AI data extraction for invoices and customs documents: types, confidence and review

In 60 seconds: To extract invoice data with AI, first define what each field means, its type and when it must stay null. Keep the document and reading evidence. Use confidence to route cases: high scores with every validation passed can allow recording within an agreed permission; uncertain cases go to review; missing or unreadable critical fields go to quarantine. Calculate totals in code and cross-check references against the authorized system. Calibrate thresholds on your own documents before enabling writes. For customs documents, flag discrepancies for the responsible reviewer; never automatically correct the original.

A fictional invoice says “Total: 1.250,00” and “Currency: USD.” The extractor returns 1250.00 but records it in local currency. The structure is valid and the entry may be wrong. Operations work starts in that gap between reading a value and being able to use it.

This guide focuses on the contract between the document and the ERP: schema, absence, confidence, rules and review. Extraction ends with candidate fields; reconciling the invoice against a quote is a subsequent process. All examples are fictional and contain no customer data.

What typed extraction adds

OCR recognizes text; a template tries to locate it using known positions or labels. That may be enough for an invoice with a stable layout. If the layout changes, you need to check that the rule still points to the total rather than the subtotal.

Asking a general-purpose LLM for JSON organizes the response. Tools that support it can also enforce a schema. The operational contract additionally needs a representation for missing data, a way to verify evidence and an available uncertainty signal. A valid number can still be the amount from a different row.

In a typed workflow, design each output before reading documents: invoice number as text, total as a number, date as a date. Keep extraction tasks separate from estimation. If the due date is missing, a prediction of when the customer will pay cannot fill that field.

The design should work with OCR and rules, a document service, a vision model or an LLM with structured output. Require the same contract from each provider adapter. If comparable confidence is unavailable, keep review until you have measured an alternative policy; do not convert a phrase such as “I am certain” into a probability.

Design the schema before the prompt

For each field, store the literal value, normalized value, supporting page or passage and reason for absence or uncertainty. Also keep the original file’s hash, schema version, extractor and applied policy. An absent optional field can be valid; an absent required field prevents progress.

Field	Destination type	Proposed rule
invoice_number	Text	Preserve leading zeros and separators; never convert an identifier to a number
supplier_tax_id	Text or null	Read the printed identifier; resolve identity against master data separately
total	Decimal or null	Define which total includes tax, discounts and freight; preserve the precision required by the destination
currency	Currency code or null	A lone $ symbol does not identify a country or currency
issue_date	ISO date or null	Do not interpret 04/05 without a confirmed convention or invent the year
purchase_order	Text or null	If absent, do not reuse the invoice number
line_items	List of records	Keep a reference to each row and distinguish an unreadable table from an empty one

For decimals, define separators by source format and reject ambiguity. Calculate money with decimal arithmetic or minor units and the business’s rounding rule. Do not impose two decimal places on quantities, unit prices or currencies requiring different precision.

A date without a year needs approved, traceable context. If none exists, preserve the literal text and leave the normalized date null. A value supplied from the purchase order belongs in a separate field with that provenance; it must not appear to be text from the invoice.

For example, fictional invoice DEMO-0042 shows “Total: 1.250,00 USD,” “Issued: 20/10/2026” and no purchase order. The application’s representation could be:

{
  "invoice_number": "DEMO-0042",
  "total": "1250.00",
  "currency": "USD",
  "issue_date": "2026-10-20",
  "purchase_order": null,
  "status": "review",
  "reason": "purchase_order_required_by_policy"
}

This is an illustrative destination contract, not a Clairic response: the decimal is serialized as a string to preserve precision. Evidence and confidence metadata are stored alongside these values. Even when reading is correct, a rule requiring a purchase order keeps the case in review.

Confidence routes cases; rules permit action

Clairic distinguishes p_null—the probability that the input does not determine the value—from confidence. A null may reflect missing information or a reading failure; it does not prove the data is absent. The official extraction guide, checked on October 20, 2026, warns that types and confidence do not replace application checks.

Read value first, then the absence signal and confidence. Do not salvage an auxiliary guess when the final value is null. Do not average fields either: several correctly read descriptions cannot compensate for an uncertain currency.

Route	Policy condition	Action
Automatic recording	Every critical field present, confidence above its approval threshold, absence below its limit and all rules passed	Record only the authorized operation; keep the ERP response
Human review	Legible evidence but intermediate confidence, ambiguous reference or a resolvable discrepancy	Show the original and candidates; require a decision with a reason
Quarantine	Critical field null, low confidence, unreadable document, truncated output or blocking inconsistency	Stop the write and assign an owner to request evidence or escalate

