AI can prepare a three-way invoice match by extracting purchase order, delivery note and invoice lines, linking likely equivalents and calculating differences. Finance should receive a source-linked match-exception pack, not an unexplained approval recommendation. Missing documents, unclear units and suspected duplicates remain open for human review.
The proposed workflow below covers preparation only. It does not authorise an invoice, post an accounting record or release payment. All example records and amounts are hypothetical; all operating rules are proposals for finance to adapt.
1. Define what finance is being asked to approve
Start by defining the evidence needed for a reviewer to decide whether the invoice agrees with the order and accepted delivery. A three-way match needs more than three files with similar totals.
The purchase order records what was ordered. The delivery evidence records what arrived and, where separately recorded, what was accepted. The invoice records what the supplier is charging. A delivery note alone should not be treated as proof that your receiving team accepted every item.
For a first scope, consider goods purchases with identifiable item lines. Keep service invoices, deposits, non-PO purchases and disputed deliveries on separately defined review routes rather than forcing them into a goods-matching template.
Assign responsibilities before configuring extraction:
- Accounts payable assembles documents and checks invoice identity.
- Procurement resolves order, price and item-substitution questions.
- Receiving confirms accepted quantities, returns and shortages.
- Finance makes the approval decision and handles accounting and tax judgement.
This is a focused accounting automation use case. Its deliverable is a review pack, not a replacement for your approval policy.
2. Collect the evidence and preserve document identity
Collect the original documents and reliable system records before asking AI to link anything. Preserve their identity so that a reviewer can reopen the exact evidence used.
For each file, retain a document ID, filename, document type, version, intake time and controlled storage reference. Keep purchase order revisions distinct. A superseded order may explain a difference, but it should not silently replace the current authorised version.
At header level, capture supplier identity, invoice number, document dates, PO reference and currency. Use the supplier master record to check identity rather than relying only on a trading name extracted from a PDF. Restrict document access and retention according to a policy reviewed by the appropriate security and legal owners.
If accounting records are part of the evidence, validate the integration separately. The Source: Xero Accounting API definition includes invoice records with contacts and line items, and examples containing quantity and unit amount. That supports field-mapping investigation, not a claim that Xero natively performs this proposed match.
Also distinguish “no record found” from “lookup failed”. An unavailable system is not evidence that an invoice has never been recorded.
3. Extract lines without hiding uncertainty
Extract each line into a consistent record while retaining the original text and its location. Normalisation should make comparison possible without erasing evidence.
Useful fields include item code, description, quantity, unit of measure, unit price, discount, line amount, tax shown and currency. Record accepted quantities separately from quantities printed on the supplier’s delivery note. Use a missing value rather than zero when a field cannot be read.
For every material value, retain the document ID and page plus row or table location where available. A reviewer should be able to inspect the quantity or price without searching the entire attachment.
Source: Azure Document Intelligence documentation describes text and table extraction, prebuilt invoice extraction and custom extraction models. Those capabilities can supply inputs; the matching logic remains a separate proposed application. Verify the selected model, API version and regional availability before choosing it.
If model output is converted into a fixed record format, Source: OpenAI structured outputs can constrain its schema. A valid structure does not establish correct extraction. Incomplete responses and refusals also need an explicit failure route, never a default “matched” status.
4. Link lines before calculating agreement
Propose line links using strong identifiers first, then send uncertain alternatives to a person. Similar wording alone is not enough to establish that two lines represent the same goods.
A proposed matching sequence is:
- Check supplier identity, PO reference and currency.
- Link exact PO line references or approved item codes.
- Apply an approved supplier-to-internal item mapping if one exists.
- Use descriptions to suggest remaining candidates.
- Flag multiple plausible candidates rather than choosing silently.
Units deserve their own check. “One carton” and “twelve units” can agree only if an authorised conversion supports that relationship. AI should not invent pack sizes from the description.
Retain one-to-many relationships where an invoice line covers several deliveries. Record which receipt quantities have already supported earlier invoices, so that repeated use of the same delivery evidence can be identified. Treat returns and credit notes as linked records, not unexplained negative adjustments.
A custom AI agent may coordinate evidence retrieval and candidate matching, but its authority should remain limited. The guide to custom AI agent workflows provides a useful starting point for defining that boundary.
5. Calculate differences with explicit comparison rules
Use deterministic calculations for quantities and amounts after the line links are established. AI can explain a difference, but it should not decide the arithmetic or invent a tolerance.
For each linked line, calculate the proposed checks below:
- Invoice quantity against accepted, not-yet-invoiced receipt quantity.
- Cumulative invoiced quantity against the current authorised order quantity.
- Invoice unit price against the agreed PO price on the same basis.
- Invoice line amount against quantity multiplied by price, adjusted for documented discounts.
- Sum of lines against the invoice subtotal and stated total.
Compare like with like. Separate tax-exclusive amounts, tax shown and tax-inclusive totals. Put currency mismatches, unclear discount treatment, extra freight and disputed tax treatment into distinct exceptions. A finance or tax professional must decide the relevant treatment; matching software cannot establish tax entitlement.
A proposed starting rule is exact agreement for quantities and prices, with any rounding allowance separately approved and recorded. A tolerance should specify its scope, currency and calculation basis. Passing it changes the presentation status only, not the approval authority.
The distinction between AI agents and automation matters here: flexible interpretation and fixed calculations serve different purposes.
6. Route exceptions to someone who can resolve them
Route each exception with a reason, evidence and a specific question. “Mismatch found” is not enough for useful human handling.
For missing delivery evidence, ask receiving to confirm accepted quantities and supply the record. For a price difference, ask procurement whether a documented change exists. For an unclear unit conversion, ask the item-data owner to confirm the conversion and its source.
Suspected duplicates need their own route. Compare supplier identity and invoice number, then inspect dates, amounts, files and existing accounting records. Similarity is a reason to investigate, not proof of a duplicate. Accounts payable should decide whether a second submission is a copy, replacement or genuinely separate invoice.
Retain every unresolved exception even if another check passes. Equal invoice and PO totals do not cancel a missing receipt or ambiguous item link.
When evidence changes, create a new pack version and recalculate affected lines. Preserve the earlier version and record what changed. Any approval decision must refer to the reviewed version. Security owners should approve access controls, and finance should define who may resolve an exception versus who may approve the invoice.
7. Build and evaluate the finance review pack
Build the pack so that finance can reproduce each material finding from the source documents. A concise summary should sit above a detailed line table, with unresolved questions visible first.
Use the reusable template below as a proposed minimum. Replace bracketed fields, repeat the line table for every invoice line and attach controlled references rather than unrestricted public document links.
Proposed match-exception pack template
Pack identity: [pack ID], [version], [prepared date], [preparer], [finance reviewer].
Invoice identity: [supplier master ID], [supplier name], [invoice number], [date], [currency], [total].
Evidence register: [invoice ID/version/reference], [authorised PO ID/version/reference], [receipt IDs/references], [prior invoice and return references]. Mark missing evidence explicitly.
| Line | PO / receipt / invoice references | Ordered / accepted / previously invoiced / current invoice quantities | Unit and conversion source | PO / invoice price | Amount difference | Status and reason |
|---|---|---|---|---|---|---|
| [item] | [document, page, row] | [four quantities] | [unit; approved mapping] | [same-basis prices] | [currency; calculation] | [ready for review / exception / unresolved] |
Exception record, repeated per issue: [type], [observed values], [source references], [proposed rule/version], [owner], [question], [required evidence], [resolution and resolver].
Summary checks: [line-to-total reconciliation], [tax basis and review question], [duplicate-search coverage/result], [missing or ambiguous links].
Finance decision: [pending / approved / held / returned], [reviewer], [timestamp], [reason], [pack version reviewed]. Approval remains a human decision; payment is outside this pack.
Completion checklist: Every line accounted for; material values traceable; calculations reproducible; unresolved issues visible; owners assigned; document access checked; reviewed version retained.
Evaluate the proposal against packs assembled independently by finance. Include partial deliveries, changed POs, repeated submissions, unclear scans and mixed units. Record incorrect links, missed exceptions, unnecessary exceptions, missing references and reviewer effort. Set acceptance criteria before evaluation. Potential benefits remain conditional on those results, not on vendor capability alone.
Worked walkthrough: matching and unresolved evidence
A normal case should show why the quantities agree; an exception case should show precisely why finance cannot yet decide. The following records, identifiers and amounts are hypothetical, with amounts shown exclusive of tax to isolate matching arithmetic.
PO P-410 orders 100 filters at R80 each. Receipt D-22 records 60 accepted filters. Invoice I-73 charges for 60 filters at R80, giving R4,800. No previous invoice has used that receipt.
The proposed pack links the item codes and records 100 ordered, 60 accepted, zero previously invoiced and 60 currently invoiced. The quantity and price differences are zero. It labels the line “ready for review”, with references to each document’s line. The remaining 40 ordered filters are not a shortage on this invoice. Finance still checks the invoice’s other details and decides whether to approve.
Now suppose I-74 charges for the remaining 40 filters, but no accepted receipt is available. The pack records an unsupported quantity of 40 and asks receiving for evidence. It must not infer delivery from the PO balance.
If I-73 arrives again as a renamed attachment, the pack flags a suspected duplicate and links the earlier submission. Accounts payable checks whether it is merely a copy. If the new invoice instead says “five cartons” with no approved pack conversion, the quantity remains unresolved until procurement or the item-data owner supplies the mapping.
FAQs
Can finance review an invoice covering several delivery notes?
Yes, provided the pack links each invoice line to the relevant accepted receipts and shows their combined available quantity. Keep receipt IDs and earlier invoice allocations visible. Do not collapse several deliveries into one unexplained total. If an allocation is uncertain, receiving and accounts payable should resolve it before finance relies on that match. The pack should also distinguish quantities delivered from quantities accepted.
What should happen when the invoice has no PO number?
Keep the PO link unresolved. AI may suggest candidates using supplier identity, item codes and dates, but procurement should confirm the correct authorised order. If the purchase genuinely has no PO, use your separately approved non-PO review route. Do not manufacture a PO relationship just to complete the three-way table. Retain the missing reference and the human resolution in the pack.
Does a clean three-way match prove the invoice can be paid?
No. It supports a limited comparison of order, receipt and invoice evidence. Supplier legitimacy, bank-detail changes, tax treatment, approval authority and payment controls require appropriate human judgement and separate processes. “Ready for review” should never mean “approved for payment”. Keep the decision record attached to the exact pack version so that later document changes cannot silently inherit an earlier approval.
If your business needs help defining this review pack, Symaxx’s AI automation service is a place to discuss the preparation workflow. Get in touch with representative documents and your approval rules, using a suitably secure sharing method.