A supplier invoice arrives as a scan. The extraction service reads the company name cleanly, but the total contains a faint decimal point. Document extraction confidence can help decide what to review, yet the practical question is narrower: which value is safe to use for the next action?

A useful review process keeps the original document, the extracted field and the intended business action together. A model’s estimate can help route work. Approval still needs rules for missing information, inconsistent values and the cost of a mistake.

Separate a prediction from a measured result

Microsoft’s Document Intelligence documentation distinguishes confidence for an individual extraction from estimated accuracy for a custom model. It also separates document-type, field and word confidence. Not every field returns a score, and the availability of particular scores depends on the model and API version.

For a product team, this means a single “document confidence” badge can hide the question a reviewer needs to answer. A readable company name does not resolve an uncertain total. A correctly recognized number does not establish that it belongs to the amount-due field.

Microsoft also notes that a table cell can have high confidence while its row has lower confidence. Review the relationship between values when the document contains split rows, merged cells or multiple totals. The source position and surrounding label belong beside the extracted value in a review screen.

Choose review rules by consequence

Amazon Textract’s best-practice guidance ties confidence thresholds to the sensitivity of the application. It recommends discarding or scrutinizing predictions below an appropriate threshold, with different needs for archival material and financial decisions.

There is no useful universal threshold for every field and every action. Start with the decision the system will make, then decide what evidence it needs. The following is a proposed product-review policy, not a vendor default:

Field or condition Suggested review question Action to hold
Supplier name Does it match the intended supplier record? Creating or changing the supplier
Amount and currency Do both agree with the source and the order? Approving an invoice
Payment details Has a change passed the business’s separate verification process? Updating a payment destination
Required field missing Is it genuinely absent or was it missed? Completing the record
Conflicting totals Which total represents the amount owed? Posting the extracted amount

Keep an explicit route for a missing score. An absent confidence value is not a reason to silently treat the field as reliable, and a field that is optional in one document may be required for a particular business action.

Test the threshold against labeled documents

Google Document AI’s evaluation guide compares processor predictions with annotations in a test set. It reports precision, recall and F1, including results for individual labels. Raising a confidence threshold generally trades fewer incorrect accepted predictions for more missed values.

Google’s default threshold maximizes F1. That statistical objective does not automatically express the cost of a mistaken payment detail or an omitted invoice line. The business decision may need a stricter acceptance rule for one field and a different review route for another.

Build a test set that represents the documents the workflow will receive. Include the ordinary clean files and the awkward ones: a new supplier layout, a poor scan, a credit note, a multi-page table and a document with a genuinely absent field. Mark the expected answers before evaluating the extraction.

Record the model version, test-set version and acceptance policy with the result. Otherwise a later improvement is difficult to distinguish from a change in the documents or matching rules. Keep examples that failed; they are useful inputs to the next review.

Give the reviewer enough context to correct the record

A queue that shows only a field and a colored score asks the reviewer to guess. A more useful screen opens the original page at the relevant region and shows the field label, extracted value and any validation conflict together.

Consider a hypothetical invoice whose total is readable but whose currency is cropped off. The reviewer should be able to mark the currency unresolved without inventing it from the supplier’s country. If the document cannot establish a required value, the workflow needs a request for better evidence.

Preserve the original extraction when a person makes a correction. Store the corrected value separately with the reason and the action taken. That makes it possible to examine whether a recurring error comes from the scan, the model, the document layout or the review policy. Our audit-log guide explains the limits of treating an event record as proof of the underlying decision.

Improve the input before changing the threshold

Textract recommends clear input images and warns against downsampling an already supported document before upload. Its table guidance also calls out difficult structures such as merged cells and inconsistent rows. Better source material can address a different failure from the one a threshold addresses.

If the amount is blurred, asking for a clearer scan may be more useful than repeatedly processing the same file. If the source is clear but the value keeps landing in the wrong field, inspect the schema, labels and examples. These are different repair paths and should produce different queue reasons.

Keep the source document’s version attached to the result. Replacing a scan after extraction without retaining that connection makes a later review ambiguous. The same principle appears in data provenance for RAG answers: a result needs a trace to the material that supported it.

Reporting & Sources

Documentation reviewed October 20, 2026. The review-policy table and workflow recommendations are editorial analysis; they describe no deployment test or measured customer outcome.