Document AI Extraction: What a Confidence Score Actually Means, and Where Extraction Stops Being Reliable

Quick answer: A confidence score measures how sure the model is that it read the characters correctly. It does not measure whether the value it put in the field is the right value for that field. Those are different failures, and the second one is the expensive one. Set review thresholds per field from your own cost of a wrong value, not from a single document-level accuracy number, and expect four specific document conditions to break extraction no matter whose model you buy.

Every document extraction demo ends with a screen of green fields and a number near 95%. The number is real. It is also answering a narrower question than the one you are asking, and the gap between those two questions is where production projects go wrong.

What the score is actually scoring

Read the vendor documentation rather than the marketing page and the definition is unambiguous. Amazon Textract describes the Confidence field on every returned block as:

"The confidence score that Amazon Textract has in the accuracy of the recognized text and the accuracy of the geometry points around the recognized text."

— Amazon Textract API reference

Two things are being scored there: did I read these characters correctly, and did I draw the box in the right place. Neither is is this the right value for this field.

Google's Document AI returns a confidence float on each extracted entity, but its response documentation shows how to read and display the value without defining it as a calibrated probability of correctness (handling the response). That absence is itself informative: the number is a model signal, not a guarantee with a stated statistical meaning.

So a field can carry 0.99 confidence and still be wrong, because the model read the characters on the page perfectly and took them from the wrong place on the page.

The two failure modes, and why only one is visible

This distinction is the whole article, so it is worth naming both failures precisely.

Recognition failure. The model misreads the characters. 1,240.00 becomes l,240.00 or 1,246.00. Confidence usually drops when this happens, because the model is genuinely uncertain about the glyphs. This failure is detectable from the score.

Assignment failure. The model reads the characters perfectly and assigns them to the wrong field. It takes the subtotal instead of the total, the ship-to postcode instead of the bill-to, the invoice date instead of the due date, or the second of two tax lines. Confidence stays high, because character recognition was never in doubt. This failure is invisible to the score.

Assignment failure is the one that reaches your ledger. It produces a value that is well-formed, plausible, and in the right data type — a date where a date belongs, a currency amount where money belongs. Nothing downstream flags it. It looks exactly like a correct extraction until someone reconciles against the source document weeks later.

The practical consequence: a confidence threshold is a control for one of your two failure modes. If your review process consists only of "look at anything below 0.85," you have built a control against the cheaper problem.

Setting a threshold from your own cost, not from a benchmark

A single threshold applied across every field is the default configuration and almost always the wrong one, because the cost of being wrong is not uniform across fields.

Work it out per field with three inputs:

1. What a wrong value costs. A wrong vendor bank account is a payment you may not recover. A wrong purchase order reference is five minutes of matching. A wrong description field costs nothing measurable. These differ by orders of magnitude and should not share a threshold.
2. What review costs. The fully loaded minutes a person spends opening the document, finding the field, and confirming or correcting it.
3. How often the model is wrong at a given score. This one you have to measure, not assume — see the next section.

The rule that falls out: review a field when the expected cost of not reviewing exceeds the cost of reviewing it. For a bank account field that is nearly always, regardless of score. For a description field it is nearly never. Most vendors ship one global slider because one slider is easy to build, not because one threshold is correct.

Calibrate before you trust the number

Confidence scores are model outputs, not calibrated probabilities. A field scored 0.90 is not reliably wrong one time in ten. It might be wrong one time in three, or one time in two hundred, and the relationship differs by field, by document type, and by vendor layout.

You can measure this in an afternoon:

• Take 300 processed documents with known-correct values.
• Bucket every extracted field by its confidence score — 0.5–0.6, 0.6–0.7, and so on.
• In each bucket, compute the share that was actually correct.

You now have your own calibration curve. If the 0.9–0.95 bucket is 99.4% correct, a 0.9 threshold is defensible for a low-cost field. If that bucket is 91% correct, the vendor's suggested threshold is going to hurt you. Repeat the exercise per document type, because a curve built on one vendor's invoice layout does not transfer to another's.

This is the step that separates teams who put extraction into production successfully from teams who are still arguing about accuracy percentages six months in.

Four conditions that break extraction regardless of model

