Five of the major document APIs return a confidence score and three do not. The ones that do disagree about the scale: Textract runs 0 to 100 while Azure, Google Document AI and Cloud Vision all run 0 to 1. A threshold copied between them fails silently.
Written for US teams choosing an extraction API for a workflow where a wrong value costs money. Every claim is quoted from vendor documentation and linked. Last updated September 2026.
Upload a document to extract
Drop files here or click to upload
Up to 50 files
Free plan extracts the first 5 files, the rest unlock when you upgrade
Uploading...
Drop a real document in and look at what comes back per field, not per word.
AWS Textract, Azure AI Document Intelligence, Google Document AI and Google Cloud Vision all return a confidence score on every response. Mistral OCR returns one only if you set confidence_scores_granularity, and the Azure-hosted copy of Mistral OCR rejects that parameter outright. Amazon Bedrock Data Automation documents no confidence field anywhere in its output schema. Chat models return none at all.
The detail that breaks integrations is the scale. Textract documents its confidence as a float with a "Maximum value of 100." Azure documents "an estimated probability between 0 and 1." Google uses "Range [0, 1]" in both products. A routing rule written as if (confidence < 0.9) is correct on three of them and, on Textract, quietly approves every value in your document set. It does not throw and it does not log. You find out when somebody downstream notices a wrong number.
The part most buyers get wrong. Confidence is not accuracy. Accuracy is measured against known-correct answers, usually once, at benchmark time. Confidence is the model guessing about itself, on one result, right now. A model can be confidently wrong, so the only question worth asking a vendor is whether their score is calibrated: at a 90% threshold, is it actually right about 90% of the time? If you want the accuracy side of this decision, that is a separate axis and we keep it on the OCR accuracy comparison.
Every row is read from the vendor's own reference documentation, not from a marketing page. Where a vendor gates a feature by API version or model type, the gate is in the row, because that is usually the thing that bites after the contract is signed.
| API | Scale | Default | Where the score sits | The thing to know |
|---|---|---|---|---|
| AWS Textract | 0 to 100 | Always on | Word, line, key-value pair, table, cell, merged cell, selection element, signature, query result, expense field | The widest coverage of the structures you actually act on |
| Azure AI Document Intelligence | 0 to 1 | Always on | Word, key-value pair, selection mark, region, signature, document type. Table, row and cell only on custom models from the 2024-11-30 GA version | Microsoft states that "not all document fields return a confidence score" |
| Google Document AI | 0 to 1 | Always on | Entity, block, token, form field name and value, table layout, detected language | Table cells carry no confidence field. One number for the whole grid |
| Google Cloud Vision | 0 to 1 | Always on | Page, block, paragraph, word, symbol | The most granular reading hierarchy, but no business fields to attach it to |
| Mistral OCR | 0 to 1 | Off by default | Page, block or word, whichever you request | Set confidence_scores_granularity or you get nothing back |
| Mistral OCR on Azure AI Foundry | Not available | Not available | None | The parameter is rejected with HTTP 422 extra_forbidden |
| Amazon Bedrock Data Automation | Not documented | Not documented | None found in the published output schema | Zero occurrences of "confidence" across all three document output pages |
| Chat models (GPT, Claude, Gemini) | Not available | Not available | None. Token logprobs on two of the three, which is a different thing | The Anthropic Messages API does not accept a logprobs parameter at all |
Bedrock Data Automation is marked "not documented" rather than "returns none" on purpose. We counted the word across AWS's three BDA document-output pages and found zero occurrences, which establishes that AWS publishes no confidence field. It does not establish what an undocumented response body contains, and we are not going to claim it does.
This is the most expensive small detail on the page. Textract's Confidence field is documented as "Type: Float. Valid Range: Minimum value of 0. Maximum value of 100." Azure's is "an estimated probability between 0 and 1." Both are floats. Both are called confidence. Neither will complain if you compare it to the wrong number.
Teams hit this during migrations and during proof-of-concept bake-offs, which is exactly when nobody is watching the review queue. The symptom is a straight-through processing rate that looks suspiciously perfect for about a week.
| API | Documented type | A 90% rule looks like | If you use the other form |
|---|---|---|---|
| AWS Textract | Float, 0 to 100 | confidence < 90 | 0.9 lets everything through |
| Azure AI Document Intelligence | Probability, 0 to 1 | confidence < 0.9 | 90 flags everything |
| Google Document AI | Float, 0 to 1 | confidence < 0.9 | 90 flags everything |
| Google Cloud Vision | Float, 0 to 1 | confidence < 0.9 | 90 flags everything |
| Mistral OCR | Float, 0 to 1 | confidence < 0.9 | Null unless you set the granularity parameter |
The cheap defense. Normalize at the boundary. Convert every vendor score to a single internal scale the moment it enters your code, assert that it lands in the range you expect, and never let a raw vendor number reach a business rule. It is five lines and it removes an entire class of silent failure. If you are still choosing between providers, the shape of the response matters as much as the price, which is why we keep typed JSON output on its own page.
Microsoft's definition is precise and almost universally skimmed past. A field confidence score, in their words, "reflects the model's confidence on the position of the value extracted." Position. Not the characters inside it. So a 0.99 on an invoice total means Azure is confident it found the right box on the page. Whether it read the digits correctly is a different number.
Microsoft says so directly and tells you to do the combining yourself: "While evaluating confidence scores, you should also look at the underlying extraction confidence to generate a comprehensive confidence for the extracted result. Evaluate the OCR results for text extraction or selection marks depending on the field type to generate a composite confidence score for the field."
And on the same page, in case it was not clear: "The confidence of the read results doesn't affect the confidence of the key/value extraction results, so you should check both."
Contrast with Textract, which is honest in the other direction. AWS documents its confidence as covering "the accuracy of the recognized text and the accuracy of the geometry points around the recognized text." One number, two jobs, said out loud. Neither approach is wrong. What matters is that you know which one you bought, because the composite you have to build differs.
For financial documents this is the row that decides the purchase. A statement, a remittance or an invoice with line items is mostly a grid, and a single confidence number for a grid holding four hundred values tells you nothing actionable.
| API | Row level | Cell level | Table level | Conditions |
|---|---|---|---|---|
| AWS Textract | Yes | Yes, on CELL and MERGED_CELL blocks | Yes, on the TABLE block | Nothing gated. It has worked this way since launch |
| Azure AI Document Intelligence | Custom models only | Custom models only | Custom models only | Added in the 2024-11-30 GA API version. Prebuilt layout and invoice do not return it |
| Google Document AI | No | No | Yes, on the table layout | You get one score for a grid that may hold 400 numbers |
| Amazon Bedrock Data Automation | No | No | No | The TABLE entity carries html, markdown, text, csv, headers, footers and locations, and no confidence |
Verbatim: "Regardless of the type of table, the expectation for merged cells is that they should have lower confidence values. Furthermore, the cell that is missing (because it was merged with an adjacent cell) should have NULL value with lower confidence as well." If your documents use merged headers, expect a permanently noisier review queue there and set that expectation before you pick a threshold. Getting merged cells out of a table intact is its own problem, which is why the mechanics live on the PDF table extraction page.
Microsoft's own guidance: "A correctly predicted cell that belongs to a row with other possible misses would have high cell confidence, but the row's confidence should be low." Start at the table, drill to the row, then look at cells. For fixed-layout tables they say cell confidence alone is usually enough; for dynamic tables the levels are designed to build on each other.
Textract puts a confidence value on every block it returns. Bedrock Data Automation, the service AWS positions for document understanding on top of foundation models, publishes an output schema with none. We counted: zero occurrences of the word across the standard-output page, the custom-output page and the IDP page. The TABLE entity carries html, markdown, text, csv, headers, footers, titles, page indices and bounding boxes. There is no confidence field on it.
That is a genuine trade against BDA's markdown and CSV output, and it belongs in the same conversation as price. We work through the whole comparison on Bedrock Data Automation against Textract.
Mistral OCR does return confidence, at page, block or word level, but only when confidence_scores_granularity is set. The documented behavior is that it "defaults to None (no confidence scores) to keep response payload small." Block granularity is recent, added with OCR 4.1 in July 2026.
The failure mode is quiet: your integration works, the fields come back, and the confidence key is simply absent. More detail on the rest of that response shape sits on the Mistral OCR reference.
Ask GPT, Claude or Gemini to return a JSON object of invoice fields and you get exactly that: fields. No confidence, because there is no field in the response schema for one. The Anthropic Messages API does not even accept a logprobs parameter, so the usual workaround is unavailable there.
OpenAI and Google do expose token log probabilities, and people do aggregate them into a pseudo-confidence. It is not the same thing and the research community treats calibrated field confidence for LLM extraction as an open problem. The rest of that trade-off is on the LLM OCR page.
A fourth way, and it is the one that catches procurement. Buying the same model through a different storefront can remove the feature. Mistral OCR deployed on Azure AI Foundry rejects the confidence parameter with an HTTP 422. A Microsoft moderator confirmed it in the vendor's own Q&A: "Azure-hosted Mistral OCR currently does not support the confidence_scores_granularity parameter... There is no alternative Azure parameter today to retrieve word/page confidence scores from Mistral OCR." If a marketplace deployment is on your shortlist because of an existing cloud commitment, test the specific parameters you depend on before you sign.
Every confidence threshold is applied to a field. Every human reviews a document. Those two facts compound, and the gap between them is where most straight-through processing forecasts go wrong. If a share of fields falls below your threshold and you extract several dozen fields per document, the chance a given document contains at least one of them is much higher than the field rate suggests.
| Share of fields under threshold | 10 fields per document | 20 fields per document | 40 fields per document |
|---|---|---|---|
| 0.5% of fields below threshold | 4.9% | 9.5% | 18.2% |
| 1% of fields below threshold | 9.6% | 18.2% | 33.1% |
| 2% of fields below threshold | 18.3% | 33.2% | 55.4% |
| 5% of fields below threshold | 40.1% | 64.2% | 87.1% |
| 10% of fields below threshold | 65.1% | 87.8% | 98.5% |
The share of documents touched is 1 minus (1 minus the field rate) raised to the number of fields. This assumes field errors are independent, and they are not: a skewed scan or a faint fax degrades a whole page at once, which clusters the failures into fewer documents. So read these as an upper bound on the touch rate rather than a measurement. The shape is what matters, and the shape is that a 98% per-field pass rate on a 20-field invoice sends about a third of your documents to a person.
The single cheapest fix. If your process posts an invoice using six values, threshold those six and let the rest through unreviewed. Going from 40 gated fields to 6 takes a 2% field rate from a 55% document touch rate to 11%. Nothing about the model changed; you stopped paying people to check data nobody uses.
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, and they catch a class of error confidence never will: values read perfectly and still wrong.
AWS is the only one of the big providers that publishes usable guidance, and it is refreshingly plain: "In applications that are sensitive to detection errors (false positives), enforce a minimum confidence score threshold... 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."
That is the right frame. The threshold is a price you set on being wrong. Work out what a single incorrect value costs you, in dollars or in a regulator's attention, then work out what a minute of a reviewer's time costs, and the number falls out. It is a finance decision wearing an engineering costume.
One practical note on AWS's own routing service. Amazon Augmented AI lets you set an identification confidence threshold and a qualification confidence threshold, each "between 0 and 99", and it "routes only those predictions that fall within the threshold to human reviewers." Read the scope carefully: the Textract task type is "Key-value pair extraction", so it triggers on form keys. It is not a general mechanism for table cells or raw lines.
AWS splits them for a reason. Identification confidence is "the confidence score for key-value pairs detected within a form", meaning did we find the field. Qualification confidence is "the confidence score for text contained within a key-value pair", meaning did we read it. Those fail differently. A missing field is a layout problem; a misread field is an image quality problem, and the fix for each is different.
A threshold only ever shows you the model's failures that the model already suspects. Route a small random percentage of high-confidence documents to review as well, and you get the one metric that matters: how often a confident score was wrong. Without it you are trusting a number you have never checked.
Store the confidence next to every extracted value in your own database, not just at the moment of the decision. When someone 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. This is also what makes a threshold change measurable rather than a matter of opinion.
Payments, tax filings, claims, loan files. If a transposed digit creates a liability, per-field confidence is not a nice-to-have, it is the mechanism that decides which values a person sees. Buy an API that returns it on the fields you act on, not just on words.
You cannot report an STP rate without a rule for what goes straight through. That rule is a confidence threshold, and the compounding arithmetic above is what makes the reported number honest instead of aspirational.
An auditor asking why a value was accepted without review wants a number and a documented threshold, not "the model was pretty good." Confidence gives you a defensible answer with a timestamp on it.
If the output feeds a search index, a per-field confidence score has nothing to attach to and no decision to inform. Cheap page-level OCR is the right purchase and confidence is noise.
A human looking at every page is a better reviewer than any threshold. Confidence pays off when volume removes the human, not before.
If the extraction is a prompt to GPT or Claude and that is fixed, no confidence field exists to threshold on. You would be building a second scoring system on top, which is a real project and worth pricing honestly.
A confidence score is a number an OCR or document extraction API returns alongside each result, estimating how likely that result is to be correct. AWS defines it plainly: "a number between 0 and 100 that indicates the probability that a given prediction is correct." You use it to decide what your software can accept automatically and what a person has to look at.
AWS Textract, Azure AI Document Intelligence, Google Document AI, Google Cloud Vision and Mistral OCR all return confidence, though not in the same way. Textract and the two Google products return it on every response. Azure returns it on words, key-value pairs, selection marks and signatures, but states that not all document fields carry one. Mistral returns none unless you set a parameter.
Two different scales, which is the trap. Amazon Textract uses 0 to 100 and documents the field as "Valid Range: Minimum value of 0. Maximum value of 100." Azure Document Intelligence, Google Document AI and Google Cloud Vision all use 0 to 1. A threshold of 0.9 means 90% on Azure and 0.9% on Textract, so porting a rule between them silently approves everything.
AWS gives the only vendor guidance we found worth quoting: "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." The honest answer is that the threshold is a business decision about the cost of a wrong value against the cost of a human minute, not a technical constant.
Not in its published output. We counted the word "confidence" across all three of the AWS documentation pages describing BDA document output on September 5, 2026 and found zero occurrences. The documented schema for the document, text, table, figure, page, text_lines and text_words objects carries ids, representations, reading order, page indices and bounding boxes, and no confidence field on any of them.
Only if you ask for them. The API has a confidence_scores_granularity parameter that accepts "page", "word" or "block", and Mistral documents that it "defaults to None (no confidence scores) to keep response payload small." If you never set it, every response comes back without confidence and nothing warns you.
No. A Microsoft moderator answered this directly: "Azure-hosted Mistral OCR currently does not support the confidence_scores_granularity parameter. The HTTP 422 (extra_forbidden) error confirms the parameter is not part of the Azure-exposed API schema. There is no alternative Azure parameter today to retrieve word/page confidence scores from Mistral OCR." The same model, bought through a different storefront, loses the signal.
It depends on the vendor, and this is where they diverge most. Textract gives every CELL and MERGED_CELL block a confidence value. Google Document AI puts confidence on the table layout but not on individual cells. Azure added table, row and cell confidence with the 2024-11-30 GA API version and only for custom models, so the prebuilt layout and invoice models do not return it.
No. None of the chat model APIs returns a confidence value with a structured output. The Anthropic Messages API does not even accept a logprobs parameter; OpenAI and Google expose token log probabilities you can aggregate yourself, but a token probability is not a field confidence and turning one into the other is an open research problem. Purpose-built document APIs return confidence directly.
Position, not characters. Microsoft states that a field confidence score "reflects the model's confidence on the position of the value extracted" and then tells you to combine it yourself: "Evaluate the OCR results for text extraction or selection marks depending on the field type to generate a composite confidence score for the field." A 0.99 field score means Azure is sure it found the right box, not that it read it correctly.
Do not average the fields, because averaging hides the one bad value you care about. Take the minimum confidence across the fields your process depends on, and treat that as the document score. If you need a document-level touch rate for planning, use 1 minus (1 minus the share of fields below threshold) raised to the number of fields, which is the arithmetic in the table above.
No, and Microsoft separates the two explicitly. Accuracy is measured against known correct answers, usually at training or benchmark time. Confidence is the model's own estimate at inference time about one particular result. A model can be confidently wrong, which is why the useful question about any confidence score is whether it is calibrated: at a 90% threshold, is it right about 90% of the time?
On AWS, yes, through Amazon Augmented AI, which lets you set an identification confidence and a qualification confidence threshold "between 0 and 99" and routes only the predictions inside that band to reviewers. Note the scope: the Textract task type is "Key-value pair extraction", so it triggers on form keys, not on table cells or raw text lines.
Google Cloud Vision, on paper: it publishes confidence at page, block, paragraph, word and symbol level, all on a 0 to 1 range. Textract is close behind and more useful for business documents, because its confidence sits on the structures you actually act on, including key-value pairs, table cells and query results, rather than only on the reading hierarchy.
Almost always because the threshold is applied per field while a person reviews a whole document, and the two rates compound. On a 20-field invoice, a per-field pass rate of 98% still sends about a third of documents to a human. If your straight-through processing rate came in far below the accuracy number in the vendor deck, this arithmetic is usually the reason.
DocuOCR returns a confidence value on each extracted field, on one scale, on every response, with no parameter to remember to set. That is the point of the whole page: the number is only useful if it is attached to the values your process acts on and it means the same thing every time. Upload a real document above and look at what comes back before you commit to anyone, including us. We do not publish a headline accuracy percentage, because the only accuracy figure worth anything is the one measured on your documents.
