Three-Way Matching + Duplicate Detection: Double Safety Net

A company we worked with paid a vendor $47,000 last quarter for an invoice that matched every control perfectly — valid PO, confirmed receipt, correct pricing. All green. The problem? They'd already paid that exact invoice two months earlier. Three-way matching approved it both times without blinking.

This happens more than people think. The Institute of Finance and Management puts duplicate payments at 0.1% to 0.5% of total AP spend. On $50 million in annual payables, that's $50,000 to $250,000 — gone. Not to fraud. Not to some exotic scheme. Just invoices that sailed through three-way matching twice because nobody asked "wait, didn't we already pay this?" The AP Association pegs 0.8% of all processed invoices as duplicates, and recovering those payments? That takes an average of 18 months. If they're caught at all.

Three-way matching answers one question: is this invoice legitimate? It was never designed to answer the equally expensive one: have we already paid it?

What Three-Way Matching Actually Does

At its core, three-way matching compares three documents before approving payment:

1. Purchase order (PO) — what your company agreed to buy, at what price and quantity
2. Invoice — what the vendor is billing you for
3. Goods receipt (GR) — confirmation that the goods or services were actually delivered

When all three line up — the PO says 500 units at $10, the invoice bills 500 units at $10, and the warehouse confirmed 500 units showed up — the invoice clears for payment. When they don't, it gets flagged. Simple enough.

This control is genuinely powerful. It catches pricing errors, quantity mismatches, invoices for goods that never arrived, and unauthorized purchases. There's a reason most organizations require PO-backed purchasing.

Some shops use two-way matching (PO vs. invoice, skipping the receipt) or four-way matching (adding inspection or quality checks). Three-way remains the standard. The blind spots we're about to cover apply to all variants.

The Blind Spots Three-Way Matching Can't See

Here's the thing about three-way matching: it validates a single invoice against its supporting documents. It never looks sideways. It doesn't compare invoices against each other. Think of it like a bouncer checking IDs at the door — great at spotting fake IDs, but completely oblivious if the same person walks in twice.

That creates four blind spots we see AP teams run into again and again.

Blind Spot 1: Same PO, Multiple Invoices

A vendor submits invoice #4521 against PO-2200. Three-way match passes. Two weeks later, the same vendor resubmits the charges under invoice #4521-R, claiming the first was "revised." Three-way matching runs again — PO exists, amounts match, goods were received. Passes again.

Both invoices matched the same PO perfectly. Neither triggered a flag. Why would they? Three-way matching only asks does this invoice match a valid PO? It never asks has another invoice already claimed this PO?

Blind Spot 2: Vendor Resubmissions with New Invoice Numbers

A vendor sends invoice #1088 in January. Paid. In March, the same vendor sends invoice #3045 for the identical amount, date, and line items — just a different invoice number. Maybe their AR team didn't mark the original as paid. Maybe their billing system auto-generated a duplicate. We've seen both.

Three-way matching won't catch this. The second invoice matches a valid PO and confirmed receipt. It looks completely legitimate. It just happens to duplicate a payment from two months ago. SAP's own research shows 25% of duplicate payments involve changed invoice numbers — the exact scenario three-way matching was never built to handle.

Blind Spot 3: Split Invoices and Partial Deliveries

You issue PO-3100 for 1,000 units. The vendor ships in two batches: invoice #A for 600 units, invoice #B for 400 units. Then a third invoice arrives for 400 units, also referencing PO-3100.

Three-way matching checks the PO (1,000 units authorized), sees a valid partial receipt, and may wave it through — especially if your tolerance thresholds sit at the common 5–10% range. Tracking cumulative totals across multiple partial invoices requires cross-invoice analysis. Three-way matching doesn't do that.

Blind Spot 4: Non-PO Invoices

Not every invoice has a purchase order. Recurring services, utilities, subscriptions, expense reimbursements — these often bypass the PO process entirely. For these invoices, three-way matching simply doesn't apply. There's no PO to match against.

And here's the kicker: Ardent Partners research shows 40–60% of invoices at mid-market companies are non-PO spend. That's a huge chunk of your payables with no matching control at all. In our experience, this is where duplicates hide most easily.

How Duplicate Detection Closes the Gap

