Why three-way match exceptions pile up
A three-way match exception is an invoice your ERP will not release for payment because it disagrees with the purchase order, the goods receipt, or both. At multi-site organisations most of these exceptions have ordinary causes: a receipt nobody entered at the branch, a partial delivery, a price that moved, a unit of measure that differs, a freight line that was never on the PO, or the same invoice sent twice. An AI agent working inside your finance system can investigate the routine ones and propose the fix, while your AP team approves every release.
The queue usually becomes visible the wrong way. A supplier rings the CFO, a branch manager complains that a vendor has put the account on stop, or month-end accruals swing because nobody knows which invoices are genuinely owed.
This guide is for the finance leader, AP manager or CFO at a multi-site organisation in construction, wholesale, facilities, health or manufacturing. It covers why the documents stop agreeing, what the exception queue costs in practice, and how to clear the routine share without loosening the control that three-way matching exists to provide.
What three-way matching is checking
The match compares three records before an invoice is paid:
- The purchase order: what you agreed to buy, at what price, in what unit.
- The goods receipt: what arrived, entered by the person who took delivery.
- The supplier invoice: what the supplier says you owe.
If quantity and price agree within the tolerances finance has set, the invoice is cleared for approval and payment. If not, it goes on hold. Two-way matching drops the receipt and compares only the PO and the invoice, which is common for services where nothing physical arrives.
Business Central, NetSuite, MYOB Acumatica and SAP Business One all hold purchase orders and receipts that an invoice can be checked against. Organisations on Xero usually add an AP tool that does the matching outside the ledger. The exception queue looks much the same in all of them. The software flags the mismatch. Working out why it happened, and who has to fix it, is still done by a person.
For the wider picture of how invoices get into the system in the first place, our guide to automating invoice processing with AI covers capture, coding and approval. This post starts where that one stops: the invoice is in the system, and it will not match.
The six causes behind most exceptions
Each cause has a different fix and a different person who can make it. That is why a single "exceptions" bucket is so slow to clear.
Receipts not entered at the site
The goods arrived. The delivery docket is in a tray at the branch, in a site donga, or in a ute. Nobody keyed the receipt into the ERP, so the invoice has nothing to match against. In organisations with many sites this can be the largest single cause, because receipting depends on whoever happened to sign for the delivery.
Partial deliveries and back orders
The PO was for 200 units, 150 arrived, and the supplier invoiced 200. Or the supplier invoiced 150 correctly, but the receipt was entered against the wrong PO line. The match fails on quantity even though everyone acted in good faith.
Price variances
The supplier applied a new price list, a surcharge, or a contract rate that differs from the PO. Some variances are legitimate and pre-agreed. Others are errors, and some are the only signal that a rate has drifted away from what procurement negotiated.
Unit of measure differences
The PO says "each", the invoice says "carton of 12", and the receipt says 48. All three may describe the same delivery. A simple comparison sees three different numbers.
Freight, fuel levies and other charges not on the PO
A freight line, a pallet charge, a small-order fee or a fuel levy appears on the invoice and nowhere else. The goods match perfectly and the invoice still fails.
Duplicate invoices
The supplier emails the invoice, then posts it, then sends a statement with the same invoice number, or sends a corrected version with a new number. If AP pays both, recovering the money takes longer than processing the invoice did. Duplicates also overlap with payment redirection fraud, where a fake or altered invoice asks for payment to new bank details.
| Why the match fails | What clears it | Impact | |
|---|---|---|---|
| Receipt not entered | Invoice has nothing to match against | Site confirms delivery from the docket; receipt entered | Site |
| Partial delivery | Invoiced quantity exceeds received quantity | Pay what arrived; hold the balance or request a credit | AP and site |
| Price variance | Invoice price differs from the PO | Check the contract or price list; accept, query or reject | Procurement |
| Unit of measure | Each versus carton versus pallet | Convert using the supplier's pack size and re-match | AP |
| Freight or levy line | Charge on invoice, not on PO | Apply the agreed freight rule or ask the buyer | AP or buyer |
| Possible duplicate | Same supplier, number or amount seen before | Block and link to the first invoice; confirm with the supplier | AP |
What the exception queue costs finance teams
The cost is mostly time and supplier trust, and it rarely shows up as a line in the budget.
AP time goes first. Every exception means opening the PO, finding the receipt, emailing a branch or buyer, waiting, and coming back to it. The ATO's eInvoicing guidance puts the cost of processing a paper or PDF invoice at between $27 and $30, against less than $10 for an eInvoice. That is the cost of an ordinary invoice. An exception adds investigation time on top.
Suppliers are paid late. An invoice on hold is an invoice that ages. For reporting entities under the Payment Times Reporting Scheme, that delay is no longer private. The scheme requires reporting entities, mostly large businesses with annual consolidated revenue of $100 million or more under accounting standards, to report every six months on their payment terms and actual payment times to the suppliers the scheme covers. Reports go to the Payment Times Reporting Regulator and are published on the public Payment Times Reports Register. Each report is due within three months of the end of its six-month period.
Month-end gets harder to close. Goods received but not invoiced, and invoices received but not matched, both distort accruals. The longer the queue, the less confident the controller is in the AP balance.
Fraud exposure rises. The ATO's eInvoicing page cites the National Anti-Scam Centre: more than $166 million was lost to payment redirection and false billing scams in 2025, compared with $152 million in 2024. A tired team clearing a long queue is more likely to wave through a changed bank account or a near-duplicate.
- ATO: typical cost to process a paper or PDF invoice$27 to $30
- ATO: cost to process an eInvoiceLess than $10
- National Anti-Scam Centre via the ATO: lost to payment redirection and false billing scams, 2025More than $166 million
- Payment Times Reporting Scheme: reports per reporting entity each year2 (six-month periods)
- Payment Times Reporting Scheme: deadline after each period ends3 months
These outside figures give a CFO context. The figure that matters is your own: how many exceptions arrived last quarter, by cause, and how long each one sat before it was cleared.
Why the queue grows faster at multi-site organisations
A single-site business can fix most exceptions by walking to the loading dock. A business with 20 branches, project sites or hospital wards cannot.
Consider a typical wholesale distributor with branches across two states and one central AP team. Each branch receives deliveries differently. One receipts on the handheld scanner when the truck is unloaded. Another stacks dockets and receipts on Friday. A third has a new storeperson who does not know the receipting screen exists. The central team sees the result as exceptions, with no view of which branch, which supplier or which habit is causing them.
Construction adds another layer. Materials arrive at a site, the docket is signed by a subcontractor's leading hand, and the PO was raised by a project buyer in head office. Before that invoice can be released, someone has to reach all three. Health and facilities management see the same pattern with consumables and maintenance call-outs spread across many locations.
Every site does it differently, and the central team absorbs the difference.
Exceptions investigated before anyone opens them
The useful job for AI in a three-way match process is investigation and proposal. The ERP already does the arithmetic of the match. What it cannot do is read the docket photo a site manager emailed, recognise that "CTN12" on the invoice and "EA" on the PO describe the same 48 units, or notice that a freight charge matches the rate in the supplier's contract.
An AI agent working inside your ERP or finance system can do that groundwork for each held invoice:
- read the invoice, the PO lines, any receipts, and the supplier's price list or contract terms;
- check the site's email or shared folder for a delivery docket against that PO;
- classify the exception by cause, using the six categories above or your own;
- propose the fix with the evidence attached, such as "receipt for 150 units found on docket 4471, partial delivery, pay 150 and hold 50";
- route anything it cannot explain to the right person: the site, the buyer or procurement.
A person in AP approves each proposed release. The agent never pays a supplier and never changes bank details. It prepares the decision, so the reviewer starts from a proposed answer with its evidence attached.
- Invoice arrivesBy Peppol, email or the supplier portal, and is captured into the ERP
- Match failsThe ERP compares PO, receipt and invoice and puts the mismatch on hold
- Cause identifiedThe agent reads the documents and dockets and classifies the exception
- Fix proposedTolerance, unit conversion or freight rule applied, with evidence attached
- AP approvesA person accepts, edits or rejects the proposal before anything is released
- ERP updatedReceipt, credit request or release recorded in your own system
- Audit trail keptEvidence and the approver's decision stored with the invoice
The agent runs in your environment, with access only to the records AP already uses. Where it needs to read a site mailbox or a shared drive, that access is granted and logged like any other system account, and every decision it proposes is stored with the invoice for audit.
Which exceptions to hand to the agent first
Not every exception should go to the agent at the start. The test is whether a correct answer can be checked against a document or a rule your finance team already trusts.
Can the right answer be proven from a document or an agreed rule?
- Yes: a docket, contract rate, pack size or agreed freight rule settles itAgent investigates and proposes; AP approves each one
- Partly: the evidence exists but needs a site or buyer to confirmAgent drafts the query to the right person and tracks the reply
- No: commercial judgement, a dispute or a new priceStraight to procurement or the buyer, with the agent's summary attached
- Any sign of changed bank details or a near-duplicatePayment held; AP confirms with the supplier on a number already on file
Bank detail changes and suspected duplicates always stay with people. The agent's job there is to spot them and stop the payment, and a person confirms with the supplier on a phone number already held in the vendor master.
Tolerances and rules set by finance
An agent is only as trustworthy as the rules it works to. Before any build, finance sets them in writing:
- Price tolerance by category, as an amount or a percentage, and who can accept a variance above it.
- Quantity tolerance, including whether over-delivery is accepted.
- Freight rules: which suppliers may charge freight, at what rate, and whether it needs a buyer's OK.
- Unit of measure tables for the suppliers who invoice in packs.
- Duplicate rules: same supplier and invoice number, or same supplier, amount and date within a window, plus near matches across channels.
There is no universal right number for any of these. A tolerance that suits low-value consumables would be careless on capital items. What matters is that the rule is written down, owned by a named person, and applied the same way at every site.
Often the working rules live in the heads of two or three experienced AP officers. Writing them down is useful on its own, and it is the first part of the work.
GST and tax invoice checks happen during the match
An invoice that matches the PO perfectly can still fail as a tax invoice. The ATO sets out what a tax invoice must show. For taxable sales under $1,000 it must include enough information to determine seven details: that the document is intended to be a tax invoice, the seller's identity, the seller's ABN, the date of issue, a brief description of the items sold including quantity and price, the GST amount payable, and the extent to which each sale is taxable. Tax invoices for sales of $1,000 or more must also show the buyer's identity or ABN.
That last point catches multi-entity groups. An invoice addressed to the wrong entity in the group, or with no buyer details at all on a large amount, should be queried before the GST credit is claimed. The agent can check these fields during the investigation and add a missing buyer ABN to the list of reasons the invoice is on hold. Our guide to Peppol e-invoicing compliance covers the GST checks for invoices that still arrive as PDFs.
Peppol e-invoicing cleans up the invoice side of the match
Peppol improves the invoice side of the match and leaves the PO and receipt sides as they are. The ATO is Australia's Peppol Authority, and Australia and New Zealand adopted the Peppol framework together in 2019. The ATO notes that the Australian and New Zealand invoice specification supports GST and can be used to issue an invoice that meets the tax invoice requirements.
A structured eInvoice removes keying errors and makes duplicates easier to catch, because the supplier, ABN, invoice number and lines arrive as data. It does nothing for a receipt that was never entered at the site, a partial delivery or a price that moved. The ATO itself says you still need to apply your existing checks before paying eInvoices.
There is a reporting link as well. According to the ATO, large businesses in scope for the Payment Times Reporting Scheme must now note their eInvoicing policies and practices and flag eInvoices in their payment times reports. Moving suppliers to Peppol and clearing the exception queue are two parts of the same payment times story.
Shadow mode before the agent touches a live invoice
The safe way to introduce an agent into AP is to let it work beside the team on real exceptions without acting on any of them.
In shadow mode, the agent investigates every held invoice and records its proposed cause and fix. Your AP officers clear the queue exactly as they do today. Each week the two are compared side by side: how often the agent's cause and fix matched what the officer actually did, by exception type and by site.
Finance sets the accuracy threshold before shadow mode starts. When the agent meets it for a given exception type, that type moves to co-pilot mode: the agent's proposal appears in front of the officer, who approves, edits or rejects it. Types that do not reach the threshold stay in shadow mode or stay manual.
Each phase ends at an exit point: proceed, pause or stop, keeping everything delivered so far. If the comparison shows the agent cannot reliably explain partial deliveries at your construction sites, you stop there and keep the parts that work.
- Weeks 1 to 4Discovery and designCount last quarter's exceptions by cause and site, write the tolerance and freight rules, agree the accuracy threshold
- Weeks 5 to 12Build and shadow modeAgent investigates every held invoice in your ERP; weekly side-by-side comparison; nothing is released by the agent
- Weeks 13 to 18Co-pilot and handoverProposals shown to AP for exception types that met the threshold; a person approves each one; code and documentation handed to your IT
Measuring whether the queue moved
Agree the baseline in Phase 1, measured from your own ERP, so the later comparison is not a matter of opinion:
- number of invoices on hold at month-end, by cause and by site;
- median days from invoice receipt to match cleared;
- share of exceptions cleared without a query to a site or buyer;
- duplicates and bank detail changes caught before payment;
- for reporting entities, the payment times figures the Payment Times Reporting Scheme already asks for.
The site-level view is often the most useful output. Once exceptions are counted by branch and cause, the fix for the largest cause is sometimes a receipting habit at a few sites, which a branch manager can change in a week.
Where the ERP is Business Central, our Business Central invoice processing guide covers what the platform's own agents do and where a custom agent fits beside them. If you are still comparing invoice capture tools, the honest guide to invoice automation sets out the trade-offs.
How Solve8 can help
If your AP team spends its week chasing sites for receipts and buyers for price approvals, a short review will tell you how much of the queue is routine enough for an agent and how much is a receipting or procurement habit to fix first. You leave with your exceptions counted by cause and a straight answer on whether a pilot is worth running.
We build inside the ERP and finance systems you already run, as part of our process automation work, with the connections to site mailboxes, procurement records and supplier data handled through system integration. Where an off-the-shelf AP tool cannot follow your rules, we scope custom AI development in your own environment. The lead on every engagement spent 18 years on operations and data systems for BHP, Rio Tinto and Senex Energy, gained while working with previous consulting employers. These companies are not Solve8 clients. More about how we work is on our about page.
Book a free 30-minute review and bring last quarter's exception count. We will tell you which causes we would start with and which we would leave with your team.
Related reading:
- Automate Invoice Processing with AI in Australia: Xero and MYOB: capture, coding and approval before the match runs.
- Invoice Automation Australia: The Honest Guide: the trade-offs between capture tools, ERP features and custom builds.
- E-Invoicing Compliance in Australia: Peppol Without Rekeying: moving suppliers to Peppol and checking the PDFs that remain.
- Automated Invoice Processing in Business Central: what Business Central does natively and where an agent fits.
Sources: Checked 6 November 2026: ATO, Tax invoices (last updated 18 September 2026); ATO, About Peppol eInvoicing (last updated 2 November 2026), including its National Anti-Scam Centre figures; Payment Times Reporting Regulator, About the Payment Times Reporting Scheme, Who must report and when and Information sheet 10: Reforms to Payment Times Reporting.
