How three-way matching works, and where agents pick up
Three-way matching works as a pipeline that fires when a supplier invoice is entered for payment: the system extracts the invoice data, retrieves the purchase order it references, pairs each invoice line with a PO line, checks unit price and quantity on every paired line against tolerance – the variance band a company allows before requiring review – verifies computed amounts such as tax and freight, and then either posts the invoice or holds it. Each stage fails for its own reasons, so understanding how three-way matching works means knowing the order the stages run in. In SAP the logic runs inside MIRO, the invoice verification transaction; Ariba and Coupa use different screens and the same sequence.
This wiki defines source-to-pay concepts for companies where AI agents carry the operational work and people keep the judgment calls. A glossary can afford to treat the match as a black box that answers yes or no. An agent assigned to clear the failures cannot, because the right fix depends on which stage of the pipeline produced the flag. This page walks the stages in order; the concept itself – why three documents, and what each one contributes – is covered on the three-way matching page.
Capture and extraction set the ceiling for everything downstream
Most explanations of how three-way matching works begin at the comparison. The pipeline begins earlier, when the invoice arrives as a PDF attachment, a paper scan, or an EDI transmission and the system extracts structured fields from it: supplier, invoice number, PO reference, and for every line an item description, quantity, unit of measure, unit price, and amount. Extraction errors travel. A capture tool that reads a quantity of 1,500 as 1,800, drops a decimal from a unit price, or merges two invoice lines into one produces flags three stages later that look exactly like supplier billing errors.
Retrieval comes next. The header PO reference points the system at the purchase order, and the PO carries the goods receipts – the warehouse's record, posted against each PO line, of what physically arrived. In SAP that record sits on the purchase order history tab, fed by goods receipt postings in MIGO. An invoice with a missing or mistyped PO reference stops here, before any comparison happens, and the same is true when the referenced PO exists but was never released. Holds from this stage involve no genuine disagreement between the documents; they are plumbing failures, and they resolve in the capture queue or with the supplier's billing team.
Line pairing decides what the match is even comparing
Before any number is checked, the system has to decide which PO line each invoice line corresponds to. Glossaries skip this step because it sounds trivial. It is the step where matching most often goes wrong, because suppliers bill from their own systems, and their line structure follows their invoicing logic rather than the buyer's PO.
Take PO 4500128733, a maintenance order with three lines: line 10, 500 hex bolts at $0.42 each ($210); line 20, 500 flange nuts at $0.31 each ($155); line 30, 200 mounting brackets at $4.85 each ($970). All bolts and nuts have been received; 120 of the brackets have. The supplier's invoice arrives with two lines. The first reads "fastener kit, 1,000 pcs, $365" – the bolts and nuts consolidated, priced correctly in total. The second bills 120 brackets at $4.85, with the remaining 80 to follow on next month's invoice. If the pairing engine maps "fastener kit" to PO line 10 alone, the checks that follow see 1,000 units invoiced against a receipt of 500 and a unit price of $0.365 against an ordered $0.42 – a quantity exception and a price variance on an invoice that contains no error at all. Paired correctly, with the kit split across lines 10 and 20 and the brackets matched to line 30 as a partial, every line clears exactly.
Unit-of-measure differences cause the same effect: a PO written in eaches matched against an invoice billed per hundred shows a hundredfold price discrepancy until something converts the units. A meaningful share of flagged price and quantity mismatches dissolve the moment the lines are re-paired, and the match can only compare the lines it has paired.
Quantity and price run as separate checks with separate tolerances
For each paired line, the quantity check compares invoiced quantity to received quantity, so the company never pays for goods that have yet to arrive. The price check compares the invoiced unit price to the PO unit price. Each check applies its own tolerance – typically a percentage band, an absolute cap, or both – and each can fail on its own, which is why a single invoice can carry both a quantity mismatch and a price variance. SAP records the two failures under different blocking reasons, a quantity block and a price block, and routes them differently because the fix lives in different places: a quantity block usually resolves in receiving, a price block with the buyer or the contract.
Tax and freight are checked against the system's own arithmetic
Header-level amounts follow a different logic from line comparisons. The ERP computes what tax should be – from the tax code, the jurisdiction, and the taxable base – and compares its own result to the figure on the invoice. Freight is validated against the PO's delivery terms or planned delivery costs. In practice the failures here are small and stubborn. Suppose the goods on an invoice total $947 and freight is $48. The supplier computed 8.25% tax on the goods alone, $78.13; the ERP's tax code applies 8.25% to goods plus freight, $82.09. The two figures differ by $3.96, the whole document holds, and no line on the PO is wrong anywhere. Rounding differences, freight billed on an order whose incoterms – the standardized trade terms that assign shipping cost and risk between buyer and seller – put freight on the supplier, and tax codes mapped to the wrong jurisdiction all fail the same way: the supplier's arithmetic and the system's arithmetic disagree.
A hold code names the symptom
The final step in how three-way matching works is binary: lines inside tolerance post, and an invoice whose lines all clear joins the payment run untouched, while any failed check parks the document with a blocking reason and routes it to a queue as one of the invoice exceptions an AP team works. The blocking reason describes what failed. Why it failed lives in the surrounding records: the purchase order history, the goods receipt documents and packing slips, the contract's pricing schedule, the buyer's email thread, and the resolution of the same mismatch the last time this supplier produced it. A price block on the bracket line says the numbers differ; the contract amendment that explains the difference sits in a repository the match never reads.
That is why the investigation belongs to whoever, or whatever, can read those records. The arithmetic up to the hold has been reliable in ERPs for decades, and nearly all of the cost of matching sits after it – in the reading, cross-checking, and deciding that the manual vs automated exception resolution page compares path by path. For an AI agent, the hold code is an entry point: a named symptom, a document set to read, and a verifiable end state.
Fragment builds AI agents that start where the pipeline stops. When an invoice holds, the agent re-derives the line pairing, reads the purchase order history, the receipts, the contract, and the supplier's resolution history, then clears the block or escalates with the evidence attached – inside the company's existing SAP or Ariba environment, with no rip and replace. See how the workflows run or request a demo.