Agentic Duplicate Payment Detection: Catching the Same Invoice Paid Twice Before the Payment Run Executes
written by Cooter:Labs
published on September 13, 2026
Introduction
Duplicate payments are one of the most common — and most quietly expensive — leaks in accounts payable, and they happen for mundane reasons rather than fraud. A vendor resubmits an invoice because the first one "looked lost," using a slightly different invoice number or an added leading zero. A new employee sets up a vendor record that already exists under a different spelling or a different remit-to address, and the same invoice gets keyed in twice under two vendor IDs. Two payment runs in the same week both happen to pick up the same open item because a hold was lifted between them. Each of these looks completely normal in isolation: valid PO reference, valid GL code, an amount that matches what was actually owed. The problem only becomes visible when the vendor calls asking why they received two checks, or when a post-payment audit samples a handful of vendors and finds an overpayment that's been sitting there for months.
Three-way matching and contract-price checks answer the question "is this specific invoice legitimate on its own terms?" — right PO, right receipt, right price. Duplicate payment detection asks a different question: "has something functionally identical to this already been paid?" That requires comparing a new invoice against the entire history of payments already made or already queued, not just validating it in isolation, and doing that comparison has to tolerate the fact that a duplicate rarely looks like an exact copy — it looks like the same underlying obligation described slightly differently.
An exact match on invoice number against payment history catches the laziest duplicates and almost nothing else, because a resubmitted invoice usually arrives with the number changed — a suffix added, a leading zero dropped, or a completely new number if the vendor's system auto-generated it fresh. An agent that instead compares vendor, amount, PO reference, and invoice date within a tolerance window (same vendor, same amount to the cent, dates within a week or two, overlapping or absent PO context) catches the pattern a strict number match misses. The output at this stage isn't a block, it's a candidate: two records that look like they describe the same obligation, surfaced for a second-pass check before either one clears a payment run.
The harder case is a duplicate that spans two different vendor IDs — the same real-world supplier entered twice under a slightly different name, a different tax ID typo, or a different remit-to address, each with its own AP history. A duplicate check that only looks within a single vendor's invoice list will never catch this, because from that vendor record's point of view the invoice is unique. This is where duplicate-payment detection has to lean on the same fuzzy vendor-matching logic that catches duplicate vendor master records in the first place — normalized name, tax ID, and banking details — to group candidate invoices by the vendor they actually belong to before comparing amounts and dates, not by the vendor ID the ERP happens to have on file.
A duplicate caught after a check has cleared or an ACH batch has settled turns into a collections problem — someone has to call the vendor, ask for the money back, and hope the vendor's own AR team processes the refund before quarter-end reconciliation gets messy. The same check run against the pending payment queue, before the batch is submitted to the bank, turns the same finding into a one-line hold instead. That means the matching logic has to run as a gate on the payment-proposal step in the AP workflow — the point where open items get selected into a payment run — not as a periodic audit job that reports on payments already gone out the door.
A flagged pair of invoices isn't self-evidently a duplicate — it might be two genuinely separate invoices that happen to share an amount by coincidence (a recurring fixed-fee service, for instance), or a legitimate credit/rebill pair. The agent's job is to surface the comparison — both invoice images, the matched fields, and which ones matched exactly versus within tolerance — to an AP clerk who can open both documents and confirm in seconds, not to unilaterally cancel a payment based on a fuzzy match. Where the match is exact on every field (same vendor, same invoice number, same amount, same date), a harder hold before release is reasonable; where it's a fuzzy cross-vendor match, it should stay a flag for human review rather than an automatic block.
Looking Ahead: Challenges and Innovations
Recurring fixed-amount invoices are indistinguishable from duplicates on the numbers alone
A monthly software subscription, a fixed retainer, or a recurring lease payment produces the exact same vendor-amount pair every billing cycle, which is precisely the signature a naive duplicate check is looking for. Distinguishing a legitimate recurring charge from an actual duplicate requires the agent to know the billing cadence expected for that vendor relationship — monthly, quarterly, whatever the contract says — and only flag two payments to the same vendor for the same amount if they fall inside a single expected billing period rather than two consecutive ones. Getting this wrong in the direction of over-flagging trains the AP team to ignore the tool within a few cycles; getting it wrong in the other direction misses the actual duplicates hiding in a company's largest, most recurring vendor relationships.
Legitimate credit memos and rebills look like the fuzzy-match case the system is designed to catch
When a vendor issues a credit memo and then a corrected invoice for the same underlying transaction, the two documents can carry a similar amount, an overlapping date range, and clear references to the same PO — which is exactly the pattern the cross-record matching in phase two is built to surface. The agent needs visibility into credit memo and rebill relationships already recorded in the ERP, not just raw invoice and payment records, or it will keep flagging a normal correction workflow as a suspected duplicate. Where that linkage isn't tracked cleanly in the source system, the fix is upstream data hygiene, not more aggressive matching logic layered on top of a data gap.
The check has to run fast enough to not become the bottleneck in the payment run
A payment run for a mid-size company can select hundreds of open items at once, and a duplicate check that compares every new invoice against months of payment history in real time has to do that comparison efficiently enough not to turn a same-day payment proposal into an overnight batch job. In practice this means the fuzzy matching can't run an unindexed full-history scan for every invoice — it needs the payment history pre-indexed by vendor group, amount range, and date window so each check is a narrow lookup rather than a comparison against the entire ledger, which is an engineering constraint on the implementation as much as a logic problem.
The metaverse
As more AP volume moves through electronic invoicing networks and structured e-invoice formats rather than PDFs keyed in by hand, duplicate detection gets a cleaner signal to work from — a unique network-assigned invoice reference travels with the document instead of being retyped and altered on resubmission. That shifts duplicate-payment prevention away from probabilistic fuzzy matching on typed fields and toward closer to a deterministic lookup, which is the same trajectory most agentic AP controls are on: the harder, inference-heavy version of a check today becomes a straightforward verification once the upstream data is structured enough to support it.
Conclusion
Duplicate payments rarely come from anything as dramatic as fraud — they come from a resubmitted invoice, a second vendor record nobody noticed was a duplicate, or two payment runs that both happened to pick up the same open item. None of that shows up as a red flag to a person keying in a single invoice, and none of it gets caught by a three-way match that only checks whether one invoice is individually legitimate. Catching it means comparing every new invoice against the payment history that already exists — across vendor records, not just within one, and before the payment run executes rather than after the money has moved. That doesn't replace the AP clerk who decides whether a flagged pair is a real duplicate or a coincidental recurring charge; it makes sure that decision gets made before the check clears instead of after someone has to call the vendor and ask for a refund.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.