When can a document update a business record?
Architecture decisionsA document arrives with a plausible total and a customer name. Extraction is easy to demo. The hard decision is whether those fields are trustworthy enough to change the system of record.
Illustrative worked decision
What makes the obvious answer unsafe?
Imagine a supplier invoice whose total looks legible but whose purchase-order number differs from the current order. A model may extract both fields perfectly. That does not make the invoice payable, nor does a high extraction score settle which record is authoritative.
The architecture decision is where automation stops. The goal is to avoid both extremes: keying every field manually, or allowing a convincing extraction to silently overwrite a business record.
Three credible approaches.
The most automated option is not the default. Choose it only if its additional value can be measured against the simpler flow.
| Approach | Fit | Cost and risk |
|---|---|---|
| Manual entry and review | Low volume or highly variable documents | Clear human accountability, but slow and difficult to scale or audit consistently. |
| Extract, then review every case | Strong starting point | Improves data entry and preserves control, but every document still enters a queue. |
| Selective straight-through processing | Only after measured field-level evidence | Reduces routine work, but requires evaluated rules, exception ownership, and rollback/reconciliation. |
Where the authority changes hands.
Begin with extraction as a proposal, not a write. Preserve the original file and extraction version. Every material value shown to an operator should link back to its page or region. Validate required fields, types, totals, duplicate identifiers, and the current system-of-record value before deciding a path.
Send conflicts, missing fields, poor image quality, and policy-sensitive values to a reviewer. Present the source image next to proposed and current values so the reviewer can correct or reject without trusting a summary. A rejection returns a reason and a resubmission path. An approval records who made the decision.
Only consider straight-through processing for a defined document class and low-risk field set after measuring precision on representative data. A single “confidence above 90%” rule is not a release criterion. Scores can differ by field, document type, and model; some extracted fields may lack a score altogether.
Follow the decision on a phone
- Receive the file, identify its source, and preserve a traceable original.
- Extract values with page and field references, then validate against the authoritative record.
- Route missing, conflicting, or material fields to a reviewer with the source alongside each proposal.
- Commit an approved change against the current record version, or reject and request a corrected document.
What must remain true?
Document boundary
Quarantine uploads, check type and size, apply retention and access rules, and never treat text inside a document as an instruction to the processing system.
Validation boundary
Deterministic checks compare proposed values with policy and the current authoritative record. An extraction score informs review; it does not overrule a failed check.
Write boundary
A controlled API writes only approved fields and checks the record version. A changed record sends the case back to validation instead of overwriting newer work.
Audit boundary
Retain source reference, extraction version, validation results, reviewer decision, record revision, and outcome. Align retention with the actual legal and customer requirements.
Test the decision, not just the diagram.
Contradictory invoice
Use a readable invoice with a purchase-order mismatch. Extraction success must not bypass the exception queue.
Duplicate and resubmission
Resubmit the same file and then a corrected version. The system should detect the duplicate, preserve both histories, and avoid a second unintended write.
Concurrent change
Edit the business record during review. Approval against the old revision must fail and prompt revalidation.
Release gate
Measure errors by field and document class, reviewer corrections, queue age, false acceptance, and the cost of each failure before expanding automation.
This is an illustrative design for education and review, not a verified Ampity client deployment.
Technical guidance: Microsoft Document Intelligence: confidence and human review; Microsoft Azure Architecture Center: choose document-processing technology. These sources inform principles; they do not validate this exact design.
Which boundary is difficult in your system?
Bring the current workflow, its failure cases, and the decision your team must make. We can help compare safe options and define the evidence for production.
Discuss your architecture