What 3-way matching is, why it stays manual in practice, and what a system has to do to handle the exceptions. With figures from over 20,000 Dutch finance job postings.
3-way matching is the control that compares a purchase invoice against two other documents: the purchase order, with what was ordered and at what price, and the goods receipt, with what was actually delivered. If all three agree, the invoice can be booked and paid without anyone looking at it.
Every invoice processing tool now says it does this with AI. That is an easy claim, because the majority match by themselves: one order, one delivery, amount agrees. The question is what happens to the rest.
If you work with purchase orders and goods receipts, this covers a substantial share of your accounts payable work. Our analysis of over 20,000 Dutch finance job postings shows how unevenly it is spread: at companies on NetSuite, 12.7 percent of postings explicitly ask for matching work, and at Dynamics 12.3 percent, against 5.5 percent at Exact. More than twice as often. One caveat: larger companies sit on Dynamics, NetSuite and SAP more often, and larger companies also use purchase orders more often. ERP and company size run together in this data.
Why does the purchase order process exist?
Before automating something it pays to know where the control came from, because that determines what you must not throw away. There are four reasons.
Segregation of duties. The three documents come from three different hands. Procurement orders, the warehouse receives, accounts payable pays. Nobody can invent a purchase and clear it for payment on their own. That is why it is three documents and not two, and it is the core of your internal control.
You pay only for what you actually received. Over-billing, a price that quietly went up, the same invoice twice, or an invoice from a supplier nobody ordered from. Without the order and the receipt alongside it, you do not see any of that coming.
Commitments are visible before the spend. The order records what you have committed to. Your budget is therefore correct at the moment of ordering, not when the invoice lands.
Your numbers fall in the right period. On receipt, the obligation is booked to Goods Receipt Not Invoiced, so your result is right even when the invoice only arrives next month. And your stock value is right, because receipt and invoice land on the same order line.
So this is a control you want. We have written before that control is rarely the answer to a process nobody follows, and that still holds. The difference is not the control itself but where the friction lands. If the compliant path costs twenty minutes, people take the workaround: the order raised after the invoice, the existing supplier record that is close enough. If the compliant path costs nothing, you keep both the control and the compliance. More on that: support over control.
2-way or 3-way: what is compared to what?
2-way matching: invoice against purchase order. You compare what the supplier is billing with what you ordered, at the price you agreed. That covers two of the four reasons above: the spend was approved in advance and the commitment was already in your system. What it does not cover is whether you actually received it.
3-way matching: invoice against order and a confirmation of receipt. The moment you do want to know that, you need a third confirmation from someone other than the buyer and the payer. For physical goods that is the goods receipt in the warehouse, and that is by far where 3-way matching is most common. But the point is not physical versus non-physical, it is that independent confirmation. For services it can be a signed-off timesheet or a delivery confirmation. Many companies do not register that, which is why 2-way is the workable answer there in practice.
Rule of thumb: if you have a warehouse you need 3-way, and it is also what keeps your stock value and your ledger clean. If you mostly buy services, 2-way is enough and the work sits in the approval flow rather than in the receipt.
Why does 3-way matching fail in practice?
The simple case is not the problem. The work sits in three steps, and it breaks in all three.
Step 1: finding the right order
Every matching tool assumes your purchase order number is on the invoice. Often it is not, and what is on it is usually a number of an entirely different kind.
The supplier puts their own order number on the invoice. Your extraction reads it neatly as the purchase order number, after which it matches against nothing. Your purchase order number does exist somewhere: in the reference field of your own order, where the buyer typed it when they placed it.
With contract manufacturing the order is only created after the goods arrive, so the supplier could not have known the purchase order number. What does exist is a works order number, and that is what has to be matched on.
Sometimes the purchase order number is not on the invoice at all but in the attachment: a packing slip, a freight document, a spreadsheet with a specification in it.
And when nothing usable is there, one route remains: the delivery-note number on the invoice against the reference field on the goods receipt, and from there to the order.
Four routes to the same destination, and which one applies differs per supplier. Sometimes the link lives in your ERP, sometimes in a document that arrives as an attachment. A tool that knows one route fails on the other three.
Step 2: pairing the lines
Matching on order totals stops working the moment there are partial deliveries or several orders on one invoice. It has to be per line. But on what do you pair an invoice line to an order line?
There is no universal identifier. At one supplier it is your own item code, at another it is theirs, and at most there is no usable code at all and only the description remains. That has to be normalised on product, variant and size, and confirmed against quantity and amount.
Then units. One supplier invoices in singles while your order is in six-packs, so everything divides by six. Another invoices in tonnes where your order is in kilos. That is not a general rule but a table per supplier and per item, and you discover a new one only when it breaks.
And you compare against what was received, not what was ordered. Procurement may receive more than was ordered; that gets approved and booked as stock. The correct comparison is received minus already invoiced, tracked cumulatively per order line, because several invoices can land on one line over time.
Step 3: explaining the difference
This is where most of it goes wrong, and where the most important distinction in the whole process sits. A difference between order and invoice has three causes, and each belongs to a different person.
| Cause of the difference | Who resolves it | What has to happen |
|---|---|---|
| The quantity is off | Procurement or supply chain | Establish whether less was delivered, something arrived damaged, or the supplier is over-billing |
| The price is materially different | Whoever maintains the orders | Master data is out of date: correct the price on the order, then re-match |
| Rounding, two decimals against more | Nobody | Create an extra line automatically so the posting does not stall; where that line goes is your choice |
That distinction is the difference between a working system and an exception bin. A half-percent tolerance does not know the difference: it accepts a three-cent rounding and a three-cent pricing error in exactly the same way, and the second one should have been seen.
What if the invoice arrives before the goods?
This is not a failure, and yet most systems treat it as one. Suppliers send the invoice with the shipment, transport takes a few days, and the match therefore fails on something that will resolve by itself in three days.
The right handling is to hold the invoice and re-run the check daily until the receipt arrives, then work the Goods Receipt Not Invoiced account weekly to see what has closed since. Rejecting it back is the wrong answer to a problem that is purely about timing.
What does AI have to do to automate 3-way matching?
Five things, and only the first is about reading.
Reading is not the hard part. Recognition has genuinely improved: fields and lines are read accurately, including from a layout you have never seen. But on matching, reading was rarely the bottleneck. If the number printed on the invoice is the supplier's order number, reading it better does not help you.
Reasoning its way to the right order. This is where it actually starts. The purchase order number is not there, so: what kind of number is on it instead, where in the ERP might the purchase order number live, is it in the attachment, or can I get there via the packing slip? That is not extraction, it is a search across several routes, where the system has to know which route belongs to which supplier.
Computing the difference, at line level. Converting units. Tracking cumulatively what has already been invoiced per order line. Working out received minus invoiced. Calculating the exact amount of the deviation rather than just noting that one exists.
Understanding what caused it. A three-cent difference is either a rounding or a pricing error, and the tolerance cannot tell you which. The system has to establish the cause, because the cause decides who resolves it. And a rounding still needs handling: for as long as the difference stands it blocks the posting, so an extra line has to be created before the invoice can enter the ERP.
Bringing in the context that is not in your ERP. This is where it gets interesting, and this is where the bar sits. The supplier emails to say they are shipping 80 instead of 100 and the rest follows next week. Or they announce a credit note. Or there is a message that an item was substituted for an equivalent one under a different code. A person who read that email simply approves the invoice for 80 and escalates nothing, because she already knows. A rules engine sees a quantity mismatch and stops.
The difference between a system that looks at your invoice lines and a system that functions like a colleague sits exactly there. Can it find the email, the attachment or the message in the supplier mailbox where the deviation was already explained, connect it to this invoice and this order line, and decide on that basis that nothing is wrong? That is the standard to measure a system against, because it is what the person you are trying to relieve does all day.
And then comes the last part, where most tools stop. They flag. An exception appears in a list, and from there it is human work again: finding out what happened, pulling up the order, looking up the receipt, typing an email.
What does the system do when something does not add up?
On a quantity difference, an email goes to supply chain with the order number, the receipt, the invoiced and received quantities, and the difference already calculated. Not "there is a discrepancy", but which line, how much, and against which receipt.
On a material price difference, an email goes to whoever maintains the orders, with the order price, the invoice price and the amount at stake, so they can update the order. After that it re-matches automatically.
On a missing receipt or a missing packing slip, a message goes to the supplier with the order attached.
If the deviation has already been explained somewhere, in an email from the supplier or an attachment to the invoice, that gets looked up first. If it says 80 were shipped instead of 100 and the rest follows, there is no discrepancy to escalate but a partial delivery to process. A person only gets involved when that explanation does not exist.
On a rounding, nothing human happens. An extra line does have to be created, because otherwise the difference blocks the posting. Where that line goes is up to you: to inventory differences, or as an extra line on the purchase order so stock and payables balance again.
On an invoice that is early, nothing is rejected. The invoice is held and the check runs again tomorrow.
And when everything agrees, the action is the posting itself: the invoice goes into the ERP with every line linked to the right order line, and that is what clears the Goods Receipt Not Invoiced account. That is the difference between a system that shows you your work and a system that does it.
Do you have matching software, or an intelligent system?
Generation 1 is OCR with rules: a template per supplier, a booking rule per situation. It works as long as everything is the way you thought of it in advance, and step 1 is immediately fatal.
Generation 2 is the same architecture with an AI layer on the recognition. Reading improved, the processing stayed a rules engine. One tolerance, no distinction between a rounding and a pricing error, and still no second route to the purchase order number.
Generation 3 starts not at the reading but at the work: reason, compute, explain, bring in context, act. That is not better recognition, it is judgement written down as a rule and then executed identically every time.
So the question to ask a vendor is not whether they do 3-way matching. Everyone does. The question is what happens to the invoice with no purchase order number on it, and who gets an email when the quantities do not agree.
More on the three generations and which tools sit in each: the accounts payable software comparison guide. If you are looking specifically to replace your current tool, we go deeper in Blue10 alternatives.
Can Exact, NetSuite or Dynamics do 3-way matching themselves?
Every major ERP knows the concept. The difference is what happens the moment an invoice leaves the standard path.
| ERP | What it does itself | Where it stops |
|---|---|---|
| Exact Online | Links order, receipt and invoice for clean one-to-one cases | Line level on partial deliveries and multi-order invoices; two decimals create rounding differences |
| Microsoft Dynamics | Matching built into Business Central and F&O | Without goods-receipt registration everything must be confirmed manually at line level; intercompany across entities is its own project |
| NetSuite | Strong on the basics | Dual quantities such as item count plus rental period, and cumulative part-invoices against one order line, fall outside the standard |
| SAP | Full purchase-to-pay on board | Configuration-heavy; every exception needs to be designed in advance |
| AFAS | Purchasing and receipts on board | The same limits at partial deliveries, units and differences |
How Claridy does it
Claridy finds the order first and knows all four routes: your order number on the invoice, the supplier's order number in your own reference field, a works order number for contract manufacturing, and the detour via the delivery-note number on the packing slip. Recorded per supplier, not guessed per invoice.
Each invoice line is then paired to exactly one order line, on item code where one exists and on normalised description where it does not, with the per-supplier unit conversion applied. The comparison is against received minus invoiced, tracked cumulatively.
Differences are separated and each gets its own action, as described above. Attachments and the supplier mailbox are read too, because that is often where the explanation for a difference sits.
You set the rules in plain language: book rounding up to half a cent per line automatically, escalate price deviations above two percent to procurement, transport costs always to the logistics cost centre. That description becomes deterministic logic, so the same invoice always gives the same outcome and every step is in the audit trail. Every correction your team makes becomes a rule, so the same exception never comes back.
At a group we analysed, 91 percent of invoices carried an order, and 95 percent of those matched line by line. That is 86 percent of all invoices that can pass without a human. The remaining 14 percent, the invoices with no order and the lines that genuinely deviate, stays with your team, with the preparation done.
To work out what the manual work costs you today, use the ROI calculator. And the other side of the same job, clearing incoming payments against open items, is covered in the guide to bank reconciliation and cash application.
Frequently asked questions
The control that compares a purchase invoice against two other documents: the purchase order, with what was ordered and at what price, and the goods receipt, with what was actually delivered. If all three agree at line level, the invoice can be booked and paid without anyone looking at it.
2-way compares the invoice to the purchase order: does what is being billed agree with what you ordered, at the agreed price. 3-way adds an independent confirmation of receipt, so you never pay for what was not delivered and your stock value stays correct. 2-way suits services, 3-way applies as soon as someone other than the buyer can record that it arrived, which in practice mostly means physical goods.
There is almost always another route: the supplier's own order number that your buyer put in the reference field, a works order number for contract manufacturing, a number in an attachment, or the delivery-note number on the packing slip. Which route applies differs per supplier and is recorded per supplier.
An extra line has to be created either way, because for as long as the difference stands the invoice cannot be posted. Where that line goes is a choice, and more than one option works. Booking it to inventory differences is one, and that is how one of our customers does it. An extra line on the purchase order is just as logical, because that brings your stock and your payables back into balance. What matters in both cases is separating a rounding from a genuine price difference: a rounding needs nobody's attention, a price difference means your master data is wrong.
Hold it and re-check daily until the receipt lands. That is timing, not an error, and rejecting it costs more work than waiting.
Yes, and that is the point. On a quantity difference a message goes to supply chain with the order, the receipt and the calculated difference in it. On a price deviation, to whoever maintains the order. On a missing receipt, to the supplier. Flagging is not the same as handling.
For the large majority, yes, provided matching works at line level, the purchase order number can be found per supplier, and differences are sorted by cause. The exception that genuinely needs judgement should stay with a person, with the preparation done.
Yes. Claridy reads orders, receipts and invoices from all three and writes the approved posting back. The ERP stays the system of record.
For three-way matching, yes. Invoices without an order are coded by Claridy against your own booking history; that is a different workflow on the same platform.
Source for the job posting analysis: Claridy analysis of 21,642 Dutch finance job postings, 2026, tasks classified by AI against our own rubric. Last checked: 2026-08.