Check whether AI copied every invoice line by matching each visible line in the scanned PDF to an extracted row, then checking fields and arithmetic. Use the scan as the evidence, not the AI output as its own answer key. A matching total is useful, but it cannot establish that descriptions, quantities and individual lines are complete.
The proposed workflow below prepares a finance review pack. It does not approve an invoice, determine its tax treatment or authorise payment.
1. Establish which pages and lines belong to the invoice
Start with a complete, readable source file and an agreed definition of an invoice line. Without that definition, two people can produce different counts from the same scan.
Keep the original PDF unchanged. Record its file reference, invoice identifier, supplier name and page count. Check page order, clipped margins, faint printing and continuation pages. If a page is unreadable or missing, hold the completeness decision and request a better copy.
For this proposed process, count separately listed goods, services, charges and credits as source lines. Treat a wrapped description as part of its parent line. Record subtotals, VAT summaries and carried-forward amounts separately, rather than counting them as purchased items.
An invoice that combines several deliveries may repeat headings or descriptions. Those repetitions are not automatically duplicates. Give each source line a location, such as a page number and table-row reference, before comparing the output.
Ask the person counting the scan to work independently of the extracted row count. Otherwise, the output can influence what they notice on the page.
2. Extract fields without discarding their evidence
Keep the original text and its location alongside each interpreted value. A clean spreadsheet without source references makes checking slower and leaves corrections difficult to explain.
Microsoft describes text, table and document-structure extraction in its Source: Azure Document Intelligence overview. Google similarly describes transforming documents into structured fields and returning extracted information in Document objects in its Source: Document AI overview. These capabilities support extraction; they do not establish that a particular invoice was copied completely.
A proposed row record should contain:
- Source file reference, page and row location.
- Raw description and any item code.
- Raw quantity, unit price, discount and line amount.
- Normalised numeric values, with currency recorded separately.
- A field status: present, not printed, unreadable or uncertain.
- Extraction version and any subsequent correction reference.
Use page crops or coordinates where available. Otherwise, create a manual page-and-row reference. Never claim that a locator came from the extraction tool if a reviewer added it.
This is the evidence-preservation part of document processing, not simply a request to return invoice text.
3. Match source lines and output rows in both directions
Check both that every source line has an output row and that every output row has a source line. Equal counts are not enough: one omitted line and one duplicate can cancel each other out.
Create a matching register with source location, extracted row identifier and match status. Walk down each page in reading order. Confirm the description, item code where printed, amount and position. Then walk through the extracted rows to identify anything unsupported by the scan.
Use proposed statuses such as matched, missing, unexpected, merged, split and uncertain. A merged result may combine two purchased items into one row. A split result may turn a wrapped description into two apparent items. Both need correction or an explicit explanation.
Check the top and bottom of each page carefully. Keep carried-forward amounts separate from new charges, and connect continuation text to the correct parent line.
A proposed completeness rule is that every source line needs an explained mapping and every extracted row needs evidence. Unresolved mappings should remain exceptions, even when the invoice total agrees.
4. Check missing fields and suspicious interpretations
Judge field completeness against what the invoice actually prints, not against a template that assumes every supplier uses the same layout.
If a service invoice prints only a description and amount, an absent quantity may be legitimate. If the scan clearly prints a quantity but the output omits it, that is an extraction defect. Keep those cases distinct.
Review blank descriptions, truncated item codes, shifted columns, missing minus signs and decimal separators. Preserve the raw string before converting it to a number. Do not silently change an uncertain character because another value would make the arithmetic work.
If a model formats the extraction as JSON, a schema can require keys and data types. Source: OpenAI's Structured Outputs guide describes schema-constrained responses. Format compliance is not evidence that every source row or value is correct.
Allow explicit unknown values rather than forcing guesses. For any inferred value, record the derivation separately from copied values. A reviewer should be able to distinguish what the supplier printed from what the process calculated.
5. Recalculate amounts using the invoice's stated basis
Reconcile line arithmetic and document totals separately. Each check answers a different question, and neither replaces the source-to-row comparison.
Where the printed fields support it, calculate quantity multiplied by unit price, then apply the stated discount or adjustment. Compare that result with the printed line amount and the extracted amount. Use decimal arithmetic rather than relying on model-generated calculations.
Next, sum the relevant lines and compare them with the printed subtotal. Reconcile separately listed delivery charges, credits, VAT and other adjustments to the invoice total. First establish whether the amounts are presented as tax-inclusive or tax-exclusive. Do not add tax twice or impose a tax treatment that the document does not explain.
Record each difference, even when small. Any rounding tolerance is a proposed business rule that finance must define and justify against the supplier's calculation basis. It must not excuse missing lines.
Keep a distinct field for unresolved tax presentation. Appropriate finance or tax judgement is required before drawing conclusions about correctness beyond faithful extraction.
6. Route exceptions with a named owner
Hold uncertain evidence for a person who can resolve it, rather than asking the model repeatedly until it produces a convenient answer.
Assign extraction defects to the document-checking reviewer. Assign unclear amounts, discounts and tax presentation to finance. Request a clearer invoice from the supplier when the source itself is unreadable. Record the question, source location, owner, action and resolution evidence for each exception.
Preserve the first extraction. Store corrections as a separate version with before-and-after values, the reviewer's name and a reason. If extraction is rerun, compare versions instead of silently replacing the earlier result.
Fixed checks and exception routing may be sufficient. The resource on AI agents versus automation can help frame that design choice. If adaptive handling is proposed, the custom AI agents workflow resource is relevant background, not proof that an agent is necessary.
For terminology, the glossary entry for a custom AI agent provides a separate reference. Neither approach should receive invoice-payment authority through this checking workflow.
7. Assemble the pack and evaluate the checking method
Mark extraction ready for finance review only when mappings, fields and reconciliation are explained, or clearly label the pack as incomplete.
Include the original scan, extracted rows, matching register, arithmetic worksheet, exception log and correction history. Show unresolved questions prominently. Record who checked the source and what they checked. An extraction-ready status must not look like finance approval.
Before relying on the proposed process, evaluate it against a reviewer-created reference set covering clear scans, faint pages, wrapped descriptions, credits and continuation tables. Compare exact source-line recovery, unsupported output rows and field accuracy. Record arithmetic agreement separately.
Review failures by layout and scan condition, rather than reporting only a single average. A method that handles simple invoices but loses continuation lines needs a specific restriction or further work. Human-reviewed examples can inform acceptance rules; vendor capability alone cannot demonstrate outcomes.
This checking stage can sit within broader AI automation, but ledger posting and payment controls are separate decisions.
Reusable line-level extraction checklist
Use this proposed checklist for each invoice. Mark every item Pass, Exception or Not applicable, and record evidence for exceptions.
Invoice reference: ____ Source file: ____ Reviewer/date: ____
- All pages are present, ordered and readable; missing pages are flagged.
- Source lines are counted independently, with wrapped descriptions and summaries treated consistently.
- Every source line maps to an extracted row or a documented exception.
- Every extracted row maps back to a source location; unsupported rows are flagged.
- Descriptions, item codes, quantities, prices, discounts, signs and amounts match where printed.
- Blank fields distinguish not printed, unreadable and extraction missing.
- Raw text remains available alongside normalised values and currency.
- Merged, split and possible duplicate rows have an evidence-based resolution.
- Line calculations agree or have a recorded explanation.
- Subtotal, adjustments, tax presentation and total reconcile on the stated basis.
- Corrections retain original values, reviewer details and reasons.
- Unresolved exceptions have owners and next actions.
- The pack includes the scan, rows, mappings, calculations and exception history.
Disposition: Ready for finance review / Incomplete, hold for clarification.
Boundary: This records extraction checking, not invoice approval or payment authority.
Hypothetical walkthrough: a match, an omission and a duplicate
Apply all three checks together: row mapping, fields and arithmetic. The following invoice and every amount are hypothetical.
Suppose a two-page invoice shows four source lines: two boxes at R100 each, one service at R300, delivery of R50 and a credit of R20. The printed subtotal is R530. A separately printed hypothetical tax amount of R79.50 produces a total of R609.50. This illustrates reconciliation, not a tax determination.
In the normal case, the output contains all four rows, including the negative credit. Each row points to its source location. The reviewer checks the fields, calculates R200 + R300 + R50 − R20, and records agreement with the printed totals.
Now suppose delivery is omitted and the credit is copied as positive R20. The extracted sum becomes R520. The reviewer identifies two defects, not merely a R10 discrepancy. They restore delivery from the scan, correct the credit sign with evidence and retain the original output.
In another variant, the output omits delivery but duplicates the service row. Equal row counts still fail the two-way mapping. The reviewer removes the unsupported copy and restores the missing delivery through recorded corrections. If the credit sign is illegible, they hold that field and request clarification rather than choosing the sign that balances the total.
Frequently asked questions
Use the source evidence to resolve these questions, not the apparent neatness of the extracted table.
Can we trust the extraction if its total matches the scanned invoice?
No. A matching total supports arithmetic agreement, not complete copying. An omitted line and an incorrect extra row can offset each other, while descriptions or quantities may still be wrong. Match every source line to an output row and trace every output row back to the scan. Keep the total check as a separate part of the review, not a substitute for that mapping.
What should we do with a description that continues onto the next page?
Link the continuation to its parent source line after checking the page sequence and table layout. Preserve references to both page locations. Do not count continuation text as another purchased item unless the scan supports that interpretation. If the output splits it into separate rows, record a merge correction. Where the relationship remains unclear, leave an exception for the reviewer rather than assuming the nearest row is correct.
Should we fill in a missing quantity from the line amount and price?
Not as though it was copied from the invoice. If quantity is not printed, record that status. A calculation may suggest a quantity, but it remains derived information and needs a separate label and human review. If quantity is printed but unreadable, request a clearer source or clarification. Never use a mathematically convenient value to hide an unresolved extraction gap.
If your business needs help defining this evidence trail and exception handling, get in touch with Symaxx to discuss a scoped document-processing workflow. Start with representative invoices and proposed review rules, then evaluate the approach before depending on it.