Found fourteen months later, by the supplier
The shape of the story is almost always the same. A supplier calls about something unrelated and mentions, half apologetically, that their account shows a credit. Someone looks. An invoice from over a year ago was paid in March and again in April, and nobody in either organisation noticed until now.
What makes it worth studying is not the money. It is that every control worked exactly as designed and none of them had anything to say. The invoice was genuine both times. The approver was authorised both times. The bank paid what it was told to pay both times. The reconciliation balanced both months, because the money really did leave the account twice.
Duplicates are the purest example of an error that is invisible to record-level checking. Everything that examines one transaction at a time will pass them, and most of what a finance function does examines one transaction at a time.
Why they are invisible
Most errors are detectable because something about the record is wrong: a figure does not add up, a field is missing, a value is implausible. Reviewing the record finds them.
A duplicate has no such property. Examine either payment in isolation and it is impeccable. There is a matching invoice, an approval, a supplier who genuinely provided something, and a bank movement confirming it. If you were auditing that single transaction you would sign it off, correctly.
And the reconciliation confirms it too, which surprises people. Reconciliation asks whether the money moved as recorded, and it did — twice, as recorded. Paying the same invoice twice is precisely the class of error a reconciliation is structurally incapable of noticing, as covered in what "reconciled" actually proves.
So the error lives in a relationship rather than in a record, and finding it requires deliberately comparing records to each other. Nothing in a normal month does that.
Where they actually come from
Almost none of these involve anyone doing anything wrong, which is part of why they persist — there is no negligence to find and correct.
Two channels. The invoice is emailed to a person and also to a shared inbox, or posted and emailed. Two people process it in good faith, each unaware the other has it. This is the most common origin by some distance.
The chasing copy. A supplier resends an invoice because it is approaching its due date. The copy carries no obvious marking that it is a reminder, so it enters the process as a new document.
The interrupted payment run. A run fails partway. Someone re-runs it. Whether the first half gets paid twice depends entirely on whether the process was designed to be safely repeatable, and many are not.
The urgent payment. Something is paid manually, outside the normal run, because it is late or someone is chasing. The invoice remains in the system as unpaid, and the next run pays it again.
The duplicated supplier. The same company exists twice in the master file under a trading name and a legal name. Each record has one invoice; the system sees no duplicate at all.
The unapplied credit. A supplier issues a credit note and re-invoices. The credit never gets applied, so the re-invoice is paid in full and the original was already paid.
Why built-in detection misses the real ones
Most accounting systems have duplicate detection, and most of it compares supplier, invoice number and amount for an exact match. Against a genuine accidental re-entry of identical data, it works.
Real duplicates are almost never identical. They differ in exactly one field, and any single difference defeats an exact match completely. The check is not broken — it is answering a narrower question than the one people believe it is answering.
That gap between the question asked and the question assumed is the whole problem. Everyone believes duplicates are covered because a duplicate check exists, so nobody looks for the cases it cannot see.
| What differs between the two entries | Why it happens | Exact match finds it? |
|---|---|---|
| Invoice number punctuation | Typed by two people from the same document | No |
| Leading zeros in the reference | One entry keyed, one imported | No |
| Supplier record | Trading name and legal name both exist | No |
| Amount, by a rounding of pennies | One entry from a total, one from lines | No |
| Invoice date | One entered as received date | No |
| Nothing at all | Genuine re-entry of the same data | Yes |
The normalisation problem
An invoice number is a string, and the same invoice can produce several different strings. Punctuation appears or does not. Leading zeros survive keying or get dropped by a spreadsheet. Case varies. A prefix is included by one person and omitted by another.
The fix is straightforward and unreasonably effective: normalise before comparing. Strip punctuation and whitespace, fold case, remove leading zeros — and keep the original for display, because the supplier will quote it back to you in its original form.
Compare on the normalised value and a large share of the duplicates an exact match misses become exact matches. It is one of the highest-return changes available in accounts payable, and it is a few lines of logic.
Watch one trap: normalising too aggressively creates collisions. Some suppliers genuinely use short sequential numbers, and stripping everything distinctive can make two unrelated invoices look identical. Normalise, then compare within a supplier, and treat a match as a candidate for review rather than as a verdict.
A spreadsheet is often the culprit
Two records, one supplier
Duplicate detection is almost always scoped to a supplier — reasonably, since comparing every invoice against every other invoice is expensive and noisy. That scoping creates a precise blind spot: if the same company exists twice in the master file, its invoices are never compared.
Duplicated supplier records are extremely common. A company is set up under its trading name and later under its legal entity name. A merger brings two ledgers together. Someone creates a new record because they cannot find the existing one, which is itself usually a search problem rather than a discipline problem.
The fix is to scope duplicate checks by tax registration number rather than by supplier record, where you hold it. It is the identifier that is genuinely stable across name changes, spelling variants and separate records, and it costs nothing to use as the comparison key.
Alongside that, run a periodic review for likely duplicate supplier records: same registration number, same bank details, similar names, same address. Merging them removes the blind spot permanently rather than working around it.
The false-positive trap
The obvious response — make detection much more aggressive — fails in a way worth understanding, because it explains why so many organisations have detection that nobody uses.
Loosen the criteria and the flags multiply, and most of them are legitimate. Rent is the same amount every month. Retainers, subscriptions and standing charges repeat. A supplier delivering weekly bills similar amounts. Every one of those looks like a duplicate to a rule that compares supplier and amount.
When a check produces mostly noise, people stop reading it. Then the one real duplicate arrives in a list of forty false ones and is cleared along with them — and the organisation now has worse protection than if the check did not exist, because everyone believes duplicates are covered.
So the design goal is not maximum sensitivity. It is a small number of high-quality signals that a person will actually review. Two or three flags a month that get genuine attention beat forty that get bulk-cleared.
The other kind: duplicates in the data
There is a second family of duplicates that has nothing to do with paying anyone twice. It happens when the same transactions are imported twice, and it inflates rather than depletes.
The usual cause is overlapping statement periods. Someone downloads three months, then downloads a custom range that intersects it, or a bank issues both a monthly statement and a year-to-date summary. Every transaction in the overlap now exists twice, so turnover and expenses both rise while the closing balance still looks plausible.
Detect it by comparing periods rather than rows. Two identical rows are not necessarily duplicates — the same amount at the same shop on the same day is a perfectly ordinary Tuesday, and removing genuine repeats creates a gap in place of a duplicate. Compare the ranges the documents cover, which is unambiguous.
Where the source provides a stable transaction identifier, deduplication becomes exact rather than heuristic — one of the concrete advantages of structured formats described in CAMT.053 explained. The series-level checks that catch this are in the missing month problem.
The expense claim paid twice
A variant worth its own section, because it has a different mechanism and a different fix. An employee pays for something on a company card. The card transaction reaches the ledger through the statement. The employee also submits the receipt as an expense claim, and gets reimbursed.
The company has now paid for one lunch twice — once to the card provider and once to the employee. Neither record is wrong. The card statement genuinely shows a charge; the receipt genuinely shows a purchase. They are two views of the same event and nothing in the process knows they are related.
This is rarely deliberate. It usually happens when someone is unsure whether a card purchase needs a claim, and submits one to be safe, or when the card is new and the habit of claiming has not yet been unlearned. The amounts are individually small, which is exactly why nobody investigates them.
The detection is specific: for each expense claim, look for a card transaction with the same amount within a few days. Unlike the supplier case, false positives here are rare — a matching amount on a matching date between a claim and a card line is usually the same purchase, not a coincidence.
The prevention is a rule rather than a system: purchases on a company card are never claimed, full stop. It only works if the rule is unambiguous and everybody knows it, which is a management problem rather than a finance one — but it removes the origin entirely, which no amount of detection does.
How they are usually found
It is worth listing these honestly, because the pattern is uncomfortable: in most organisations, duplicates are found by accident or by the counterparty.
The supplier says so. The most common route, and it depends entirely on the supplier reconciling their own receivables carefully. Some do; some do not.
Chasing an unpaid invoice. Someone investigates an invoice that appears outstanding and discovers it was paid — twice.
A supplier statement reconciliation. Comparing what the supplier says you owe with what you think you owe. Effective, and rarely done outside the largest suppliers.
Year-end review. Sometimes, if someone looks at supplier balances rather than only at the total.
Notice that none of those is a control. They are all discovery by chance, which means the frequency of finding duplicates says more about how often people happen to look than about how often duplicates occur.
The strongest single signal
If you take one thing from this article, take this: review supplier accounts with credit balances every month.
A credit balance on a supplier account means you have paid more than you owe. There are innocent explanations — an unapplied credit note, a prepayment, a deposit — and each is worth knowing about anyway. But the most common reason is that something was paid twice.
What makes it the best signal is that it requires no matching logic at all. No normalisation, no thresholds, no fuzzy comparison, no false positives generated by rent. It is a list you can produce in seconds from any ledger, and every line on it deserves an explanation.
It also catches duplicates the clever checks cannot: a payment made against the wrong invoice, a supplier paid from two systems, a credit note issued and then also refunded. Anything that results in the supplier holding your money shows up here regardless of how it happened.
The checks worth running
Ordered by return on effort. The first two are close to free and find most of what there is to find.
| Check | Effort | What it catches |
|---|---|---|
| Supplier accounts in credit | Seconds, monthly | Anything that left you overpaid, however it happened |
| Normalised invoice number within supplier | One-off change | Punctuation, case and leading-zero variants |
| Same amount, same supplier, within 30 days | A query, monthly | Two-channel and manual-payment duplicates |
| Comparison keyed on tax registration | One-off change | Duplicated supplier records |
| Same amount, two suppliers with similar names | A query, quarterly | The duplicated-supplier case directly |
| Supplier statement reconciliation | Hours, for top suppliers | Almost everything, for those suppliers |
| Cross-year scan for the same amount | A query, annually | Duplicates that straddle a period boundary |
| Statement period overlap detection | Automatic | Imported duplicates on the data side |
Keep the judgement human. Every one of these produces candidates rather than conclusions, and each candidate usually has an ordinary explanation. The value is in producing a short list that someone actually reads.
A worked example
A supplier invoice for 8,450.00 arrives by email to the finance inbox and, because the project manager also asked for it, to her personal address. She forwards it for payment. It is entered and paid in March.
The finance inbox copy is processed a week later by someone else. The invoice number is written on the document with a hyphen; the first entry was keyed without it. The duplicate check compares the two strings, finds them different, and passes. It is approved and paid in April.
Both months reconcile perfectly. Both payments appear on the bank statement, both are matched to invoices, and nothing is outstanding. The supplier account now carries a credit of 8,450.00 that nobody looks at, because supplier balances are reviewed in total rather than individually.
Fourteen months later the supplier mentions it. Recovery is agreed as an offset against future invoices, which works because the relationship is ongoing.
| Control | Did it operate? | Why it did not catch this |
|---|---|---|
| Approval workflow | Yes, twice | Both invoices were genuine and correctly approved |
| Duplicate check | Yes | Compared strings that differed by one hyphen |
| Bank reconciliation | Yes, both months | The money genuinely moved, twice, as recorded |
| Supplier balance review | In total only | The individual credit balance was never seen |
| Year-end review | Yes | Looked at totals, not at accounts in credit |
Getting the money back
Recovery is usually possible and usually straightforward, and it gets harder with time — which is the practical argument for scheduled detection rather than opportunistic discovery.
The normal resolution is an offset against future invoices rather than a refund. Suppliers prefer it, it requires no payment run on their side, and for an ongoing relationship it is genuinely fine. Ask for a refund where the relationship is ending or the amount is large enough to matter to cash flow.
Evidence makes the conversation short. Both payment references, both dates, the invoice number, and the amount. Suppliers are generally cooperative when the case is clear, since their own records will show the same thing.
Where recovery genuinely fails — a supplier that has ceased trading, or a dispute — the amount has to be written off with a documented reason. Do it deliberately rather than leaving a stale credit balance sitting on the account, because a permanent unexplained credit is exactly what conceals the next duplicate.
Prevention that actually works
One entry point. Every invoice arrives at one address, whoever it was sent to. This single change removes the largest origin, and it is a process decision rather than a technical one.
Idempotent payment runs. A run that is interrupted and repeated must not pay anything twice. That means marking items as paid atomically with the payment instruction, not afterwards.
Urgent payments recorded immediately. The gap between paying something manually and recording it is the window in which the next run pays it again. Close the window by recording first.
One record per supplier. Enforced on tax registration, with a periodic merge review. Removes the blind spot rather than working around it.
Three-way matching where purchase orders exist. A second invoice against a fulfilled order has nothing left to match, which makes it a strong control — for the spend it covers. Its limits and mechanics are on three-way match, and the process discipline around it in running AP without a platform.
The real cost, which is not the money
A recovered duplicate costs little in cash. The cost is in what it reveals and what it consumes.
It consumes trust in the numbers. Once one duplicate is found, a reasonable person asks how many others there are, and the honest answer is that nobody knows — because the thing that found this one was chance. That question tends to produce a review that costs far more than the payment did.
It consumes the supplier relationship a little, particularly when they found it and you did not. And it consumes management attention disproportionately, because a duplicate payment is easy to understand and therefore easy to become concerned about.
Set against that, a monthly review of supplier accounts in credit is minutes. The asymmetry is the argument — not that duplicates are catastrophic, but that finding them is so much cheaper than the alternative of learning about them from someone else.
Key takeaways
A duplicate payment is two individually perfect records whose only fault is that both exist. Record-level review cannot see it, and neither can reconciliation, because the money genuinely moved exactly as recorded — twice.
Built-in duplicate detection compares exact strings, and real duplicates differ in one field: punctuation in an invoice number, a leading zero, or a supplier that exists twice. Normalising before comparison and keying on tax registration close both gaps for almost no effort.
The highest-value control needs no matching at all — review supplier accounts carrying credit balances every month. It has no false positives, requires no thresholds, and catches overpayments however they arose. Everything else in this article is an optimisation on top of it.
Frequently asked questions
Get a year of payments into one sheet
The same-amount, same-supplier scan needs the data in one place. Convert a year of statements into a single sheet with a source column, with overlapping periods detected rather than blindly merged.