Clairic can read an invoice total. What must happen before ERP posting?
Cloudflare has introduced Clairic in preview. Follow one hypothetical invoice to separate extracted fields, deterministic checks, and decisions that need an authorized accounting reviewer.
AI-generated illustration, not a customer document or real system screen.
An invoice shows a total of THB 10,700. The system reads the number correctly, but the same invoice number has already been recorded. Sending that extracted amount straight into accounts payable could still create a duplicate liability.
Cloudflare introduced Clairic on October 19, 2026, as a preview on Workers AI. It takes input plus definitions of the fields an application needs, then returns typed values such as text, numbers, or dates. For accounting teams, the useful starting question is which values to extract and where to stop a document before it affects the ledger. Cloudflare announcement
This article reflects the sources checked on October 21, 2026. It proposes an evaluation using a hypothetical document. It does not report an Enersys deployment. The cited documentation does not establish accuracy on Thai invoices, correctness under Thai tax rules, or readiness for an organization's production workflow.
Start with one invoice and keep the evidence
Suppose accounts payable receives invoice INV-1021 from Supplier A, dated October 21, 2026, referencing purchase order PO-0042. It lists 10 items at THB 1,000 each, a subtotal of THB 10,000, printed tax of THB 700, and a total of THB 10,700. The printed due date is November 20, 2026. These figures illustrate reconciliation; they do not determine the tax rate or tax treatment of a real transaction.
Original Enersys diagram based on this article’s fictional case. It is not a customer document, product screen, or Clairic test result. The printed tax illustrates arithmetic only.
Keep the original document attached to the draft record and make the supporting evidence accessible to the reviewer. Evaluate file intake, character recognition, and field extraction separately. A skewed image or a transcription error can carry an error into every later stage.
The model reference documents text and image inputs. Its text-based invoice example extracts an invoice number, derives a due date, and returns null for a missing PO number. That is the model developer's usage example, not validation on a company's own document formats. Clairic model reference and invoice example
How is Clairic different from asking a chatbot to read a document?
Ask a chatbot to “read this invoice” and the reply might be a paragraph that an application must parse again. Clairic starts with fields and answer types defined by the application: an invoice identifier as text, a total as a number, and a due date as a date. The application receives answers for those fields rather than a written explanation of the whole invoice.
Cloudflare describes a single-pass model that does not generate answer tokens like an LLM. It can return null when it cannot find an answer, alongside uncertainty information. For the team building the workflow, the question is how those values and uncertainties should affect the next step. A correct data type makes an answer usable by code; the value still needs checking against the document. How the model works, in Cloudflare’s announcement
Define fields that correspond to the document
For the evaluation, request the supplier name, invoice number, issue date, PO reference, currency, printed due date, subtotal, tax, and total. Keep the amounts separate. A single field called “amount” leaves an avoidable ambiguity about which figure the application needs.
Keep invoice numbers and tax identifiers as text to preserve leading zeros. Define how Buddhist and Gregorian years are normalized. Specify currency and units separately from the amount. These are proposed test requirements, not a claim that Clairic has been validated on every Thai document type.
If the PO is missing, retain a missing-data state and send the item for investigation. Guessing a reference to complete the form makes a draft look more reliable than its evidence. Cloudflare distinguishes extraction of an existing value, computation from supplied facts, and estimation of an unknown outcome. An estimated payment date must therefore never silently replace the contractual due date. Extraction concepts and limitations
Recalculate amounts and apply agreed rules in code
For this invoice, application code should independently calculate 10 × 1,000 = 10,000 and 10,000 + 700 = 10,700 using money-appropriate decimal handling, then compare those results with the extracted values. If the total was read as THB 10,100, hold the document to investigate. Do not silently change a value to make the equation balance.
Cloudflare explicitly identifies weaknesses in longer chains of dependent calculations and aggregation across many table rows in the early checkpoint, and recommends using code for the math. Reading a printed total correctly is no substitute for checking the sum of the invoice lines. Preview limitations in the announcement
Explicit rules should match the approved supplier record, check duplicate invoice identifiers within the same supplier and company, validate currency and open accounting periods, and compare PO-0042 with the receipt evidence. Tax checks must use rules approved by accounting for the transaction type and relevant date. The model should not choose a rate simply because the example contains THB 700 in tax.
A subtotal plus tax matching the total establishes arithmetic consistency only. It does not establish the correct tax category, legal validity of the document, or entitlement to the intended input-tax treatment. The responsible accounting and tax reviewers must address those questions.
Change the evidence and see where the draft stops
Suppose every field on INV-1021 is read correctly. The evaluation should show why the record proceeds or stops, rather than a single “success” message. These are expected outcomes under the proposed rules, not responses from an actual Clairic call.
Finding in the fictional case
Expected next step
The extracted THB 10,700 total matches recalculation
Pass arithmetic only; posting is still unapproved
Supplier and INV-1021 match an existing record
Hold the draft and link the earlier document for comparison
PO-0042 is removed from the test document
Keep the field missing or null and route it for investigation; do not guess a familiar reference
The extracted total is THB 10,100
Flag the mismatch and open the source for review; do not silently replace it with 10,700
The third case is particularly useful: it tests what happens when evidence is absent. A visible blank gives a reviewer something to investigate. A guessed PO can attach the invoice to the wrong purchase.
Human decisions remain before posting
When INV-1021 is flagged as a duplicate, a reviewer needs to compare the earlier record with the source document. It might be a resent file, a correction, or another transaction. High confidence on every extracted field does not resolve that distinction.
Review is also needed for an unmatched supplier, missing PO, incomplete receipt, changed bank account, or uncertainty over expense versus asset classification. Instructions written inside an invoice to change the payee or bypass approval are document content, not authority to operate the application.
Confidence and p_null can help prioritize exceptions, but their meaning and relationship to observed errors must be tested on the organization's own sample. Do not set approval policy from a score that merely looks high. Cloudflare says typed output does not guarantee correctness and recommends cross-checks or human review for consequential actions. Risk and uncertainty guidance
In this proposed evaluation, processing stops at a draft record. An authorized person reviews the evidence and approves ledger posting. Payment approval is a separate permission from document reading. Preserve model outputs, validation results, corrections, approver identity, and timestamps so the decision can be reconstructed.
Test the failures the team cannot accept
Start with documents authorized for the evaluation and a human-verified reference set. Include the formats the team actually receives: mixed Thai and English, Buddhist years, multiple pages, poor images, discounts, missing PO references, and resent files. Separate examples used to tune instructions from those used to measure results.
Measure correctness per field, incorrect records that pass the checks, exceptions needing staff review, and elapsed time from receipt to an accepted draft. Include conversion, correction, and human-review costs. Cloudflare's results on other tasks are not results for this Thai invoice workflow and cannot establish its accuracy or savings.
Before sending real documents for processing, the responsible team should review authorization to use the data, service terms, retention, access, and processing locations against organizational requirements. A model launch announcement does not establish PDPA compliance or Thailand data residency. Approve the data scope before starting the trial.
A useful accounting and IT meeting question is: if INV-1021 is read perfectly but duplicates an existing record, who owns the review queue and what evidence permits posting? Once that is answered, test whether Clairic prepares a sufficiently useful draft.
Questions accounting teams need to resolve
Does Clairic guarantee accurate Thai invoice extraction?
The documentation checked here does not establish accuracy on Thai invoices. Evaluate authorized documents against the organization's own verified reference answers. The service remains in preview.
Can a correctly read total go straight into ERP?
In this proposed evaluation, it still needs amount checks, duplicate detection, supplier matching, purchasing and receipt evidence, and accounting and tax review before an authorized person approves posting.
Has Enersys deployed Clairic for customers?
This article analyzes public documentation and proposes an evaluation. It does not announce an Enersys deployment or measured Clairic results.
