Duplicate Payment

A duplicate payment is the same vendor obligation paid more than once. It rarely happens because someone approved the identical invoice twice, that case is the one simple matching already catches. It happens because the second payment doesn't look identical: a vendor resubmits under a new invoice number after a slow response, an invoice gets re-keyed by a different person or into a different system after an ERP migration or an acquisition, or the vendor sits on file twice under slightly different names, "Acme Inc," "Acme, Inc.," "ACME INC", so the two payments never land next to each other in a straight invoice-number lookup.

That's why catching a duplicate payment is a population-level review, not a single-invoice control. Three-way match is a per-invoice gate applied before a payment goes out, and it's good at stopping an invoice for goods that were never ordered or never received. It isn't built to notice that a $4,200 payment cleared on the 3rd and the same $4,200 cleared again on the 17th under a different invoice number and a vendor name with a comma in a different place. That comparison only shows up once the full payment history is checked against itself.

A useful check can't rely on exact matches, because exact matches are exactly what a duplicate payment avoids. It has to compare across vendor name variants, fuzzy, not string-equal, amount, date proximity, and reference or invoice number, then rank what it finds by how confident the match is. An identical amount to the same vendor three days apart is a near-certain duplicate; a similar amount to a similarly named vendor two months apart is worth a look, not an assumption.

Once a duplicate is confirmed, recovery is the real work: a credit memo from the vendor, a refund request, or an offset against the vendor's next invoice, and someone has to own chasing it rather than just flagging it and moving on. A duplicate payment that's found but never recovered is functionally the same loss as one that was never found.

Related concept (not yet published as its own glossary entry): accounts payable.

Related skill: Duplicate payment scan

Go deeper: AP Automation

Comparing every payment against a vendor's full history for a name variant, a re-keyed invoice, or an amount that's just close enough is exactly the kind of volume work that eats a Controller's time without needing much judgment until a real candidate turns up. Adopt's agents already check incoming invoices against vendor history before they're paid, catching the duplicate before it goes out; for payments that already cleared, the same fuzzy-match approach runs as the duplicate payment scan skill, returning risk-ranked findings with evidence attached instead of a raw list to sort by hand. Sign up free.