The invoice number looks plausible and belongs to the wrong field
An extraction system reads a clean sequence of characters from an invoice and labels it as the invoice reference. The sequence is actually a customer account number. The text recognition can be excellent while the business record is wrong. A plausible value is not evidence that the correct field was understood.
For document automation, we would separate extraction from acceptance. Extraction proposes values with their source locations. Acceptance decides whether those values may create or change a business record. Combining them into a single invisible step makes uncertainty difficult to inspect and expensive to reverse.
Confidence is an input to the decision
Amazon Textract recommends considering both confidence and the sensitivity of the use case, with uncertain results discarded or referred for greater human scrutiny. Its best-practice guidance supports a rejection path rather than unconditional acceptance. It does not supply a universal threshold for every organisation.
A confidence value should not be treated as proof that an invoice belongs to the right supplier or that payment is authorised. Those are separate questions. The extraction layer may recognise characters accurately while attaching them to the wrong commercial meaning.
Set acceptance rules at field and operation level. A doubtful descriptive note and a doubtful bank account should not trigger identical handling. Determine what evidence each decision requires and what happens when that evidence is absent. An empty field can be safer than a confident-looking guess that enters an accounting workflow.
Validate relationships, not just individual strings
Consider an illustrative invoice process. Supplier identity should match an approved supplier record. The purchase order, where required, should refer to the relevant business relationship. Totals and line items should agree under the accounting rules the organisation actually uses. A document that passes a date parser can still be the wrong document for the transaction.
Retain the original value alongside any normalised value. A date reformatted for storage should remain traceable to the source. Distinguish a correction made by a reviewer from a fresh extraction result, and keep enough provenance to explain why the accepted record differs from the document.
Duplicate detection belongs here too. Reprocessing an attachment or receiving a forwarded copy should not automatically create another invoice. Use the business identifiers and document context needed to recognise likely duplicates, then send ambiguous matches to review instead of silently merging unrelated records.
Review must allow a genuine refusal
A useful reviewer sees the relevant source region, the proposed value, validation failures and the downstream consequence. They should be able to correct a value, request a better document, reject the document or return it to the appropriate owner. Approve is not enough.
Avoid preselecting a decision that turns review into repeated confirmation. The screen should make the uncertainty visible rather than encourage the operator to clear the queue. Review throughput is not a success measure if incorrect records are being accepted more efficiently.
The rejection path also needs a customer or supplier response. A case cannot disappear after someone clicks reject. Record the reason, who must supply replacement evidence and whether the underlying business deadline is affected. That responsibility belongs to the workflow, not to the extraction model.
Test acceptance this week
Gather representative documents, including awkward layouts, ambiguous references and duplicate attachments. Agree on the accepted outcome with the team that owns the resulting records before running the extractor. Keep examples with missing evidence in the evaluation set.
Inspect incorrect acceptances separately from rejected correct values; their consequences differ. Walk a rejected case through replacement, review and final resolution. The system is ready for a narrow production scope when it can explain both what it accepted and what it deliberately refused to turn into a business record.