What is three-way matching, when AI agents run the match?
Three-way matching is an accounts payable control that compares three documents before an invoice is paid: the purchase order recording what the company agreed to buy, the goods receipt recording what actually arrived, and the invoice stating what the supplier now claims. If quantities and prices agree across all three within an allowed tolerance – the variance band a company accepts before requiring review – the invoice posts and pays. If any figure disagrees, the invoice stops and becomes an invoice exception in a hold queue.
Across this wiki, source-to-pay concepts are explained for companies where AI agents carry the operational load – comparing documents, reading contracts, clearing holds – while people keep the judgment calls. Most definitions of three-way matching stop at the comparison itself; this page also covers what the comparison can never do, because that gap is exactly where agents now operate.
The match cross-examines three independent testimonies
Three-way matching gets its authority from independence. The three documents describe the same purchase, but each is written by a different party, at a different time, for a different reason. The purchase order is the buyer's testimony, recorded in the ERP before anything ships: these items, these quantities, these prices. The goods receipt, logged as a GRN when a delivery lands at the dock, is the warehouse's testimony about what physically showed up; for services it is usually a confirmation that the work was performed. The invoice is the supplier's testimony, and it is the only one of the three written by an outside party with money riding on the outcome.
Because the testimonies are independent, agreement among them is hard to fake. For a bad payment to clear, the buyer's record, the warehouse's record, and the supplier's claim would all have to be wrong in the same direction by the same amount. That is why the control has survived every generation of AP technology, and why its siblings – two-way and four-way matching, which vary how many testimonies are collected – are variations on the same idea rather than replacements for it.
A pass proves consistency, and a fail explains nothing
The control's limits deserve as much precision as its definition, because the limits define the work that surrounds it. A passing three-way match proves one thing: the three records agree with each other. If a purchase order was cut at a stale price and the supplier happens to invoice at that same stale price, the match passes cleanly and the company overpays with a full audit trail. Consistency among the testimonies is the entire proof; the truth of the underlying purchase sits outside it.
A failing match proves even less. It reports that a disagreement exists, on which line, and by how much – and there its knowledge ends. The three documents contain the discrepancy without containing its cause, so a match engine that reads only those three documents is structurally unable to explain what it found. Match tolerances – the allowed gap, in dollars or percent, before a difference counts as a disagreement – tune where the pass/fail boundary sits, and the full sequence of checks is laid out in how three-way matching works. Neither tuning nor mechanics changes the basic shape: the match is a detector.
One valve order shows both verdicts
In practice, the two outcomes look like this. A plant orders 600 pressure-relief valves on PO 4500118203 in SAP at $84.50 each, $50,700 in total. The warehouse receives 600 and posts the goods receipt. The supplier invoices 600 at $84.50. Every figure agrees, so the invoice posts without a person touching it and payment follows the terms – the flow AP teams call touchless invoice processing.
The next month the plant reorders 300 valves on a new PO at the same $84.50, and the invoice arrives at $88.90 per unit: $26,670 against an expected $25,350. The price differs by 5.2%, the tolerance allows 2%, so the match fails and $26,670 goes on hold. Everything the match can report fits on one line: unit price, PO says $84.50, invoice says $88.90. Whether a steel surcharge clause reset the contract price, a negotiated increase never reached the price master, or the supplier simply billed the wrong rate is invisible to it. Those causes and their relatives are cataloged in where three-way matching breaks and, more broadly, in the types of invoice exceptions.
Agents work the gap between detecting and explaining
The detection half of three-way matching was automated decades ago; every ERP and P2P suite runs the comparison without help. The explanation half stayed manual, because explaining a failed match means reading records the match engine never sees: the PO change history, the contract's pricing schedule, the receiving clerk's note about a short pallet, the email where a buyer approved a substitution, the way the identical mismatch was resolved last quarter. That second pass has belonged to AP analysts for as long as the control has existed, which is why failed matches age in hold queues while analysts triage by dollar value.
AI agents now run the second pass. An agent picks up the failed valve invoice, pulls the supplier contract, finds a surcharge clause indexed to steel prices, computes the reset, and either confirms $88.90 to the cent or establishes that no clause supports it. When the evidence clears the hold, the agent posts the match with the rationale attached. When the case turns on something genuinely ambiguous, it escalates with the completed workup rather than a bare hold code. Part of what the agent must learn is tribal – the supplier who always bills freight on a separate line, the plant that books maintenance parts to an unusual cost center – knowledge that lives in resolution history and in corrections from the team rather than in any master record.
The division of labor is clean. The match is the first pass: deterministic, instant, and confined to three documents. The agent is the second pass: able to read everything else the company knows about the purchase. Invoices with no purchase order at all – non-PO invoices for legal fees, utilities, or ad hoc services – never get a first pass, which is why they need their own validation path.
The control stays, and the fate of a failed match changes
The match is worth keeping exactly as strict as it is. Run without it, an AP process pays duplicate invoices, inflated prices, and deliveries that never happened, and discovers each one after the money is gone. Companies that deploy agents keep the control in place and keep tolerances tight, because a flagged disagreement now costs minutes of agent time instead of days of queue time. The pressure to widen tolerances just to survive the exception volume goes away.
Expect the match to fail about as often as before. The disagreements are created upstream by partial deliveries, price resets, and late receipts, and the match will keep detecting them. What changes is what a fail costs: the investigation starts the minute the hold is raised, and the judgment calls that reach people arrive carrying evidence rather than symptoms.
Fragment builds the AI agents that run this second pass, working inside a company's existing SAP or Ariba environment with no rip and replace. When a three-way match fails, the agent investigates it the way a strong analyst would – contract, history, precedent – clears the holds the evidence supports, and routes the genuine judgment calls to people with the proof already assembled. See the workflows Fragment runs or request a demo.