Multi-entity businesses lose money to duplicate payments more often than almost any other single leakage — and it's rarely fraud. It's usually two entities, or two people in the same entity, both processing the same vendor invoice because nobody had a single source of truth telling them it was already paid.
By the time it's caught the normal way — a vendor calling to say they were paid twice, or an audit six months later — the cash is already gone and getting it back means an awkward conversation and a wait. The entire point of catching it in SQL is catching it before the payment run, not after.
Why this needs a database, not a spreadsheet
A single entity can sometimes get away with checking for duplicate payments in Excel — cross-referencing a payment register against itself isn't hard at a few hundred rows. It falls apart the moment there's more than one entity, more than one bank account, and vendors who get paid from different legal entities against the same underlying invoice. That's a join across tables, not a lookup within one sheet — which is exactly the kind of question SQL is built to answer and Excel isn't.
The logic, in plain language
The SQL query groups payments by vendor, invoice number and amount, then flags any group where more than one payment record exists within a defined window — say, thirty days — across any entity, not just within one. It doesn't matter whether the duplicate happened because two people in two entities both saw an open invoice, or because a vendor sent the same invoice twice with a different reference number. If the vendor, the amount and the timing line up, it gets flagged for a human to look at before the payment goes out, not after.
What Gets Flagged
Where the real saving is
The saving isn't just the duplicate payment itself, though that's real money. It's the time nobody spends chasing a vendor to return an overpayment, the awkwardness avoided in that vendor relationship, and — more quietly — the fact that a working duplicate-payment check tends to make everyone processing payments a little more careful, because they know something is checking. That last part doesn't show up in any single number, but it's often the bigger effect over a year.
The best fraud and error controls aren't the ones that catch the most incidents. They're the ones that mean fewer incidents happen in the first place, because everyone knows the check exists.
This is one SQL query out of a much longer list — ageing buckets, month-over-month variance, GST reconciliation — all written once as reusable logic against a standard chart of accounts, so a finance team stops re-solving the same problem every single cycle.