An invoice lands for 500 units at $4.10 each. The purchase order said 480 units at $4.00. The warehouse received 480. Pay that invoice as written and you have just overpaid by $130, for twenty units you never got, at a price you never agreed to. Three-way matching is the check that catches that before the money leaves.
It is one of the oldest controls in accounts payable, and one that accounts payable automation is built to run at scale, because it answers the three questions that decide whether an invoice should be paid: did we order this, did we receive it, and are we being charged the right amount? This guide explains how three-way matching works, why purchase order mismatches happen, and how running it inside your ERP makes it accurate instead of aspirational.
The three documents, and what each one proves
Three-way matching compares three records before an invoice is approved for payment.
The purchase order is what you agreed to buy: the items, quantities, and prices you committed to. It proves the purchase was authorized and sets the terms. The goods receipt is what you actually received, the quantities your receiving team logged when the delivery arrived. It proves the goods showed up. The invoice is what the supplier is charging you. It is the claim.
When all three agree, within a tolerance you set, the invoice is safe to pay and can post without anyone touching it. When they do not agree, you have an exception, and it should stop for a person before the payment goes out. Go back to the example: the invoice claimed 500 units at $4.10, the PO authorized 480 at $4.00, and the receipt confirmed 480 arrived. Two mismatches, one on quantity and one on price, and $130 that stays in your account.
Two-way, three-way, four-way: which one you need
Three-way is the standard for physical goods, but it is not the only kind of match, and using the wrong one creates friction.
Two-way matching compares the invoice against the purchase order only. There is no goods receipt to check, so it fits services, subscriptions, and other non-inventory spend where nothing physically arrives at a dock. It confirms you are billed what you agreed to buy.
Three-way matching adds the goods receipt. It is the right control whenever you buy something that gets received, because it catches the gap between what was ordered and what actually turned up. Most inventory and materials spend belongs here.
Four-way matching adds one more step: inspection or quality acceptance. It matters in regulated or quality-critical buying, where receiving the goods is not enough and they have to pass a check first. Pharmaceuticals and precision manufacturing are common homes for it.
The rule of thumb: match against every document that represents a real control point, and no more. Forcing a three-way match on a service invoice with no receipt just manufactures exceptions.
Why purchase order mismatches happen
If matching were always clean, no one would need automation for it. The reason exceptions pile up is that invoices and orders drift apart for a dozen ordinary reasons, almost none of which involve anyone doing anything wrong.
Price variances are the most common. The supplier's price changed since the PO was cut, or freight and handling appear on the invoice but were never on the order, or a currency conversion lands a few cents off. Quantity variances come from partial deliveries, over-shipments, or goods received short because some arrived damaged and were rejected. Timing causes its own share: the invoice arrives before the goods receipt is posted, so there is nothing to match against yet, and the invoice waits. PO revisions trip up matching when an order changes after the fact and the invoice matches the original version. Unit-of-measure mismatches happen when you order in cases and the supplier invoices in each. And plenty of invoices simply arrive with a missing or wrong PO reference, so the system cannot find the order to match at all.
None of these is exotic. Together they are why exception handling, not matching itself, is where AP actually spends its time.
Tolerances: the setting nobody explains
Here is the part most explanations skip. Matching is not a pass-or-fail test. It runs against tolerances you define, and those tolerances decide how much of your AP team's week goes to exceptions.
A tolerance says how much variance is acceptable before an invoice stops for review. You might allow a price variance up to two percent or a few dollars per line, and accept quantities up to what was received. Set them by category and spend level, because a rounding difference on a box of screws does not deserve the same scrutiny as a five-figure variance on capital equipment.
Get this wrong in either direction and you pay for it. Tolerances that are too tight flag invoices that should have passed, and an AP team drowning in false exceptions stops trusting the control. Too loose, and real errors slip through to payment. This is a policy decision made with finance, not a technical setting a consultant flips on the way out the door.
What should happen on a mismatch
When an invoice fails the match, two things separate good accounts payable tools from mediocre ones.
First, the exception should isolate on its own track rather than blocking the queue behind it. One disputed line on one invoice should never hold up the clean invoices behind it. Second, it should route to the right owner automatically, on hold, with the reason attached, so the person who picks it up already knows whether they are looking at a price variance, a short receipt, or a missing PO.
The best setups also rematch on their own. When an invoice fails only because the goods receipt had not posted yet, the system should complete the match the moment the receipt lands, with no one re-touching it. Rules like these can be set down to the individual vendor, because the supplier who always short-ships needs different handling than the one who never does. For more on the invoices that do not match cleanly, see AP exception bottlenecks in Dynamics 365.
Why ERP-native matching is more accurate
Three-way matching is only as good as the data it matches against, which is where ERP integration stops being a technical detail and becomes a control issue.
When invoice matching runs inside your ERP, it compares the invoice against the live purchase order and the live goods receipt, as they stand right now. There is no copy, no sync delay, and no chance of matching against a version of the PO that changed an hour ago. A bolt-on tool that matches against data synced over from the ERP is always one step behind the truth, and it keeps its match results in a second system that your ledger and your auditor then have to reconcile.
Native ERP integration removes both problems. The match is accurate because the data is current, and the control is defensible because the purchase order, the receipt, the invoice, and the match result all live in one place with one audit trail. For finance teams on Microsoft Dynamics 365, that is the difference between purchase order matching as a real control and matching as a report you hope is right.
The takeaway
Three-way matching is a simple idea with a lot riding on the details: the tolerances you set, the exceptions you catch, and the data you match against. Run it inside the ERP, with sensible tolerances and clean exception handling, and it becomes the control that keeps you from paying for what you did not order and did not receive.
Truvio AP Automation runs three-way matching inside Dynamics 365 for both Finance & Operations and Business Central, against live PO and receipt data, with tolerance rules and exception handling built in. Book a demo to see it match your own invoices.
.svg "truvio_logo"){kind=small}
