Review AI document extraction before records change
Review AI-extracted document fields with source evidence, identity checks, validation, version-specific approval, and a clear correction route.
An extracted field can look convincing and still be wrong. A document may contain several dates, multiple addresses, a subtotal beside a total, or a reference belonging to an earlier transaction. AI can help propose values, but a business record should change only after the process establishes which values belong there and who may authorise the change.
The useful design separates extraction, validation, review, and posting. Each stage has a different purpose. This guide provides a field review matrix and a hypothetical supplier document example, with a pilot that can use synthetic documents before any connection to operational records. It covers administrative record handling, rather than professional accounting, legal, or eligibility decisions.
Define the record you intend to create
Start with the destination record and its required fields. Describe what each field means in that system. An “invoice date,” “service date,” and “received date” are not interchangeable even if all are dates. A total may be tax-inclusive, tax-exclusive, or one instalment of a larger agreement. An extraction task needs these definitions before it can be evaluated.
Create a simple data dictionary with field names, meanings, allowed formats, required status, source expectations, and responsible owners. Identify whether missing values may remain empty or must stop the workflow. Avoid defaulting to today’s date or the first available amount simply to make a record complete.
The small-business data dictionary guide provides a broader structure for defining fields across tools. For extraction, add a source locator requirement: the page, section, label, or text span that supports the proposed value. This makes a review less dependent on the model’s explanation of its own work.
Preserve the source separately from its interpretation
Keep an identifiable source document with a stable reference and an access boundary appropriate to its contents. A proposed extraction should point back to that reference. If the document is replaced, retain the distinction between versions so a reviewer knows which evidence supported an earlier proposal.
Do not treat the extracted text as a perfect copy of the source. Scanned characters, table structure, footnotes, and reading order can be misinterpreted. A page that looks clear to a person can become confusing when flattened into text. Where the task matters, let reviewers inspect the relevant original region, rather than only the AI-generated summary.
Google’s Document AI response documentation illustrates that processing results can include text, entities, confidence information, and anchors into document content. That is a factual example of response structure, not a recommendation to buy a service. Your own review design must determine which evidence is sufficient and how a proposed value becomes an authorised record.
Build a field-level review matrix
Different fields deserve different checks. An exact reference can be compared with a known pattern; an amount can be checked against a calculation; a customer identity may require a match to an existing record. Use the matrix to make those differences explicit before creating an automatic posting path.
| Field type | Useful check | Common ambiguity | Proposed stop condition |
|---|---|---|---|
| Document reference | Present and linked to source | Duplicate or revised reference | Existing record needs investigation |
| Counterparty | Match to approved record | Similar names or trading names | No unique verified match |
| Date | Format and semantic label | Day-month order or multiple dates | Meaning cannot be established |
| Currency | Explicit supported currency | Symbol used in several countries | Currency is inferred without evidence |
| Amount | Arithmetic and labelled total | Subtotal, balance, or instalment | Components do not reconcile |
| Payment instructions | Separate verification route | Changed bank details | Never update from extraction alone |
The table proposes operational checks, not universal accounting rules. Have the appropriate bookkeeper or adviser define posting requirements, tax treatment, and correction methods for your business. A technical field validation cannot settle those professional decisions.
Treat confidence as supporting information
A confidence value can help prioritise review, but it does not establish business correctness. The system may confidently read the wrong total or recognise a name that belongs to the billing address rather than the supplier. A high score does not overcome a missing identifier or a conflicting source.
If confidence is available, evaluate what it means for each field and document type. Do not borrow a single threshold from a demonstration and apply it to every record. A currency ambiguity may be more consequential than a minor description mismatch, even when the description has a lower score.
Use independent checks where the business meaning supports them. Compare allowed currencies, known references, current source versions, and expected totals. Keep an explicit “unresolved” outcome. A workflow that forces every document into a complete record will eventually fill gaps with guesses unless the boundary prevents it.
Verify identity before matching existing records
A name alone is often insufficient to select a customer or supplier. Two businesses may have similar names, and a supplier may have several branches or legal entities. Define which identifiers your team uses to confirm a match, and keep that policy consistent with the information you are authorised to hold.
Do not let an extraction step create a new supplier simply because no close match appears. The right outcome may be a new-counterparty request handled through your established onboarding process. Existing records should not be merged based on a plausible text similarity score alone.
Use the duplicate customer records guide for a careful approach to candidate matching and authorised merges. In the extraction workflow, display candidate matches as candidates. The reviewer must be able to see which source fields support the proposed selection and which differences remain unexplained.
Separate document text from operating instructions
A document is evidence to process, not an authority to change the workflow’s rules. It may contain ordinary instructions addressed to its recipient, such as a payment request, or malicious text intended to manipulate an AI system. Neither should grant the extraction process new permissions.
Define the allowed task outside the document. For example, “Propose these named administrative fields and cite their locations.” The task does not include sending messages, changing bank details, opening arbitrary links, or deleting records. Enforce those limits through the available actions and downstream checks, rather than relying on a document not to ask for more.
OWASP’s Improper Output Handling guidance concerns the consequences of insufficiently validating model output before downstream use. The practical point for this workflow is to treat extracted content as untrusted input to the next stage. A well-formatted result still needs appropriate business and technical checks before it can affect records.
Work through a hypothetical supplier document
Imagine a small service business receiving a supplier invoice for equipment rental. The document contains an invoice number, an issue date, a rental period, a subtotal, tax lines, an amount already paid, and a remaining balance. The business is testing extraction using a synthetic version of this layout.
The first proposal selects the full invoice total as the amount outstanding. The arithmetic check shows that the stated deposit has not been considered. The workflow pauses and presents the invoice total, deposit, remaining balance, and their source locations. It does not overwrite an existing balance merely because one field is labelled “total.”
The reviewer also sees a note announcing changed bank instructions. That information is routed to the established supplier verification process. It is excluded from the ordinary field approval. The review packet states that approving administrative extraction does not approve payment or a bank detail change.
After checking the source and destination definitions, the reviewer approves the appropriate proposed fields for a draft record. The authorised accounting process determines posting and payment handling. The record retains the source reference, reviewed version, reviewer, and decision. This hypothetical case demonstrates the separation of stages, not a tested integration or an accounting treatment suitable for every business.
Keep approval tied to the exact proposed change
Show reviewers both the current record and the proposed value when an existing record would change. A screen that displays only the new value can conceal an important overwrite. Make additions, corrections, and removals distinguishable. If the proposal changes after review, it should return for the relevant approval rather than inheriting an earlier decision.
Record who approved which fields and under what authority. One person may verify the document reference while another resolves a commercial discrepancy. Avoid a generic green “approved” badge that implies every part of the transaction has been checked. A field review, an accounting approval, and payment authorisation are different events.
Provide a clear rejection path. A reviewer should be able to mark an unreadable document, a duplicate, or an unsupported document type without inventing a corrected value. The invoice approval process guide connects field evidence with the broader administrative review of supplier invoices.
Plan for duplicates and revised documents
A customer or supplier may send the same file twice through different channels. The second copy should not automatically create a second operational record. Use source fingerprints where appropriate, along with meaningful business identifiers and review rules. A changed file with the same reference may be a revision rather than a duplicate.
Document how revisions supersede earlier proposals. If a corrected document arrives before posting, the pending extraction can be replaced with a new version while retaining the history. If it arrives after posting, the authorised correction process should decide what happens. Do not erase an earlier approved transaction just to make the extraction queue look tidy.
An uncertain processing result also needs investigation before retrying a record creation. The system may have written a draft even though the response was interrupted. Verify the destination using a stable case reference before repeating an action that could create a duplicate. Keep technical retries distinct from a reviewer’s decision about the document’s meaning.
Pilot across layouts and failure cases
Create a synthetic sample set that represents the documents you expect: clean digital files, scans, multi-page documents, tables, changed layouts, missing fields, and revised copies. Include documents the workflow should refuse or route to review. Record expected field values and expected stop reasons before running the test.
Measure correctness at the field level as well as the document level. A document with nine correct fields and one wrong currency may be unusable. Track unsupported values, missing evidence, incorrect matches, duplicate drafts, and review time. Separate ordinary extraction errors from failures of the approval boundary.
Have a reviewer use the packet without guidance from the designer. Can they find the source region quickly? Can they see what will change? Can they leave a field unresolved? The workflow is not ready for greater volume if a person must reconstruct every proposal from scratch or if a polished interface hides the underlying uncertainty.
Create a correction route before the first posting
Plan what happens when an error is discovered after a draft or record has been created. Identify who can stop further processing, how the affected record is located, and who decides the authorised correction. The extraction team should be able to supply the original source and proposal, but should not invent a financial adjustment or delete evidence to conceal the error.
Use a correction case linked to the original processing reference. Record the field in question, the value originally proposed, the evidence that raised the concern, and the current operating state. If an external message or payment-related step may already have occurred, make that uncertainty explicit so the owner checks its actual status before repeating anything.
Test a hypothetical wrong-currency case. A synthetic document uses a symbol shared by several currencies, and the initial proposal selects one without enough evidence. If a reviewer catches it before record creation, the proposal should remain unresolved. If it is found after a draft exists, the correction route should identify that draft and prevent it from advancing. If a posted record is affected, the qualified finance process determines the response.
Also decide how a confirmed defect becomes a regression case. Preserve the problem’s structure with synthetic values and add the expected stop condition. Keep a short link from the correction record to that test improvement. This closes the operating loop: the team can explain the original event, apply the authorised response, and check that future releases handle the same ambiguity more appropriately.
Give corrected cases a final completion check. Confirm that the authorised destination reflects the decision, pending actions use the corrected version, and affected operators know which source now applies. A correction is incomplete if the register looks right while an older proposal remains scheduled for later processing.
Maintain a useful exception log
Record error categories that lead to an action: ambiguous total, unsupported layout, missing reference, identity conflict, unreadable source, duplicate candidate, or changed payment instructions. Avoid retaining unnecessary sensitive content in the log. Link authorised staff to the restricted source instead.
Review recurring categories with the process owner. A missing field may require better document intake instructions. A particular layout may need its own handling rule. A high volume of unresolved identities may show that your supplier records need maintenance. Do not assume that every issue requires a more capable model.
Keep the extraction rules, test cases, and destination definitions versioned together. When a model, layout, or field mapping changes, rerun the relevant cases. Start with draft-only operation and expand only after the team can explain normal results, exceptions, and corrections. The useful outcome is a defensible proposed record with evidence, rather than simply a fast stream of populated fields.
Sources and editorial method
Primary sources checked on October 15, 2026: Google Cloud: handling Document AI processing responses and OWASP: LLM05:2025 Improper Output Handling. The field matrix, hypothetical invoice, review sequence, and pilot are original practical analysis. No provider account is required to use the worksheets. Posting, tax, legal, and payment decisions remain with appropriately authorised people.
