3-Way Matching Automation: The Real Bottleneck

TL;DR: 3-way matching checks a supplier invoice against its purchase order and goods receipt before you pay. Automating the match is easy, most tools do it. The bottleneck is the mismatches: partial deliveries, unit-of-measure quirks, price updates that never hit the PO. Legacy software flags all of them identically and dumps the pile on a human. The win is software that reads why each match failed, auto-resolves the routine variances within tolerance, and routes only genuine exceptions to a named approver with the discrepancy highlighted. That's what moves your touchless rate from "we match" to "we barely touch invoices."

What 3-way matching actually checks

Before you pay a supplier, three documents should agree:

1. Purchase order (PO) — what you agreed to buy: items, quantities, prices.
2. Goods receipt (GRN) — what actually arrived, logged by whoever received it.
3. Invoice — what the supplier is billing you for.

Three-way matching confirms all three line up before money moves. You ordered 100 units at €4, you received 100 units, you're billed 100 × €4. Match. Approve. Pay.

It's the cornerstone control in accounts payable because it catches the expensive quiet failures: paying for goods that never arrived, paying a price nobody agreed to, paying the same invoice twice. Skipping it is how a €5M payables book quietly leaks 1–2% to duplicate and erroneous payments.

2-way vs 3-way vs 4-way

Match type	Documents compared	Confirms	Where it fits
2-way	Invoice ↔ PO	You're billed what you agreed	Services, low-risk spend, no physical goods
3-way	Invoice ↔ PO ↔ goods receipt	...and it actually arrived	The default for goods purchases
4-way	+ inspection / quality record	...and it passed acceptance	Manufacturing, regulated goods

More documents, more control, more manual work. Which is the whole argument for automating it: the control is non-negotiable, the labor is.

The easy part and the hard part

Here's what every AP automation vendor demos: an invoice arrives, the software pulls the matching PO and receipt, everything agrees within tolerance, it auto-approves and posts to the ERP. Clean. Impressive. And roughly the easy half of the problem.

The invoices that match cleanly were never the ones eating your team's afternoon. The ones that hurt are the mismatches, and in most AP shops they're 20–40% of volume:

• Partial delivery. Ordered 100, received 60, invoiced 60. Correct, but it fails a naive match against the PO quantity.
• Unit-of-measure mismatch. PO in cases, receipt in eaches, invoice in kilos. Same goods, three number systems.
• Price drift. The supplier's price went up in March; the PO still says the old number. The invoice is right; the PO is stale.
• Freight and surcharges added at billing that were never on the PO.
• Missing goods receipt because the warehouse hasn't logged it yet.

Almost all of these are legitimate and resolvable. None are fraud. But traditional matching software treats them identically: match failed → exception → human queue. So your "automated" process still lands a daily pile on someone's desk, and each item needs a person to open three documents and figure out which kind of mismatch it is before deciding anything.

That's not automation. That's OCR with extra steps.

Tolerance: the dial most tools give you one of

Tolerance is the margin you allow before a difference counts as a mismatch. A 2% price tolerance lets rounding and freight through; a small quantity allowance absorbs partial-unit deliveries. Set it right and a chunk of those mismatches auto-approve.

The catch: most tools give you one global tolerance. But a 2% variance on a €50 stationery invoice and a 2% variance on a €200k capital order are not the same risk. Real control means tolerance that flexes by supplier, by spend category, by amount, tight where it matters, loose where it doesn't. One blunt number either buries you in exceptions or waves through errors.

What "reasoning through the mismatch" means

This is where an AI agent differs from old RPA. RPA follows a fixed rule: fields don't match → stop. It has no way to tell a partial delivery from a fraud attempt, so it escalates both.

An agent reads the reason the match failed and acts on it:

• Quantity short but the PO allows partial deliveries and the receipt confirms 60 arrived → match the 60, flag the open 40 for the next delivery, approve.
• Price higher than the PO but inside tolerance and consistent with the supplier's other recent invoices → approve, note the drift.
• Price higher and outside tolerance → stop, route to the buyer with the old and new price side by side and the supplier's price history attached.
• No goods receipt found → hold, ping the warehouse, don't approve on faith.

The routine variances resolve themselves. The genuine judgment calls, a first-time overspend, a real discrepancy, a fraud signal, go to a named approver with full context, not a raw diff. That's the human-in-the-loop model done right: the human sees only what actually needs a human, and sees it pre-analyzed.

Where matching sits in the pipeline

Matching isn't a standalone product. It's one stage in how AI invoice processing works: OCR reads the document, an LLM extracts the fields, validation checks the math, and then matching pairs it with the PO and receipt and posts the result. Get extraction wrong and you're matching garbage; get matching wrong and clean extraction still doesn't get you touchless.

And matching is the hinge of the whole accounts payable cycle. It's the step that decides whether an invoice approves itself or needs a person. Your touchless rate, the share of invoices that post with zero human input, is mostly a function of how well matching handles the mismatches, not how well extraction reads clean PDFs. Mature setups hit 60–80%; the gap between them and the 30% shops is almost entirely exception handling.

How OIDO does it

OIDO doesn't replace your ERP or ask you to rip out what you run. It connects to the systems you already have through MCP and integrations: the agent reads the invoice from your inbox, pulls the matching PO and goods receipt from your existing ERP, matches line by line against tolerance rules you set per supplier, and posts the approved result back, your ledger staying the source of truth.

The mismatches are the point. Instead of flagging every variance the same way, the agent reads what broke, resolves the routine cases within your boundaries, and routes only the real exceptions, each one arriving with the discrepancy already explained. You automate one workflow, watch the touchless rate climb, then add the next.

See it in context on the invoice processing use case, or if you're comparing tools to buy, the 10 best AI invoice processing software breaks down who does matching well.

The bottom line

Every AP tool can match the clean invoices. The ones that matter, the 20–40% that don't cleanly match, are where automation either pays off or quietly hands the work back to a human. Ask any matching tool one question: what happens to a mismatch? If the answer is "it goes to a queue," you've automated the easy half. If the answer is "it reads why it failed and resolves what it safely can," you've automated the part that was actually costing you.

Sources: NetSuite, Tipalti, Rillion.