Duplicate Payment Detection: The Patterns That Slip Past 3-Way Match
Every construction AP system has duplicate payment detection built into its 3-way match logic. When an invoice comes in matching a PO and receiving report, the system checks whether a payment has already been issued for that invoice. If yes, the invoice is flagged. This catches the obvious duplicates — same invoice number, same amount, same vendor.
The less-obvious duplicates slip past basic matching. Same invoice resubmitted with a different number. Vendor records that look like the same vendor but have slight name or tax ID variations. The same work billed on two different POs (one for labor, one for materials) where the vendor double-dips. The same invoice submitted to two different project managers who each approve it without knowing about the other. These patterns require detection rules beyond simple exact matching.
Common patterns that slip past basic 3-way match:
Duplicate payment patterns to detect
- Re-billed invoices — vendor resubmits the same invoice with a new number (INV-1234 becomes INV-1234A or INV-1235) and hopes nobody notices the duplication
- Vendor record duplicates — the same vendor exists twice in the master, under slightly different names (ABC Plumbing Inc. vs ABC Plumbing, LLC), and the same invoice gets paid once to each
- Split billing across POs — the same work billed on two POs, where each PO-billing passes its own 3-way match independently
- Transposed-digit invoice numbers — INV-4321 and INV-3421 are different numbers to basic matching but may be the same physical invoice with a transcription error
- Email duplicates — an invoice emailed twice to AP, each time creating a separate record and each getting processed
- Approval-layer duplicates — same invoice approved by two different project managers on different projects, each triggering payment through their silo
- Credit/rebill pattern — vendor issues a credit and reinstates on a new number, but AP processes both the original payment and the rebill without netting the credit
Exact-match logic can be extended with fuzzy matching. For each new invoice, compare against recent invoices from the same vendor for approximate matches on:
Fuzzy invoice match signals
- Invoice number similarity — Levenshtein distance or similar string-distance metric catching single-digit changes or small variations
- Invoice amount similarity — same amount or very close amount on two invoices from same vendor within a short window
- Invoice date similarity — adjacent dates can indicate a re-billing pattern
- Line-item description match — same item described or same work period, even if invoice headers differ
A typical fuzzy-match rule: flag for review any invoice from the same vendor within 90 days where (invoice number has >80% string similarity to a previously-paid invoice) OR (amount is within 2% of a previously-paid amount) OR (line-item descriptions overlap >70%). The rule won't catch every duplicate and will flag some legitimate non-duplicates, but the flags come to human review rather than being silently paid.
Vendor master deduplication is foundational. When the same vendor exists as two records (different spellings, different addresses, different contact names), invoice matching treats them as different vendors — and the same invoice can pay to each.
Periodic vendor deduplication reviews — using tax ID as the authoritative key — catch these. Where two vendor records have the same tax ID, they're the same vendor, and the records should be merged (or one deactivated with all activity routed to the other). Without this discipline, the master gradually accumulates duplicate vendors as AP staff create new records for what they don't realize is an existing vendor.
TIN matching across the vendor master catches most of the vendor-duplicate pattern. Any two active vendor records with the same TIN should be consolidated. This cleanup pays for itself in avoided double-payments.
When the same work or materials can be billed against multiple POs, the pattern isn't duplicate-invoice-number — it's duplicate scope billed on different POs. Detection here requires looking beyond invoice-level matching at what's actually being billed.
Description-based matching can catch some of these. If one PO pays for "install HVAC equipment in Suite 201" and another PO has a line for "HVAC equipment installation, Suite 201," a description-similarity check flags the overlap. The AP reviewer can then investigate whether the work is genuinely split or whether it's double-billed.
More sophisticated detection uses field-recorded work completions — if a sub's daily reports show they completed a specific scope and both of the invoices now billing reference that same scope, it's suspicious. Tying invoice reviews to daily report and inspection data catches cross-PO duplication that pure invoice-level matching misses.
Adjacent-date duplicate detection catches the common pattern where a vendor submits an invoice, then resubmits it a few days later thinking the first didn't get through. Flag any invoice from the same vendor with a similar amount submitted within 14 days of another invoice. Most will be legitimate (different invoices submitted in sequence), but the few that are duplicates get caught.
Get AP insights in your inbox
A short monthly roundup of construction AP + accounting posts. No spam, ever.
No spam. Unsubscribe anytime.
Similarly, month-end billing that comes right after month-start billing from the same vendor deserves an extra look. A sub that billed progress through the 25th of the month and then bills again at month-end for the same period is potentially double-counting.
Credit memos and rebill patterns need specific handling. When a vendor issues a credit, the AP system should reduce the outstanding balance. When a rebill arrives, it replaces the credited amount. Without proper netting, the sequence "pay original invoice → receive credit → pay rebill" results in paying twice with a credit sitting in the system.
The AP system should track credit memos through to their offset, ensuring the credit is applied before any rebill pays. Reports that identify outstanding credit memos older than 30 days surface these situations before they become duplicate payments.
Modern AP automation can compare the actual images or PDFs of invoices. Two invoices with identical or near-identical visual content suggest the same invoice submitted twice — even if the invoice number was changed between submissions.
Image-hash or OCR-text comparison catches the pattern where a vendor re-exports the same invoice with a slight edit to the number. The underlying content is the same; the hash or text matches. This detection is particularly useful for vendors who routinely re-bill, where human reviewers might not remember each individual invoice's content.
A practical duplicate detection ruleset stacks multiple rules, each catching a different pattern:
A stacked duplicate detection ruleset
- Level 1 — exact match on vendor, invoice number, amount — block automatically
- Level 2 — exact match on vendor and invoice number, different amount — flag for review (likely legitimate amendment, but confirm)
- Level 3 — fuzzy match on invoice number (>80% similarity), same vendor — flag for review
- Level 4 — exact amount match, same vendor, within 90 days — flag for review
- Level 5 — tax ID match across different vendor records — flag for vendor deduplication
- Level 6 — image/OCR text similarity >90% — flag for review
- Level 7 — description overlap with paid invoice from same vendor within 90 days — flag for review
The goal isn't zero false positives — some flagged invoices will turn out legitimate — it's to surface the patterns for human review rather than silently pay them. A well-calibrated ruleset catches most true duplicates while keeping the review queue manageable.
Basic 3-way match catches the obvious duplicates but misses the sneakier patterns. Fuzzy invoice matching, vendor deduplication, cross-PO scope checks, credit memo reconciliation, and image-hash matching together catch the patterns that exact-match logic alone lets through. For construction AP at volume, a stacked detection ruleset surfaces likely duplicates for review rather than silently paying them. The patterns that slip past 3-way match are real, and the automation to catch them is mature — the question is whether it's actually deployed.
Written by
Alex Kim
Engineering Lead, AI
Engineering lead for Covinly's AI and ML systems. Previously built fraud detection at a B2B fintech. Writes about how AI actually reads invoices — the math, the edge cases, and why OCR alone isn't enough.
View all posts