An AI can read an invoice. Who checks what it read?

Start with the document, not the confidence badge

A supplier invoice arrives as a phone photograph. AI reads the amount correctly, turns an O into a zero in the invoice reference, and copies unfamiliar bank details into a tidy table. The output looks more trustworthy than the source because it is easier to read.

That is precisely when review needs to become more specific. Ask whether each important field came from the correct location, whether its meaning is clear, and whether the proposed record agrees with records your business already trusts. A model confidence score cannot answer all three questions.

This guide uses a fictional invoice and a suggested review process. It is not a tax guide or a claim about a DLVX client's finance workflow. The goal is a record a reviewer can accept, correct or hold without reopening the entire task from scratch.

The invoice and the first extraction disagree

Our fictional document shows supplier Somchai Office Supplies, reference SO-017, ten units at THB 800 and a THB 200 delivery charge. The displayed total is THB 8,200. The image is clear enough to read the amounts but the invoice-reference typeface makes O and zero difficult to distinguish. The payment account differs from the approved supplier record.

The amount can be correct while the record remains unsuitable for approval. Mark the reference as unresolved and the payment destination as requiring independent verification. Do not call the whole invoice “verified” because one total matches.

Design the output around the reviewer's questions

For each field, retain the proposed value, the source page or region, any transformation and the review status. Put the original invoice beside the fields when the interface permits it. A reviewer should be able to move from THB 8,200 to the printed total without searching a folder.

Keep supplier and customer identifiers separate. Keep invoice date, due date and service period separate. Preserve the original currency notation. If the source contains a tax amount, capture what is printed without deciding its treatment. Ask the appropriate finance owner to supply rules for posting and tax classification.

For a multipage invoice, confirm all pages are present before deciding that line items reconcile. A missing second page may contain credits or delivery charges. Record a missing field as missing, not zero, and an inferred due date as inferred rather than printed.

Microsoft documents invoice-field and line-item extraction. That capability is useful, but it is separate from the approval process proposed here.

Use four checks with different owners

Identity: match the supplier to a known record using the appropriate identifiers. A familiar display name is insufficient when suppliers share similar names. Preserve an unrecognized supplier as an exception.

Arithmetic: recompute the document's stated line calculations and total with ordinary formulas. Apply the organization's agreed rounding rules. Record the difference instead of asking a model to explain it away.

Commercial basis: compare the charge with the purchase order, accepted quote or delivery evidence. An invoice can be mathematically perfect for goods nobody ordered. In our example, the THB 200 delivery charge needs the relevant agreement.

Payment destination: compare it with the approved supplier record. A changed account needs the organization's established verification process using trusted contact information. Do not let a reply to the same suspicious message serve as the only confirmation.

Different people may own these checks. The record should show who accepted each one, rather than compressing everything into a green tick.

Show what changed and what stayed on hold

The reviewer consults the original supplier portal and confirms the invoice reference is SO-017. The proposed field changes from S0-017 to SO-017, with a note identifying the confirming source. A search using the corrected reference reveals the invoice is already in the review queue. The workflow should attach the newly received image to the existing matter according to policy, not create another payable item.

The bank mismatch remains unresolved. Correcting the reference does not authorize a new payment destination. The useful output is: “Duplicate arrival linked to existing review. Total reconciles. Delivery charge accepted against the quote. Payment destination change remains on hold with the finance owner.”

This is why independent review states matter. One corrected field should not erase another unresolved issue. A system that offers only accepted or rejected forces staff to hide useful partial work or approve too much.

Test the ugly documents before expanding

Use a small permissioned set with known outcomes: a clean PDF, poor photograph, rotated page, multi-page invoice, credit note, repeated arrival, missing currency and a changed bank account. Include the languages and layouts your suppliers actually send. Thai text recognition in one tool does not establish that a particular invoice parser supports every Thai document.

Count reviewer minutes, field corrections and destination errors. Keep serious errors separate from cosmetic ones. If a failed run returns no record, include it in the results. Otherwise the system can appear accurate by dropping difficult invoices.

Inspect the saved draft in the destination system, including its attachment and status. Extraction success followed by a duplicate accounting entry is still a failed workflow. Retain a manual route for any document the process cannot handle.

A useful instruction for your first invoice trial

Extract proposed fields from this permissioned invoice.
For each important field return:
printed text | proposed value | source location | review state.
Separate printed values from inferred values.
Do not infer missing currency, dates or identifiers.
List arithmetic discrepancies and ambiguous characters.
Compare only with the approved records supplied here.
A changed payment destination must remain an exception.
Output a draft review record, never payment authorization.

Take one invoice already settled by your team, remove unnecessary personal information, and compare the proposed record with the accepted one. Ask the reviewer which field took longest to verify. Improve that source-to-field connection before processing a larger batch.

Sources and dates

Sources checked on 20 October 2026. Worked examples are teaching examples unless explicitly attributed. Provider documentation describes product behaviour; the operating recommendations are DLVX editorial judgement.

• Microsoft: Document Intelligence invoice modelDocumented extraction of invoice fields and line items, distinct from our proposed review and approval process. Checked 2026-10-20.