Three-way matching is the control that compares three documents before an invoice is paid: the purchase order, the goods receipt, and the invoice itself. If all three agree, the invoice is released. If they do not, it becomes an exception and a human looks at it.
The three documents answer three different questions. The purchase order says what the organisation agreed to buy and at what price. The goods receipt says what actually arrived. The invoice says what the supplier is charging for. Paying without checking all three means paying for things you did not order, did not receive, or were charged the wrong price for.
What gets compared
The match is not a comparison of whole documents. It runs field by field, usually at line level:
- Quantity. Invoice quantity against received quantity, not against ordered quantity. This distinction matters on partial deliveries.
- Price. Invoice unit price against the purchase order unit price.
- Item. The part number or catalogue reference on the invoice line against the order line.
- Total. Extended line values and the document total, including tax and freight treatment.
Some organisations also check the delivery date against the promised date, and whether the receiving location matches the ordered destination.
Two-way, three-way, four-way
The naming refers to how many documents participate.
Two-way matching compares purchase order and invoice only. There is no receipt to check against, so it is used where receipting is not meaningful: services, subscriptions, utilities, and rate-card labour. It confirms you were charged what you agreed, but not that you got anything.
Three-way matching adds the goods receipt. This is the standard control for physical goods and the reason the receipting step exists at all. Without it, an invoice for a delivery that never arrived matches perfectly against the order.
Four-way matching adds an inspection or quality certificate. Used where acceptance is conditional on testing: pharmaceuticals, regulated food inputs, calibrated equipment, certain construction materials. Considerably less common, and heavier to operate.
Tolerances
Requiring exact agreement on every field produces an exception rate that no accounts payable team can absorb. Real implementations define tolerances: a permitted variance within which the match passes automatically.
Tolerances are normally set as both a percentage and an absolute cap, applied separately to price and quantity. A typical configuration might accept a price variance up to two per cent or twenty euros, whichever is lower, and a quantity variance up to five per cent on over-delivery with zero tolerance on under-delivery.
Two design points are worth getting right. Tolerances should be asymmetric, because being charged slightly less than agreed is not the same risk as being charged slightly more. And the absolute cap matters more than the percentage, because a two per cent tolerance on a large order is a meaningful sum being waved through.
Setting tolerances too tight produces exception volume that swamps the team and gets worked around. Setting them too loose means the control passes things it should have caught. The right setting is a function of transaction volume and average line value, and it should be revisited when either changes materially.
Why matches fail
The interesting question is not how matching works but why it fails so often. In most estates the causes are consistent and, importantly, almost all originate before the invoice arrives.
Unit of measure mismatch. The order was placed per case, the supplier invoices per unit, and the quantities differ by the case factor. This is the single most common cause and it is a catalogue data problem, not an accounts payable problem.
Price drift. The catalogue price the requisition used is not the price the supplier is currently charging, because the catalogue has not been refreshed since the last price change. Every affected invoice becomes an exception until someone reloads the file. Discussed further in hosted catalog vs PunchOut.
Missing goods receipt. The delivery arrived, nobody recorded it, and the invoice has nothing to match against. Extremely common in distributed estates where receiving happens at a loading dock without system access.
Partial and split deliveries. One order, three deliveries, two invoices, arriving in a different sequence than expected. Systems that match at document level rather than line level struggle badly here.
Freight, surcharges and tax. Charges that appear on the invoice but were never on the purchase order. Technically legitimate, structurally unmatched.
No purchase order at all. Someone bought without raising one. There is nothing to match against, and the invoice goes into a manual approval path outside the control entirely. See purchase requisition vs purchase order for why this matters.
Free-text requisitions. The order line carried a typed description and a guessed price rather than a catalogue reference. The invoice was never going to match, because the order never contained accurate data in the first place.
The metric that matters
The useful measure is the touchless invoice rate: the percentage of invoices that pass matching and reach payment without any human intervention. It captures the health of the whole upstream chain in one number, because an invoice can only go straight through if the catalogue was accurate, the order was structured, the receipt was recorded, and the supplier billed against the right reference.
Improving that number is almost never an accounts payable project. Every one of the failure causes above originates upstream: in catalogue data quality, in receipting discipline, or in whether the supplier is connected in a way that lets them bill against a structured order at all.
This is the argument for treating catalogue and supplier connectivity as accounts payable infrastructure rather than as a procurement convenience. An estate that fixes unit-of-measure consistency and price freshness in its catalogue will see its exception rate fall without touching the matching engine. That upstream work is what SupplierForge is built to do, and the mechanics of keeping that content correct are covered in catalog management: why clean catalog data is hard.
For the compliance layer that sits alongside this in Europe, where structured invoicing is increasingly a statutory requirement rather than an efficiency choice, see PEPPOL e-invoicing and the 2026 shift.