Some documents are hard for structural reasons rather than model-quality reasons. Buying a better model does not fix these; changing the process around them does.

1. Line items that span pages. A table continued across a page break is the most common source of silent line-item loss. The model extracts a table per page and something has to stitch them, deciding whether a partial row at the bottom of page one and a row at the top of page two are the same row. Validate by checking that extracted line items sum to the extracted total — a check that costs nothing and catches most of these.

2. Handwriting mixed with print. Textract explicitly distinguishes HANDWRITING from PRINTED text in its response, which tells you the distinction is material enough for the API to surface. Handwritten quantities and signatures on delivery notes are markedly less reliable than the printed fields around them, and any field that may be handwritten deserves a different threshold from its printed neighbours.

3. Layouts the model has not seen. A new vendor sends its first invoice in a format nothing in the training distribution resembles. Confidence may stay high while assignment goes wrong, because the model confidently applies a familiar pattern to an unfamiliar page. This is the argument for treating a vendor's first few documents as a supervised cohort rather than as ordinary volume.

4. Ambiguity the document genuinely contains. Two dates and no label saying which is the due date. A total that appears three times with different values because of a credit. A tax line that could be VAT or a levy. Here the document does not contain enough information to determine the right answer, and no model can recover what was never written down. The only fix is upstream: ask the sender for a better document, or accept that this field requires a human.

The first three are engineering problems. The fourth is a supplier-management problem that teams keep trying to solve with a model.

What to require in a vendor evaluation

Three requests, all of which a serious vendor can satisfy in a week.

Run it on our documents, including our worst ones. Not the vendor's samples. Include the creased scan, the new supplier, the multi-page table, the handwritten delivery note. The accuracy figure that matters is the one measured on your distribution.

Show per-field confidence, not a document score. A single document-level number cannot drive a review policy, because your review policy is per field. If the product cannot expose per-field scores through its API, you cannot build cost-based thresholds on top of it.

Show the error breakdown by type. Ask what share of errors were recognition and what share were assignment. A vendor who has never separated those two has not looked closely at their own failure modes, and you will be the one who does it for them.

Where this fits in a production pipeline

Extraction is one step, and treating it as the whole problem is the common design error. In a working pipeline it sits between two things that do more of the load-bearing work than it does: a resolution step that maps extracted text onto your master data, and a validation step that checks the extracted values against each other and against a commitment such as a purchase order.

We have written about the downstream half of this in the AP context — where extraction ends and judgement begins covers the exception path once the fields are populated, and it is the part that determines whether the automation actually reduces headcount-hours or just relocates them.

FAQ

Does a 99% confidence score mean the field is 99% likely to be correct?

No. Vendor documentation describes confidence as the model's certainty in the accuracy of the recognised text, not as a calibrated probability that the value belongs in that field. A field can score 0.99 and be wrong if the model read the right characters from the wrong place. Build your own calibration curve on 300 known-correct documents before treating any score as a probability.

What is the difference between recognition and assignment errors?

A recognition error means the characters were misread, and confidence usually drops, so a threshold catches it. An assignment error means the characters were read correctly but placed in the wrong field — subtotal instead of total, invoice date instead of due date — and confidence usually stays high, so no threshold catches it. Assignment errors are the ones that reach systems of record.

What confidence threshold should we use for document AI extraction?

There is no single correct threshold, and using one global value is the most common misconfiguration. Set it per field from the cost of a wrong value, the cost of review, and your measured error rate at each score band. High-consequence fields such as bank account details warrant review regardless of score; low-consequence descriptive fields may warrant none.

Why does extraction fail on some documents no matter which vendor we use?

Four conditions are structural rather than model-quality problems: line-item tables spanning page breaks, handwriting mixed with print, layouts outside the training distribution, and documents that are genuinely ambiguous about which value belongs to which field. The first three are addressed with validation and supervised onboarding of new layouts; the fourth can only be addressed by improving the document itself.

How should we validate extracted line items?

Check that extracted line items sum to the extracted total, and that quantity multiplied by unit price reconciles per row. These cross-field checks cost nothing to implement and catch the page-break stitching failures that confidence scores are structurally unable to detect.