Duplicate payment detection fails for a structural reason rather than a careless one: at the moment the second payment leaves, every system involved still looks correct. The payables account carries a debit balance nobody reads as an error, the bank balance still ties in total, the period closes on schedule. There is no alert to miss — which means detection cannot be a matter of noticing. It has to be a scan somebody runs on purpose.
And it has to be your scan. A supplier who has been paid twice is under no obligation to call, and in practice most of them do not. Recovery begins when you find it, not when they mention it.
Start by sizing your own exposure
APQC's process benchmarking data puts duplicate or erroneous payments at roughly 0.8% of annual disbursements for top-quartile organisations and around 2% for bottom-quartile ones. That is not a loss figure — most of what gets found comes back. It is the volume of money that went out incorrectly, and the part nobody ever finds is buried inside the same range.
One multiplication turns it into a scanning budget: annual supplier disbursements × 0.008. An organisation paying out TRY 750 million a year is looking at roughly TRY 6 million that may have left incorrectly even at top-quartile performance; at bottom-quartile performance the same company is looking at TRY 15 million. Run the percentage against your own disbursement total in your own currency, and keep the unit written down — the value of the number is not its precision, it is that a volume of this order should never pass unscanned by default.
The error rate underneath the number
None of this requires anyone to be careless. In a Gartner survey of 497 accountants in July 2023, 18% said they make an error every day, 33% a few times a week and 59% a few times a month. Spreadsheets carry a rate of their own: in the field audits compiled by Raymond Panko, roughly 94% of the operational spreadsheets examined contained at least one error. (The line that circulates as "88% of spreadsheets contain errors" is a misreading — 88 is the number of spreadsheets audited, not a percentage.) If a payment run touches a spreadsheet anywhere, and most do, a non-zero error rate is the baseline assumption rather than a pessimistic one.
What the invoice-side control can and cannot see
The standard answer to all of this is that the ERP already blocks duplicate invoices. It blocks a duplicate invoice RECORD. That is a different object from a duplicate PAYMENT, and the distance between the two is where the money goes.
The common pattern in accounts payable systems is a key built from the vendor record plus the invoice number, often with the amount added, evaluated when the invoice is entered. Exactly which fields your package compares, and exactly when it evaluates them, is a configuration question worth confirming against your own system's documentation rather than assuming. What does not vary is the underlying logic — and that logic has three limits.
- A control resting on string equality cannot see a formatting variant.
INV2026000001234andINV-2026-000001234, or a number carrying a stray leading space, are two distinct strings. In hand-keyed supplier invoices that variation is the norm, not the exception. - A key containing the vendor record cannot compare across two vendor records. If the same supplier sits in master data twice under two spellings of the trading name, the first component of the key already differs and no comparison happens at all.
- A control evaluated at invoice entry cannot be evaluated at payment. Book an invoice once and pay it twice and nothing is ever tested. A prepayment or an urgent transfer that was never attached to an invoice sits outside its field of view entirely.
So the invoice-side control closes the crudest failure mode. Everything past that is visible only if you read backwards from where the money actually left: the bank statement.
Six routes a duplicate takes around the check
Paid outside the run. A same-day transfer is executed directly in the banking portal and posted to the ledger afterwards — or never posted, and paid again in the regular cycle. *Test:* tie every bank outflow in the period to a ledger entry. If the untied list is long, outcomes are being decided by luck rather than by process.
A line inside a batch instruction. One item in a bulk payment file is assumed to have dropped out and is settled separately, while the statement shows the batch as a single aggregate debit and absorbs the difference. *Test:* keep the batch file item by item and allocate the bank total across those items before matching anything.
A credit note that was never netted. The credit is issued but the payment line is never pulled from the run, so the credit is deducted and the gross invoice is paid as well. *Test:* for every supplier with a credit note in the period, compare payment and invoice totals separately instead of netting them first.
An advance that was never applied. Cash goes out against a proforma; when the invoice arrives the full amount is paid because nothing links the two. *Test:* scan supplier accounts for debit balances. A payables account sitting in debit is not a normal state — it usually means an unapplied advance or a duplicate.
One supplier, two vendor records. Same tax ID, two spellings of the trading name, the second copy of the invoice booked against the second record and both copies paid. *Test:* deduplicate master data on tax ID and put the payment histories of records sharing one side by side. Name similarity alone will not find them — abbreviations and diacritics make one company read as two.
Two spellings of one invoice number. Hyphens, spaces, zero padding, a Latin/Turkish character swap: one document, two keys. *Test:* strip the number to letters and digits before comparing, then run a second pass keyed on vendor, amount and a narrow date window.
What the six have in common is not inattention. Each of them looks entirely normal from inside a single system and becomes an anomaly only when ledger, bank and e-invoice data sit in the same table. Our article on detecting missing invoices and duplicate entries goes further into that scanning logic.
Three systems of record, one payment
Every supplier payment leaves a trace in three separate places: an entry in the ledger, a line on the bank statement, an electronic document on the tax authority's side. The three describe one event in three vocabularies — the ledger reasons in invoice numbers, the bank in free-text descriptions, the e-invoice system in its own document numbering. Nothing forces them to agree with each other.
In Turkey the seams are wide because the volumes are. The Revenue Administration's 2024 activity report records roughly 1 billion e-invoices and 11 billion e-archive documents issued in 2024; the e-invoice taxpayer population stood at 1,565,603. Those are two different measures — a document volume and the size of a registered population — and the second is not a count of all taxpayers.
Direction matters as much as volume. In August 2020, Citibank intended to send 7.8 million dollars of interest on the Revlon loan and sent roughly 900 million dollars of principal instead. That was not a duplicate payment, but it is the same shape of failure: an instruction that looked correct inside one system became something else at the bank, and with no control sitting between the two, the party receiving the money was the one who found out first.
A worked example: reading backwards from a batch line
A fictional case, in a shape most accounts payable teams will recognise. A logistics supplier is paid in a weekly batch — 42 items, one debit on the statement. On the day the file goes out, the requesting department queries one of those items, an invoice for EUR 18,400, and the team believes it was pulled from the batch. Three days later it is settled by a single transfer so the supplier is not held up.
Nothing in the ledger objects. The batch posts and clears against a control account; the separate transfer posts against the invoice and clears; the supplier account ends the month EUR 18,400 in debit, which at a glance reads like an advance. The statement shows two outflows to the same beneficiary — one for the batch total, one for EUR 18,400 — and neither looks wrong on its own.
The only thing that surfaces it is allocating the batch total across its 42 items and then asking which document each bank outflow settles. Do that, and one invoice carries two settlements while one bank line has no unclaimed document left to attach to. Reconcile at the level of totals instead, and the month ties perfectly.
Seen from the other side of the relationship, this is the same defect as a paid invoice that still shows as open — phantom debt on a counterparty's statement is what triggers a good-faith second payment in the first place. The rule that follows works in both directions: never let a counterparty's statement authorise a payment on its own. A statement reflects how the other side applied what it received, not what you actually paid.
Recovering the money
Build the evidence pack before you make contact. Both bank advices, the invoice, and the match output showing two outflows settling one document. A claim opened that way starts at "how do we return this" instead of "did we really pay it twice."
Expect an offset rather than a refund. Where the trading relationship continues, the counterparty will usually propose deducting the amount from future invoices. That is workable, and it creates a second exposure if it is not tracked: amounts everyone believes were offset and never were. Agree it in writing and name the invoice it comes off.
Leave the balance where it is until it actually moves. The overpayment stays as a debit on the supplier account until the refund or offset happens. Dissolving it with a one-sided reclassification is the worst available option — it destroys the audit trail and leaves an unexplainable difference at period end. How the entry is finally closed depends on whether it ends in a refund or an offset; work that part through with your accountant.
A confirmation letter supports a claim without settling it. Under article 94 of the Turkish Commercial Code, a party that receives a statement of the current-account balance and does not object within one month is deemed to have accepted it. The nuance is load-bearing: that consequence operates within a written current-account agreement — article 89 makes written form a condition of validity — so where no written agreement exists, silence in response to a confirmation letter may not by itself amount to acceptance. "We sent the statement and nobody objected" is not a substitute for the claim.
Three controls that stop it recurring
Make the tax ID the identity. Name similarity produces candidates; the tax ID decides. Validate it as a mandatory field when a vendor record is created and one of the six routes above stops existing.
Measure unmatched lines, not the balance. The month-end target is not "the bank balance agrees" but "unmatched bank lines are close to zero." The first validates a total, the second validates the items inside it — and a duplicate payment is invisible to the first. Ventana Research found in 2023 that 58% of organisations close within six business days while only 31% have automated most or all of their reconciliations: fast closes, manual matching. Our bank reconciliation page sets out the line-level version of this, and the step-by-step guide walks through the mechanics.
Screen the payment file before it is released. Same tax ID, similar amount, narrow date window. This is not an approval gate; it is a question generator that asks a person whether two rows are the same invoice.
Where iFinances fits
iFinances puts your ledger or ERP records, your bank statement and your e-invoice data into a single table and works to tie every bank line to a document. The engine handles FIFO and invoice-specific settlement, partial payment splitting, batch allocation and cent-level tolerance, and uses official central bank rates across currencies. Matching a bank description to a vendor record uses Turkish-character-folded name similarity — but that produces a SUGGESTION, and a person decides.
Every match carries a written rationale: the amounts agree, the dates align, this reference points to that invoice. Unmatched lines and out-of-pattern amounts are flagged as anomalies, which is where most of the six routes above surface. The counterparty can upload their own statement through a secure link and needs no software of their own. Excel and CSV ingestion is ERP-independent: Logo, SAP, Mikro, Netsis, Luca, Zirve or plain Excel.
To be explicit about the boundary: iFinances does not keep your books, does not create entries and never settles a line on its own. It makes the gap between the instruction and the bank visible, with the reasoning attached. The claim and the correcting entry remain yours.
Frequently Asked Questions
What is the fastest way to run duplicate payment detection on a past period?
Work from the bank side rather than the ledger side. Export every outflow in the period, tie each one to an invoice or document, and treat whatever will not tie as your review list — that single pass reaches the cases an invoice-number check structurally cannot. Layer three cheap scans on top: debit balances on payables accounts, vendor records sharing a tax ID, and invoice numbers normalised to letters and digits then re-keyed on vendor, amount and a narrow date window. Allocate any batch payment file across its items first, or the whole batch hides behind one aggregate line.
How do you recover a duplicate payment once you find it?
You open the claim, and you should assume the counterparty will never raise it. Send an evidence pack rather than a query: both bank advices, the invoice, and the match output showing two outflows settling one document. Where the trading relationship continues, expect a proposal to offset the amount against future invoices instead of a cash refund. That is usually workable, provided the agreement is in writing and names the invoice the offset comes off — otherwise you have replaced one open item with another that everyone assumes was dealt with.
Our AP system flags duplicate invoices — why do duplicate payments still get through?
Because the two controls sit at different points in the process. A duplicate invoice check is evaluated when an invoice is recorded, on a key that includes the vendor record and the invoice number; whether it also compares amount or date depends on the package and how it was configured, so confirm your own setup against its documentation. Nothing about that key is tested again when a payment is released. A copy booked under a second vendor record, a number keyed with different punctuation, a transfer made by hand in the banking portal, or an advance never applied before the invoice is paid in full will all pass. The invoice-side control needs a payment-side counterpart that works from the bank statement.
How often should we scan for duplicate payments?
Tie the scan to the close: each month, tie the period's bank outflows to documents and review what does not tie. Once the data extract is repeatable that is an afternoon of work, not a project. Add a second, lighter pass immediately before each payment run — same tax ID, similar amount, narrow date window — because catching a duplicate before the money leaves removes the recovery problem altogether. Annual sweeps do find money, but they find it after a year of somebody else holding it.
✦ iFinances — See what you're missing.
