Three-Way Match Exceptions: Letting AI Agents Do the First Review

Three-way match exceptions are where accounts payable time quietly disappears. An invoice, a purchase order and a goods receipt do not agree, and someone has to work out why, usually by chasing buyers and warehouse staff through email while the invoice ages in a queue. This article explains how an AI agent can do the first review of each exception, investigating price, quantity and receipt mismatches and preparing a recommendation, while a person keeps the approval. It also covers the tolerances, decision rights and audit trail that make this safe, and the cases where it is not worth automating at all.

1. What Is Three-Way Matching and Why Do Exceptions Pile Up?

Three-way matching compares three documents before an invoice is paid: the purchase order, which says what was agreed; the goods receipt or service entry, which says what arrived; and the supplier invoice, which says what is being charged. When all three agree within tolerance, the ERP releases the invoice for payment. When they do not, it blocks the invoice and drops it into an exception queue. In SAP that usually means a payment block; in Oracle it is an invoice hold. Either way, nothing moves until someone looks.

The queue of three-way match exceptions grows for predictable reasons. Receipts are posted late or not at all, especially for services. Buyers raise orders at old prices, then agree new ones by email. Suppliers split deliveries but invoice once, or consolidate several orders on one invoice. Little of this is fraud, and most of it is resolved by the same few checks. The cost sits in the investigation: finding the email, asking the warehouse, opening the contract. Receivables teams face the mirror image when matching remittances, which is why AI cash application follows a similar evidence-gathering pattern.

2. Price, Quantity and Receipt: Where the Mismatches Come From

A price variance is the most common PO invoice mismatch. The unit price on the invoice differs from the order, sometimes through rounding, sometimes because a price increase was agreed and never reflected in the purchase order, and occasionally because the supplier has charged the wrong rate. Freight, surcharges and currency conversion add noise. The useful question is whether a valid source supports the invoiced price: a contract, a price list, an approved order change or a written confirmation from the buyer.

Quantity mismatches run in two directions. The invoice may bill more than was received, which is where money leaks, or less, which usually means a partial invoice with more to follow. Units of measure cause a surprising share: an order in cartons, a receipt in pieces, an invoice in pallets. Receipt problems are different again. A goods receipt discrepancy often means no receipt exists at all, so the system cannot tell whether the goods failed to arrive or the receipt was simply never posted.

3. How Does an AI Agent Investigate Three-Way Match Exceptions?

The agent starts where an experienced AP clerk would. It reads the blocked invoice, the order lines and any receipts, then classifies the exception as price, quantity, receipt or a combination. Classification matters because each type has different likely causes and different places to look. A price exception sends the agent to contracts, price lists and order change history. A quantity exception sends it to receipt history, delivery notes and unit conversions. A missing receipt sends it to the requester or the warehouse.

Then it tests explanations one at a time. Take a distribution group with entities in Dubai and Riyadh, where an invoice from a packaging supplier is blocked for price. The agent checks the variance against tolerance, finds a signed price amendment in the contract repository dated before the invoice, confirms the purchase order was never updated, and sees that the supplier's recent invoices carried the same new price. Each check is logged with the document it relied on. If the evidence runs out, the agent stops and says so.

Receipts are where an agent does something a rule engine cannot: it asks. It sends the requester a specific question about a named order line, with the delivery note attached if one exists, and records the reply. Where policy allows, it prompts the requester to post the receipt in the ERP rather than posting it on their behalf. That keeps the control where it belongs, with the person who saw the goods arrive, while removing the days of email chasing that usually surround it.

4. What the Approver Receives: A Prepared Case File

The output of the first review is a short case file. It states the exception type, the variance, the most likely cause, the evidence for and against, and a recommended action: approve as invoiced, approve after an order correction, short-pay and request a credit note, or hold and escalate to the buyer. It also gives a confidence level and says what would change the recommendation. A good case file lets the reviewer in the AP exception workflow decide without opening four systems.

