---
title: "AI data extraction for invoices and customs documents: types, confidence and review"
description: "Design AI data extraction with typed fields, nulls, review thresholds and checks before the ERP. Clairic as an example, with verified capabilities and limits."
author: "Carlos García"
published: 2026-10-20
updated: 2026-10-20
language: en
human_url: "https://kiia.cloud/blog/ai-data-extraction-invoices-customs-documents/"
---

> **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:

```json
{
  "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](https://developers.cloudflare.com/workers-ai/concepts/extraction-models/), 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](/blog/from-cleaning-excel-to-managing-ai-exceptions/) helps operate that queue.

## Clairic as an example: verified on October 20, 2026

The [official October 19 announcement](https://developers.cloudflare.com/changelog/post/2026-10-19-clairic-workers-ai/) 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](https://developers.cloudflare.com/workers-ai/models/clairic/), 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](https://developers.cloudflare.com/workers-ai/platform/pricing/), 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](/blog/how-to-build-a-payment-receipt-collections-agent/). Intake through [WhatsApp](/blog/payment-receipts-whatsapp-to-collections/) and [Outlook or Teams](/blog/payment-receipts-outlook-teams-collections/) shares these controls even when the channel changes. The operational goal is to reduce the [cost of copying data between systems](/blog/cost-of-copying-data-between-systems/) while retaining evidence for every decision.

If your team is defining this workflow, [talk to Kiia](/#cta-final) about a bounded pilot: one format, a reviewable schema and an owned queue before connecting ERP writes.

## Frequently asked questions

### Can AI extract invoice data without errors?

It can return a correctly typed field while misreading its content. Keep the original, check amounts and references with rules, and send exceptions to a person before recording data in the ERP. High confidence does not authorize a payment or validate an official document.

### What confidence threshold should I use?

Set it by field and risk using representative documents reviewed by your team. Compare thresholds on a separate sample and measure errors that would reach the ERP, automated cases and review workload. There is no universal percentage; a critical field without evidence blocks the entire document.

### Do I need separate OCR?

It depends on your formats and tool. A PDF with a text layer may allow direct text extraction; a scan needs OCR or a vision model. Clairic's model reference checked on October 20, 2026 accepts images but does not document direct PDF input: prepare compatible text or images and test reading quality before automating.