Define two boundaries per field: one for automatic approval and another for review. Below the second, the case goes to quarantine. The policy also needs an absence-signal limit and reasons that block action regardless of score. Recording an invoice does not grant permission to pay it or release a shipment.

How to choose thresholds using your own sample

1. Collect authorized documents covering suppliers, currencies, languages, layouts and reading quality. Include credit notes, absent fields and cases that caused rework. Anonymize examples used outside the authorized environment.
2. Have the team label the correct value and evidence for each field. Resolve disagreements before evaluating the model.
3. Use one portion to adjust the schema and thresholds. Reserve another to check the outcome without retuning on those same documents; avoid splitting copies of an invoice across both sets.
4. For each candidate policy, count errors that would be recorded automatically, eligible documents, reviews and quarantines. Break results down by field and format; examine high-confidence errors closely.
5. Choose boundaries with Finance and Operations based on impact and actual queue capacity. Test in shadow mode without writing, and audit cases that would have passed automatically too.

If a format has too few examples, keep it in review. Recalibrate when the model, OCR, schema or document mix changes. Store the policy version so you can reconstruct why an entry was accepted.

Deterministic checks after the model

Calculate line totals, taxes, discounts and freight in code using approved tolerances and rounding. Compare the result with the extracted total; a discrepancy must produce a visible exception.

Validate RFC or NIT format according to the configured country and identifier type. Valid formatting does not establish identity or tax status: cross-check the supplier against authorized master data. Compare invoice, purchase order or quote by references, currency, items and quantities, keeping differences for the reconciliation process.

If conversion is required, obtain the exchange rate from the approved source for the relevant date and operation. Store the source, date and rule; block conversion if they are missing. Do not use a rate recalled by the model. These are software design controls; the local owner defines applicable tax and customs rules.

Before writing, check duplicates using identifiers and the document fingerprint, minimum permissions and idempotency. Keep the ID returned by the ERP. A timeout requires checking the outcome before retrying to avoid duplicating the invoice.

AI for customs documents: flag the discrepancy

For Mexican pedimentos, DUA forms or other documents, agree on critical fields for the specific format with the foreign trade owner. These may include declaration number and version, importer or exporter, customs office, procedure, currency, declared value, tariff classification, origin, quantities, units and invoice references. The list depends on country and operation; it is not a universal form.

Preserve identifiers and codes as text. Distinguish net from gross weight and commercial from declared units. Matching two numbers with different units does not validate a reading.

If declared value differs from the invoice, store both with their sources and open an exception. Do not recalculate or overwrite the official value to make it match. An authorized person reviews the cause and determines the appropriate procedure; the agent preserves the original document and version history.

The review screen needs the document, page, literal value, normalized value, uncertain field, failed rule and owner. The decision must record actor, date and reason. The pattern in from Excel cleanup to exception management helps operate that queue.

Clairic as an example: verified on October 20, 2026

The official October 19 announcement introduces @cf/cloudflare/clairic in preview. Open weights are an announced intention, not a confirmed release. It supports text, numbers, dates/times, durations, lists, estimates and forecasts; scalars include p_null and confidence. Predictions include a median and an 80% p10–p90 interval. Cloudflare describes one- or two-step calculations as reliable but limits long chains and aggregation across many rows: extract operands and calculate in code.

The model reference, checked that day, documents text and PNG/JPEG/WebP images: up to four, 4 MiB each and 8 MiB combined; no remote URLs. It lists a 65,536-token context and 8,192-token passes for distributing fields. Direct PDF input and specific Spanish or LATAM form support are not published / verify. Prepare PDF text or images and validate coverage. reference_date anchors dates without a year; use only approved context.

The official price, checked on October 20, 2026, is USD 0.10 per million input tokens; the announcement confirms no output-token charge. That is inference pricing, not the complete workflow: document preparation, storage, integration and review need their own budget. Recheck pricing and limits before purchasing.

This example establishes no performance result for your invoices. To evaluate another tool, use the same document set and check evidence, null handling, table reading, input limits, data handling and the ability to stop a write.

When to keep mandatory review

Keep review mandatory if you lack representative documents, supplier identity is ambiguous, no approved exchange-rate source exists or nobody can resolve the queue. Do not enable writes if the destination cannot restrict permissions, detect duplicates and verify outcomes. Unvalidated customs formats stay outside the automatic route.

To connect these fields to a complete workflow, follow the payment receipt and collections agent guide. Intake through WhatsApp and Outlook or Teams shares these controls even when the channel changes. The operational goal is to reduce the cost of copying data between systems while retaining evidence for every decision.

If your team is defining this workflow, talk to Kiia about a bounded pilot: one format, a reviewable schema and an owned queue before connecting ERP writes.