Where three-way matching breaks: five assumptions agents restore
Three-way matching breaks where its unstated assumptions stop holding. The procedure – comparing an invoice against the purchase order and the goods receipt before payment – assumes that all three documents exist, that their lines correspond, that everyone counted in the same units, that the documents describe the same moment, and that the PO reflects the live agreement. Every recurring failure point traces back to one of the five giving way, which is why an invoice can be entirely correct and still land in a hold queue.
This wiki covers source-to-pay for operations where AI agents carry the working load – posting matches, reading contracts, clearing variances – and people rule on the judgment calls. A glossary written for clerks would treat each match failure as a hold code to be worked; this page treats it as a blind spot in the procedure itself, the level an agent reasons at when it picks up the flag.
The types of invoice exceptions catalog sorts failures by the proof that failed. This page sorts them by the assumption that failed, which explains why the procedure could not see the truth and which record restores it; the mechanics of the comparison live on the how three-way matching works page.
The match assumes all three documents exist
Three-way matching needs a purchase order and a goods receipt before the comparison can start, and whole categories of spend never generate them. Services are the standing example: consulting hours, equipment repairs, utilities, and legal work produce no goods receipt worth the name, and much of the work starts before anyone cuts a PO. Tail spend – small, infrequent purchases below sourcing thresholds – behaves the same way. These arrive as non-PO invoices, and the match has nothing to hold them against.
Take an $18,500 invoice for an emergency chiller repair at a distribution center. There is no PO because the facilities manager approved the contractor's quote by email at 11pm, and no receipt because nothing crossed a dock. A matching engine can only route it to a person for manual coding and approval. An agent reconstructs the missing documents' function: it finds the work order in the maintenance system, the technician's sign-off, the emailed quote approval, and the labor rates in the contractor's master service agreement, then assembles the same proof a PO and a receipt would have supplied – the work was authorized, it happened, and the price is the agreed one.
The match assumes invoice lines pair with PO lines
Line-level three-way matching pairs each invoice line with a PO line and compares price and quantity inside the pair. Suppliers break the pairing constantly and legitimately. They consolidate: a PO with four lines of fasteners comes back as a single invoice line reading "hardware, assorted, $7,212." They split: one PO line for 5,000 units ships from two warehouses and arrives as two invoices. They substitute: the ordered part number A-1140 was superseded mid-quarter, and both the carton and the invoice say A-1140-R. In each case the totals reconcile, yet the engine finds no line to pair and flags everything it cannot place.
An agent works the pairing problem with the documents the engine never reads. It compares line descriptions instead of line positions, pulls the packing slip to see which PO lines a shipment covered, checks the supplier's item cross-reference to confirm A-1140-R supersedes A-1140, and re-aggregates: four PO lines totaling $7,212 against one invoice line of $7,212 is a clean match once something can read both sides as sets.
The match assumes everyone counted in the same units
The PO orders 40 cases, the warehouse scans 960 eaches, and the invoice bills 40 cases again, or two pallets. All three numbers describe the same 960 bottles, and an engine comparing 40 against 960 raises a huge apparent quantity mismatch. Unit-of-measure disagreements are among the most common flags in high-volume goods categories, and every one is arithmetic.
The conversion the engine needed usually exists. The material master in SAP – the ERP's central record for each item – carries a units-of-measure table (one case holds 24 eaches), and the packing slip states the pack size. An agent reads whichever record is present, converts all three documents to one unit, and either the counts agree or a real shortage emerges. The second outcome matters: converting units correctly is how a genuine short shipment stops hiding inside a formatting problem.
The match assumes the documents describe the same moment
An invoice, a receipt, and a PO are snapshots taken at different times, and the match compares them as if they were simultaneous. Suppliers who invoice on ship date under origin-based incoterms – delivery terms under which ownership transfers when goods leave the supplier's dock – bill correctly for goods still on a truck. In practice that means goods leave the supplier on Monday, the invoice arrives Tuesday, transit takes nine days, and for a week the engine sees a company billed for nothing received. The same gap runs in reverse at month-end, when a busy dock posts receipts days late.
An agent separates a timing gap from a real discrepancy by reading the records that carry time. The advance ship notice – the supplier's electronic notification that goods have shipped – confirms the quantity is in transit; carrier tracking gives the arrival date; the incoterms on the PO establish that invoicing at ship was contractually proper. The agent then validates against the ship notice where policy allows, or schedules its own re-check for the arrival date, and the invoice stops aging in a queue while a truck drives.
The match assumes the PO still reflects the deal
The purchase order is the document three-way matching trusts most, and the one most likely to go stale. Prices get renegotiated after the order is cut, quantities get amended on a phone call, surcharges get agreed in email, and the PO in the ERP quietly stops describing the live agreement. The supplier then bills the new, correct price and fails the match against the old one. Take a PO written at $12.40 a unit in January against a contract whose amendment, signed in March, moves the price to $12.90: every invoice after March fails as a price variance, and every one of them is right.
An agent resolves the class by hunting for the current agreement. It checks whether a PO change was posted, reads the contract repository for amendments and pricing schedules, searches the buyer's correspondence for an agreed change, and checks resolution history for precedent. When the amendment surfaces, the agent posts the match with the clause and the calculation attached, and flags the PO for correction so the break stops recurring invoice after invoice.
Every break points to a record outside the match
Across the five failures one pattern holds: the truth the procedure needed existed at the moment it flagged, in a rate card, a packing slip, a units table, a ship notice, or a contract amendment. A matching engine sees three documents; the record that restores the broken assumption is always a fourth, held in a system the engine was never wired to read. That is why match failures resisted automation for so long – clearing them means reading across maintenance systems, contract repositories, ERP master data, EDI streams, and email archives. It is also why upstream discipline never finishes the job: suppliers, docks, and contract cycles sit outside AP's control, so some invoices will always arrive with an assumption already broken.
Fragment builds AI agents that work match failures at the level of the failed assumption – reading the record that restores it, or reconstructing the proof another way – inside a company's existing SAP or Ariba environment, with no rip and replace. See how the workflows run or request a demo.