Duplicate detection works on a fundamentally different axis. Instead of matching an invoice vertically against its PO and receipt, it matches horizontally — comparing every invoice against every other invoice in your system. It's less "is this invoice valid?" and more "have I seen this before?"

When a new invoice arrives, duplicate detection checks it across multiple dimensions:

• Exact match: identical file hash — the same PDF submitted twice. The easiest catch, yet ERPs routinely miss it.
• Invoice number + vendor: same vendor billing the same invoice number, even months apart.
• Amount + date + vendor: different invoice number but identical financial details. This is the classic resubmission pattern.
• Fuzzy matching: similar filenames, file sizes, or extracted text suggesting the same document was renamed and resubmitted.

Each layer catches duplicates that three-way matching cannot, because they compare across invoices rather than within a single invoice-to-PO relationship.

Running Both Controls Together

The most effective AP workflows we've seen run both controls in sequence on every invoice. Here's the practical breakdown:

Step 1: Invoice intake and data extraction. The invoice arrives via email, portal, or upload. OCR pulls the key fields: vendor name, invoice number, date, amount, line items, PO reference.

Step 2: Duplicate detection fires first. Before anyone touches the invoice, it's checked against your full invoice history. If it matches — exact file hash, same invoice number from the same vendor, or suspiciously similar financial details — it's flagged immediately. No point running a three-way match on something you've already paid.

Step 3: Three-way matching runs on surviving invoices. Invoices that clear duplicate detection move to PO matching. The system compares invoice details against the referenced PO and goods receipt. Price, quantity, or delivery mismatches get flagged.

Step 4: Approval routing. Clean invoices enter your normal approval workflow. Flagged invoices go to an exception queue with a specific reason — "potential duplicate of INV-4521 paid 2026-01-15" or "quantity exceeds PO by 12%." Your team knows exactly what to investigate.

Running duplicate detection first is a deliberate choice. Why waste time validating PO alignment for an invoice that's already been paid? It also catches resubmissions that three-way matching would approve without hesitation. Teams that add this step typically see 60–80% of duplicate catches happening before any manual review even starts.

When Each Control Fires

Scenario	Three-Way Match	Duplicate Detection
Invoice doesn't match PO amount	Catches it	Not relevant
Goods never received	Catches it	Not relevant
Same invoice submitted twice (same file)	Passes both times	Catches it
Vendor resubmits with new invoice number	Passes	Catches it
Multiple invoices against one PO	May pass	Catches cumulative overage
Non-PO invoice submitted twice	Not applicable	Catches it
Pricing error on first submission	Catches it	Not relevant

Different failure modes, different controls. Running one without the other leaves money on the table — and based on industry data, that money adds up to 1–2% of AP spend across both error types combined.

Why "We Have an ERP" Doesn't Cut It

We hear this one a lot. And yes, most ERPs include basic three-way matching. Some include rudimentary duplicate checks — usually limited to exact invoice number matches from the same vendor. That catches the obvious cases.

But the expensive duplicates aren't the obvious ones. Resubmissions with changed invoice numbers, cross-entity duplicates in multi-subsidiary environments, fuzzy matches where the same PDF was slightly modified before resubmission — these slip right through standard ERP checks.

A 2024 Gartner survey found that 73% of finance leaders using major ERP platforms still experienced duplicate payments in the prior 12 months. Built-in checks provide a floor. They're not a ceiling.

Dedicated duplicate detection fills the gaps ERP checks leave open: historical lookups spanning months or years, multi-field fuzzy matching, and file-level analysis that catches renamed or re-scanned documents.

Building Your Double Safety Net

If your AP process relies on three-way matching alone, adding duplicate detection is probably the highest-ROI improvement you can make to your payment controls. Every invoice it catches is one your existing controls already approved. That's recovered money, not prevented cost.

Start with your highest-risk categories: non-PO spend, vendors with high invoice volume, and any area where you've found duplicates before. Run a retrospective scan on your last 12 months of payables. Most teams we work with find 0.1–0.5% of spend recoverable on the first pass — and the look on a controller's face when they see the results is always the same.

Three-way matching tells you the invoice is real. Duplicate detection tells you it's the only one. You need both.

Try DupeInvoice free — upload your invoices and see what your three-way match missed.