A completed record is not proof of a correct read

01

What actually happens after extraction

AWS’s published Textract and Amazon A2I example is useful because its mechanics are explicit. Textract processes document pages and extracts data. A human-review workflow can be configured to trigger when detected form fields fall below a chosen confidence threshold.

When that review is triggered, the workflow waits for the human task. After review is completed, processing resumes, results from the pages are combined, and the output is stored. The stored result therefore sits at the end of a process that can include a distinct verification stage.

AWS says human review may be appropriate because of regulatory requirements or potentially low-quality scans. It also describes Amazon A2I as allowing predictions to be audited on an ongoing basis. Those are controls around extraction, not features of the word “complete.”

There is an important exception: AWS does not say every record needs manual inspection. Its example uses configured conditions to determine when review is triggered. The useful lesson is architectural: extraction, review and final storage can be treated as different stages rather than collapsed into a single success state.

02

The belief is stronger than the evidence

The common belief adds meaning to a workflow status. If an invoice number landed in the invoice-number field and a total landed in the total field, it is tempting to read the populated record as evidence that the source document was understood correctly.

The evidence supports a narrower conclusion. AWS provides a separate route for lower-confidence predictions and ongoing auditing. In other words, producing structured data is one operation; deciding whether particular predictions deserve additional scrutiny is another.

Production practitioners describe comparable safeguards. In one r/automation discussion, a commenter recommends classifying documents, using native PDF parsing where possible, OCR for scanned pages, validators for fields including invoice number, date, totals and tax, and review for low-confidence cases.

That Reddit discussion is practitioner experience, not a controlled accuracy study. It does not establish how often extraction fails. What it usefully shows is how an operator can avoid making “the job completed” carry more evidentiary weight than it deserves.

03

A correct read can still produce the wrong business result

There is a second problem hiding behind extraction accuracy: sometimes the text can be read correctly and still conflict with the transaction it represents. One practitioner gives a simple example. A delivery note may correctly report 46 units while the associated purchase order expects 50.

The same practitioner describes comparing extracted invoices with systems of record for quantities, prices, duplicate submissions and tax, flagging mismatches and keeping an audit trail before pushing data downstream. This is an operational account, not measured research, but it identifies checks that extraction alone cannot perform.

Another invoice-OCR discussion separates the stages similarly. One commenter recommends extracting structured fields, validating basics such as an invoice number and total format, routing low-confidence documents for review, and only then exporting. Another suggests checking whether individual line-item totals reconcile with the invoice grand total.

These controls answer different questions. Confidence review addresses uncertainty in extraction. Validation tests a defined rule. Reconciliation asks whether an extracted value agrees with another relevant record. A workflow can therefore read a value correctly while still needing evidence that the value belongs in the transaction being approved.

04

How to do it

Start by separating the decision you care about from the extraction job. Identify which fields can change that decision, what can be checked automatically, and which exceptions should stop straight-through processing.

There is no universal confidence threshold or review percentage in the supplied evidence. The practical design is therefore policy-specific: use confidence, defined validation rules and reconciliation where they address a real risk, and create an exception path for cases those controls flag.

Human review can then be targeted rather than universal. That matches the pattern in AWS’s confidence-triggered workflow and the practitioner advice to send low-confidence or exceptional records to review instead of treating every output identically.

05

Give each control one job

A cleaner operating model keeps extraction, validation and reconciliation separate. Extraction asks what the document appears to say. Validation tests the resulting values against defined rules. Reconciliation compares those values with other records relevant to a decision. Human review handles selected exceptions.

That separation also makes failures easier to diagnose. A parser problem belongs to extraction. An extracted total that fails an arithmetic rule belongs to validation. A correctly read quantity that differs from a purchase order belongs to reconciliation. Calling all three “OCR accuracy” hides where a process actually needs attention.

The benefit is operational clarity. Teams can record why a document was stopped, direct it to the appropriate check, and avoid using one generic “complete” status for several different questions about the record.

THE CHECK: For consequential records, ask: are material fields present, is confidence acceptable under your policy, do defined rules pass, does relevant data reconcile, and has each flagged exception been resolved? That checklist tests the things a completion status cannot answer on its own.