Why three-way matching fails in your ERP

ERPs ship with a three-way matching engine as standard — Dynamics 365 uses that very name in its interface — and yet real automatic matching falls short in many companies. The cause is almost never the engine: it is that the data never reaches it. Invoices that come in as PDFs with no lines extracted, paper delivery notes registered late or never, matching configured on totals and out-of-date price master data. The fix is not changing ERP: it is putting a capture and matching layer in front of it, and handing it back the invoice already verified and approved, as an importable CSV or Excel file.

The conversation repeats itself in any company with a mature ERP: "our system already does three-way matching". On paper, true. Dynamics 365 has its matching policies, SAP its tolerance keys, Sage and mid-market ERPs their purchasing modules with goods receipts. And yet, in day-to-day operations, the finance team still matches invoices by hand.

If you have the engine and you are still paying blind, the problem lies elsewhere. Almost always in one (or several) of these five points.

The five failure points

1. The invoice comes in as a PDF and nobody turns it into lines

The ERP engine matches structured records: lines with description, quantity and price. But the real invoice arrives as a PDF attached to an email. Someone has to key it in — and keying in 15 lines of an invoice takes minutes and produces errors. Typical result: only the header is keyed in (supplier, total, VAT) and line-by-line matching dies right there. The engine receives a total; it can only match totals.

Real three-way reconciliation between purchase order, delivery note and invoice requires line-by-line extraction. With classic template-based OCR it is painful; with IDP-style extraction it is feasible without configuring each supplier: IDP vs OCR.

2. The delivery note lives on paper and arrives late (or never)

It is the weakest link of the three. The delivery note is signed at the loading dock, at the bar or on the building site; it travels in a folder; it is registered days later, if at all. When the invoice arrives, the ERP has no goods receipt to match against and marks everything as pending. The "conditional approval so as not to delay payment" does the rest: pay first, verify never.

Operating rule: if the lag between physical delivery and registered goods receipt exceeds 24-48 hours, your three-way matching is nominal. Registration has to happen at receiving (mobile, scanner) or the same day in the office.

3. Matching is configured at header level, not line level

Many ERPs are implemented with matching in its loosest mode — totals matching with a generous percentage tolerance — because at go-live "that way nothing gets stuck". Nobody reviews it afterwards. The system approves everything whose sum matches, and offsetting errors slip through: paper 10% more expensive and four packs short on the same invoice add up to zero. The exact mechanism, with numbers, is in the trap of matching on totals.

4. The price master data is out of date

The invoice↔purchase order match compares against the purchase order price, and the purchase order inherits its price from the master data. If last quarter's negotiated rates were not loaded, the engine generates a chain of false exceptions — or worse: someone "fixes" the problem by widening the tolerance, and lets the real deviations through along the way. If your exception rate jumps suddenly, check master data before tolerances: how to calibrate tolerances (in Spanish).

5. Purchases without a formal purchase order

Without a purchase order there is nothing to match against. And in many SMEs a significant share of purchases is made by phone or WhatsApp: "send me 10 boxes tomorrow". The supplier delivers, invoices, and three-way matching is impossible by definition. It is not an ERP failure; it is process discipline. The workflow for these invoices — and how to reduce them — is in invoice without a purchase order.

How to tell if it is happening to you: three measurable symptoms

Inverted exception rate. If more than 40-50% of your invoices end up in manual review, the system is not filtering: it is getting in the way. In a healthy operation, 70-90% match on their own (touchless rate).
Delivery note-to-registration lag > 48h. Measure the difference between the delivery date and the goods receipt registration date. It is the least watched KPI and the one that explains the most.
Conditional approvals that are never regularised. Count how many invoices were approved "pending verification" last quarter and how many were actually verified afterwards. The gap between the two figures is your exposure.

Want these three numbers for your operation? Measure them on a sample of last month's invoices. If you want to see it with ininvoice, connect the mailbox and match new invoices without touching your ERP.

Want to match purchase order, delivery note and invoice today? The three-way matching Excel template does it line by line with formulas and tolerances; the three-way matching guide explains each step. Download the three-way matching template

How to fix it without changing ERP

The classic temptation is "we need a better ERP". Almost never. Your ERP's matching engine is probably fine; what is missing is the layer that feeds it. The architecture that works:

Capture at source. Invoices and delivery notes that arrive by email are picked up automatically (Gmail connection). Whatever arrives on paper is scanned on the day of receipt.
Line-by-line extraction without templates. Each document is turned into structured lines: description, quantity, pre-tax unit price.
Matching before the ERP. Invoice against purchase order and against delivery note, per line, with a calibrated tolerance (2% / €1.50 OR as a starting point). Whatever matches is ready for a person to approve and, once approved, is exported as a CSV or Excel file that can be imported into the ERP; whatever does not is resolved as an exception with the line and the euros flagged.
The ERP remains the system of record. Accounting, payments and audit stay where they are. The matching layer does not replace it: it feeds it with data that is finally up to the standard of its engine.

This separation — capture and verification in front, record-keeping behind — is why the fix is measured in days and not quarters. There is no migration, no consulting project, no risk to the system that already works. The concrete start-up plan is in implementing three-way matching step by step (in Spanish).

Frequently asked questions

My ERP is Dynamics 365 and it already has "three-way matching policies". Does this apply to me?: Dynamics policies (two-way or three-way matching by legal entity, item or item-supplier combination, with unit price and totals tolerances) work well when the invoice and the goods receipt come in structured and on time. The five failures in this article happen before those policies: at capture. If your invoices come in as PDFs and your delivery notes on paper, the policy has nothing to work with.
What if my volume of paper delivery notes is huge?: Prioritise by spend: the 10-15 suppliers that account for 70-80% of your purchasing volume can usually send a digital delivery note (a PDF by email will do) if asked. The remaining paper is scanned at receiving. You do not need to solve 100% in the first month; you need to solve 80% of the spend.
Does mandatory e-invoicing (the Crea y Crece law) fix this on its own?: It helps with the invoice: it will arrive structured. It does not fix the delivery note or the informal purchase order, which are two of the five failures. And the timeline still leaves some room; the analysis is in Crea y Crece and AP automation, and what it means for the receiving company, in what changes for companies with mandatory e-invoicing in 2027.
How long does it take to put the capture layer in front of the ERP?: With ininvoice, onboarding takes 24-48 hours: connect the mailbox, load suppliers and start matching. Fine-tuning of tolerances and exception handling is done with real data during the first month.
Isn't this duplicating what I already pay for in the ERP?: It completes it. The ERP records; the capture layer verifies before recording. Paying twice would mean having two systems of record — that you should avoid. The sign that the architecture is healthy: each piece of data has a single owner and the flow goes in one direction.

Three things to remember

The engine is not the problem; its diet is. No ERP can match unextracted PDFs or unregistered delivery notes.
Measure the delivery note-to-registration lag. If it exceeds 48 hours, your three-way matching is decorative, however many modules you have.
Fix it in front, not underneath. A capture and matching layer before the ERP; the ERP stays as the system of record. Days, not quarters.

Why three-way matching fails in your ERP (and how to fix it without replacing it)