Document intelligence validation
Give the reviewer the contradiction, not the whole queue
A useful exception record says which fields disagree and shows their evidence. That lets reviewers resolve the problem without repeating the extraction process manually.
In this article
Classify the exception before assigning it
Distinguish unreadable text, ambiguous field mapping, failed arithmetic, missing supplier identity and possible duplication. These problems require different evidence and sometimes different reviewers.
For a totals mismatch, show the extracted components and the relationship the validator expected. For an uncertain date, show the competing labels and source regions. A generic "low confidence" message tells the reviewer little about what to inspect.
Keep the original document available, but open it near the relevant page or region where possible. The whole document is context, not the only diagnostic tool.
Preserve the original extraction
When the reviewer changes a field, retain the raw value and source location alongside the corrected value and reason. This provides evidence for improving the parser and explains the final record later.
Do not automatically recalculate and overwrite a printed total merely to clear an exception. The mismatch may indicate a missing credit, deposit or line item. The reviewer needs to establish which interpretation is correct for the document.
If the source is too poor to resolve, use a supported request-for-better-document state. Guessing a value to clear the queue converts a visible uncertainty into a hidden error.
Prevent duplicate downstream work
Before posting a corrected record, check whether an earlier attempt may already have succeeded. A timeout can leave a reviewed invoice in an uncertain submission state even though the downstream system accepted it.
Use the operation identifier and documented reconciliation path. Do not treat a review correction as permission to create another independent posting without checking the first attempt.
Keep duplicate-document detection separate from execution idempotency. Two files may represent the same invoice, while one file may be submitted repeatedly through the same operation. Both cases need a clear rule.
Close the exception with evidence
Verify the accepted values and downstream result, then record the resolution category. Avoid collecting unnecessary personal or commercial details in broad analytics when a field category and reason are sufficient.
Review recurring exceptions by source class. A sudden increase for one supplier may indicate a layout change, while widespread arithmetic failures may point to a normalisation defect. Use those patterns to improve the pipeline and the review package rather than simply asking people to work through the queue faster.
Primary sources
Microsoft Learn: invoice extractionAWS Builders' Library: idempotent APIsReferences checked 11 September 2026.