Textract Confidence Score: Thresholds for Auto-Approve and Human Review

Amazon Textract confidence scores run from 0 to 100, not 0 to 1, and AWS recommends a threshold of 90 or higher for anything involving a financial decision. That is the short version. The longer version is that Textract returns several different confidence values that mean different things, that the routing service AWS gives you only triggers on form fields, and that a per-field threshold turns into a document review rate far larger than the field number suggests. Here is how to set the number without discovering the arithmetic in production.

What scale is the Textract confidence score on?

Zero to one hundred. AWS documents the Confidence property of a Block object as "Type: Float. Valid Range: Minimum value of 0. Maximum value of 100," and repeats the definition in its best practices guide: "A confidence score is a number between 0 and 100 that indicates the probability that a given prediction is correct."

This matters more than it should, because Textract is the outlier. Azure AI Document Intelligence documents its confidence as "an estimated probability between 0 and 1." Google Document AI and Google Cloud Vision both use "Range [0, 1]." So a routing rule written as if (confidence < 0.9) review() behaves correctly on three of the four major document APIs and, on Textract, approves every value in your document set, because every Textract score above 0.9 out of 100 clears it. Nothing throws. Nothing logs. We wrote up the full cross-vendor picture on which OCR APIs return a confidence score and on what scale, because this is the single most common silent failure in a migration.

Which Textract results carry a confidence score?

Nearly all of them, which is Textract's real strength here. Confidence sits on the Block object, and Textract models almost everything as a block: WORD, LINE, KEY_VALUE_SET, TABLE, CELL, MERGED_CELL, SELECTION_ELEMENT, SIGNATURE and QUERY_RESULT. AnalyzeExpense uses a different shape, the ExpenseDetection object, which carries its own confidence documented as "the confidence in detection, as a percentage" on the same 0 to 100 range.

Two consequences worth planning around. First, table cells get their own scores, which not every vendor does: Google Document AI puts confidence on the table layout but not on individual cells, and Azure only added table, row and cell confidence in the 2024-11-30 GA API version and only for custom models. If your documents are grids of numbers, Textract gives you a per-cell signal to act on. Second, AWS is explicit that one Textract score covers two jobs at once: it describes confidence as "the accuracy of the recognized text and the accuracy of the geometry points around the recognized text." You cannot separate a bad read from a bad bounding box using that number alone.

What is a good confidence threshold for Textract?

AWS publishes the only vendor guidance on this we consider quotable, and it is refreshingly plain: "In applications that are sensitive to detection errors (false positives), enforce a minimum confidence score threshold. The application should discard results below that threshold or flag situations as requiring a higher level of human scrutiny. The optimal threshold depends on the application. For archival purposes, such as documenting handwritten notes, it might be as low as 50%. Business processes involving financial decisions might require thresholds of 90% or higher."

Treat that as a starting range, not an answer. The threshold is a price you set on being wrong. Work out what one incorrect value costs, in dollars or in a regulator's attention, then work out what a minute of a reviewer's time costs. The number falls out of those two figures, and it will not be the same for an invoice total as it is for a vendor's street address.

Identification confidence and qualification confidence are not the same number

If you route low-confidence results with Amazon Augmented AI (A2I), you set two thresholds, and AWS defines them separately. Identification confidence is "the confidence score for key-value pairs detected within a form." Qualification confidence is "the confidence score for text contained within a key-value pair in a form." Did we find the field, and did we read it. Both accept a value "between 0 and 99," and AWS states that "if you specify a confidence threshold, Amazon A2I routes only those predictions that fall within the threshold to human reviewers."

Splitting them is useful because the two failures have different fixes. A low identification score means the layout drifted, which is a template or model problem. A low qualification score means the image was poor, which is a scanning or source problem. Teams that track only one blended number end up rescanning documents to fix a layout issue.

One scope limit to know before you design around it: the Textract task type in A2I is "Key-value pair extraction." The activation conditions are all written in terms of form keys. It is not a general mechanism for routing on table cell confidence or raw line confidence, so if your critical values live in a line-item grid, you are building that routing yourself.

Why does my threshold flag so many documents?

Because the threshold is applied per field and a person reviews a whole document, and those two rates compound. If a share of your fields falls below the threshold and you extract a number of fields per document, the share of documents containing at least one flagged field is 1 minus (1 minus the field rate) raised to the number of fields. That produces numbers most people find surprising:

A 98% per-field pass rate on a twenty-field invoice sends about a third of documents to a human. That single line explains most of the gap between the accuracy number in a vendor deck and the straight-through processing rate a finance team actually reports six months later. The table assumes field errors are independent, and they are not, since a skewed scan degrades a whole page at once and clusters failures into fewer documents. So read it as an upper bound on your touch rate. The shape is the point.

The cheapest fix is to gate fewer fields

Most extraction pipelines threshold everything the API returned, because that is the default loop. If your process posts an invoice using six values, threshold those six and let the rest through unreviewed. Going from forty gated fields to six takes a 2% field rate from a 55% document touch rate down to about 11%. Nothing about the model changed. You stopped paying people to check data that nothing downstream reads.

The second cheapest fix is validation instead of review

A low-confidence total that still equals the sum of the line items does not need a human. Cross-field checks, format rules, and matching against a purchase order or a vendor master will clear a large share of flagged documents automatically. They also catch the class of error confidence will never see: a value read perfectly and still wrong, because it came off the wrong line or the wrong page. A confidence gate is a check at ingest, so it cannot know that last month's amount arrived twice; that is the job of monitoring the data once it lands in your warehouse.

Sample above the threshold, or you are trusting a number you never checked

A threshold only shows you the failures the model already suspects. It tells you nothing about the confident mistakes, which are the expensive ones. Route a small random percentage of high-confidence documents into the same review queue and you get the only metric that makes a threshold defensible: how often a score above the line was wrong. AWS supports this directly, since A2I can "randomly send a sample of forms to humans for review... for model-monitoring purposes."

Store the confidence alongside every extracted value in your own database too, not only at the moment of the decision. When somebody asks in eleven months why a payment went out on a misread amount, the answer is either a row with a number in it or a shrug. It also turns a threshold change from an argument into a measurement.

When Textract confidence stops being enough

Two situations, both common. The first is when the values you care about are not form keys. Textract will score a table cell, but AWS's own routing service will not act on that score, so line-item review becomes custom code you own forever. The second is when the confidence you need is about a business field rather than a piece of text. Textract tells you how sure it is about characters and geometry. It does not tell you how sure it is that this number is the invoice total rather than the subtotal, because that mapping happens in your code, not in the API. If you are weighing that trade against price, the rate side is on our AWS Textract pricing breakdown, and the constraint side is on Textract's published limits.

DocuOCR returns a confidence value on each extracted business field, on one scale, on every response, with no parameter to set and no separate service to wire up for routing. That is the difference worth testing rather than reading about: upload a document you already know the right answers for, set your threshold, and see what the review queue looks like on your own paperwork before you commit to any vendor, us included.