This is the real change in invoice exception handling with agents. The person still approves, and their decision is recorded against the agent's recommendation, so disagreements become both training material and audit evidence. Over time they show where tolerances are wrong and which suppliers create the most rework. AITHENTIC's AP invoice verification agent works this way: matched invoices are approved against orders and receipts, duplicates are stopped before payment, and exceptions are routed with the reason attached. Its published outcome is 70%+ touchless accounts payable with AED 1M+ leakage saved.

5. Tolerances, Decision Rights and the Audit Trail

Accounts payable automation goes wrong when tolerances are treated as a technical setting. Price variance tolerance belongs to finance policy, set by category and sometimes by supplier, with an absolute cap alongside the percentage so that small percentages on large invoices still get reviewed. The agent should never move a tolerance. It works inside the limits it is given and reports where they look wrong, for example a category where nearly every invoice breaches and is approved anyway.

Decision rights need the same discipline. Write down what the agent may do alone, such as requesting information or drafting a debit memo; what needs a named approver; and what must always go to a person whatever the evidence, such as any invoice linked to changed supplier bank details. Escalation logic follows from that list. Well-designed finance AI agents carry a defined role, decision rights, escalation logic and a full audit trail, so an internal auditor can follow every step without asking AP to explain it.

None of this works on fragmented data. If contracts sit in a shared drive, receipts in a warehouse system and invoices in the ERP, the agent needs controlled access to all three, with consistent supplier and item master data across entities. A governed data layer, for example on Microsoft Fabric, gives the agent one version of each supplier, contract and order history, with access controlled by role. Without it, the agent inherits the same blind spots that slow your team down now.

6. When Agent-First Review Is Not Worth Doing

Some three-way match exceptions should never reach an agent. If most of your blocks come from service receipts that are never posted, the fix is process: service entry sheets, or a two-way match with budget holder approval for low-risk categories. Automating the chase would hide a broken habit. Likewise, if purchase orders are routinely raised after the invoice arrives, the match is a formality, and an agent would spend its time documenting retrospective orders that nobody intends to challenge.

Start with exception types that are frequent, rich in evidence and light on judgement: contract-backed price changes, unit-of-measure errors, partial deliveries. Leave quality disputes and commercial negotiations with buyers. Before any live invoice, run the agent on historical exceptions and compare its recommendations with what your team actually decided. Most of the work in building reliable AI agents sits in that testing and in the escalation rules, rather than in the model, and AP is a good place to learn it.

Key challenges

• Receipts are posted late or never, especially for services, so invoices block on missing evidence.
• Purchase order prices fall behind agreed contract changes, creating the same price variance month after month.
• Units of measure differ between order, receipt and invoice, producing false quantity mismatches.
• Investigation depends on email threads, shared drives and individual memory that sit outside the ERP.
• Tolerances are set once and rarely reviewed, either letting leakage through or blocking trivial differences.

The framework

A practical operating model for agent-first exception review has four stages. Investigate: the agent classifies each blocked invoice, gathers the order, receipt, contract and correspondence, and tests the likely causes against them. Recommend: it produces a case file with the cause, the evidence, a proposed action and a confidence level. Approve: a named person accepts, amends or rejects the recommendation within defined decision rights, and the ERP is updated only after that decision. Learn: AP and procurement review disagreements and recurring causes each month, feeding tolerance changes, master data fixes and buyer behaviour, so the queue shrinks at source rather than simply being worked faster.

How to implement it

1. Pull a recent history of blocked invoices from the ERP and classify them by exception type, supplier and root cause.
2. Agree tolerances and decision rights with finance policy owners and internal audit before configuring anything.
3. Connect the agent to purchase orders, receipts, invoices, contracts and supplier correspondence through governed, role-based access.
4. Run the agent on historical exceptions and compare its recommendations with the decisions your team actually made.
5. Go live on one or two frequent, low-judgement exception types with every recommendation approved by a person.
6. Review disagreements and recurring causes monthly, and fix the master data and buying habits behind them.

Frequently asked questions