Why duplicates survive every control
A duplicate payment is not an anomaly in the data. Both transactions are legitimate-looking: correct supplier, plausible amount, valid approval trail. Nothing about either one is suspicious in isolation, which is exactly why they pass every check designed to catch things that look wrong.
They also do not announce themselves afterwards. The supplier's ledger absorbs the credit, your bank balance is slightly lower than expected for reasons nobody investigates, and the discovery — if it happens at all — comes months later during a statement reconciliation.
So detection is a deliberate exercise rather than a by-product of good process. It is also a fast one, once the payments are data.
The six ways duplicates actually occur
None of these require carelessness — they are structural, which is why every AP function has some.
| Pattern | How it happens | What it looks like |
|---|---|---|
| Re-sent invoice | Supplier chases with a fresh copy | Same amount, different invoice number |
| Two routes | One copy to AP, one to the buyer | Same invoice, two entries |
| Statement then invoice | Paid from a statement and the invoice | Same amount days apart |
| Manual plus batch | Urgent manual payment, then the run | Same day, two transactions |
| Vendor duplicated | Same supplier as two records | Different payee names, same bank details |
| Credit not applied | Payment made, credit ignored | Overpayment rather than a repeat |
What it actually costs
The direct cost is the payment itself, and whether you get it back depends entirely on the supplier's goodwill and cash position. A healthy supplier refunds or credits promptly; one in trouble may simply apply it to future invoices, or not respond at all.
The indirect cost is larger and quieter: the time spent discovering it, the reconciliation confusion it causes in the meantime, and the fact that a business making duplicate payments usually has other controls that are equally soft.
Studies and industry benchmarks quote error rates, and they vary too widely to be worth citing here. The honest framing is simpler: if you have never checked, you almost certainly have some, and finding out costs an hour.
The patterns that find them
Exact duplicates — same payee, same amount, same date — are the easiest and the rarest, because most systems block them. The valuable patterns are the near-misses.
Same payee and same amount within a short window, typically thirty days, catches the re-sent invoice and the manual-plus-batch case. Same invoice number across different payees catches the duplicated vendor record. Same amount to similar payee names catches the supplier entered twice under a trading name and a legal name.
And the amount-with-a-difference case: two payments where one is the other minus a small deduction, which is usually a settlement discount taken twice or a payment made both gross and net.
Running the check on your own payments
The check runs on your bank data rather than on your ledger, because the bank is where a payment actually happened — a duplicate that exists only in the ledger costs nothing, and one that exists only in the bank is invisible to a ledger check.
Convert the statements for the period into one table, then sort by payee and amount. Duplicates in the six patterns above become visible immediately: identical amounts to the same payee cluster together the moment the data is sorted rather than read.
Extraction also flags exact repeats automatically — same date, description and amount — as part of validation, which catches the obvious cases without any manual work at all.
The check on the invoice side
The payment check finds money that left twice. The invoice check finds the cause: the same invoice recorded twice, which is what produces the second payment.
Build an invoice register and look for repeated invoice numbers per supplier, repeated amounts on the same date, and near-identical supplier names. The last is the one that finds a vendor entered twice, which is the root cause of a whole class of duplicates rather than a single instance.
Doing both checks answers a question a single check cannot: whether you have a one-off error or a process that will keep producing them.
The pre-payment check that prevents most of them
Freeze the payment list
The set of invoices about to be paid, as a table.
Check within the run
Same supplier and amount appearing twice in the same batch.
Check against history
Each amount against the last ninety days for that supplier.
Check the numbers
Invoice numbers already marked as paid.
Check the vendors
Similar payee names with the same bank details.
Review, do not auto-drop
A flagged item is a question, not a decision.
The repeats that are not duplicates
Plenty of legitimate payments look like duplicates and must not be blocked. Recurring charges of the same amount — rent, subscriptions, retainers — repeat by design. Standing orders do the same on a schedule.
Genuinely identical purchases happen too: two units of the same item bought the same day, or two engineers expensing the same conference fee.
That is why the pre-run check flags rather than removes. A control that silently drops payments creates a different and worse problem — a supplier unpaid because an algorithm decided it looked familiar.
The duplicate supplier behind the duplicate payment
The single most productive fix is not a detection rule at all. It is cleaning the supplier list, because a supplier existing twice defeats every check that groups by payee.
Look for near-identical names, the same tax registration number under two records, and the same bank account under two names. Merge them, and a whole class of duplicates stops occurring.
An invoice register makes this a sorting exercise rather than a project: sort by supplier name and the near-duplicates sit next to each other, then confirm with the registration number rather than by eye.
Supplier statements find what your data cannot
Your own records cannot show you a duplicate the supplier recorded but you did not, or a credit they issued that you never applied. Their statement can.
That is why vendor statement reconciliation belongs alongside duplicate detection: it is the external check, and it frequently surfaces overpayments sitting as credits on the supplier's ledger that nobody on your side knew existed.
Run it on your largest suppliers monthly. Those are also the accounts where duplicates are most likely, simply because volume drives frequency.
Recovering one you already paid
Speed matters more than tone. Contact the supplier with the specifics — both payment dates, both amounts, the invoice reference — and ask for a refund or a credit against the next invoice. Vague messages produce vague responses.
A credit is usually easier for the supplier and perfectly acceptable if you trade regularly. A refund is worth insisting on if the relationship is ending or the amount is large relative to your normal spend.
Where a supplier is unresponsive or in difficulty, escalate early rather than politely waiting — an overpayment to a business that later fails is an unsecured claim, and those rarely end well.
What to send when you claim one back
Three things make a recovery straightforward: the two bank transactions with dates, amounts and references; the invoice both payments relate to; and, if you have it, the supplier's own statement showing the credit.
Extracted data provides the first without a search — one filtered table rather than a hunt through PDFs — and the source-file reference on every row is what lets you attach the exact statement page it came from.
Keep the claim and its outcome. Suppliers who have produced one duplicate frequently produce another, and a history is useful the second time.
A worked example: a year of payments
A wholesaler checks a year of payments for the first time. Statements from two accounts are converted into one table of about 2,400 outgoing transactions.
Sorting by payee and amount and applying the thirty-day window surfaces 19 candidate pairs. Eleven are legitimate recurring charges, two are genuinely identical purchases on the same day, and six are real duplicates.
Of the six, three came from a supplier who re-sent invoices with new numbers when chasing, two from the same supplier existing twice in the payment list under a trading name and a legal name, and one from an urgent manual payment that was also included in that week's batch.
Two were recovered as refunds, three as credits against future invoices, and one was already sitting as an unclaimed credit on the supplier's statement — which nobody had reconciled. Total afternoon's work.
The controls that stop them recurring
Detection is a safety net; the process fixes are what reduce the rate. One route for invoices, so a copy sent to a buyer does not enter the pipeline separately. A rule that payments are made from invoices rather than from statements. And a clean supplier master, checked when new records are created.
Separating whoever approves from whoever pays helps here too, as does never making urgent manual payments outside the batch without recording them in the same place.
None of that needs an AP platform. It needs the same discipline that makes every other AP control work, and a monthly check on the data to confirm it is holding.
Who should run this check
Any AP function
If it has never been checked, there is almost certainly something.
Businesses with many suppliers
Volume and vendor-record sprawl drive the rate.
Bookkeepers
A high-value check to run for clients at year end.
After a system migration
Where the same invoices can enter twice through two routes.
Why the data has to be complete
A duplicate check on incomplete payment data misses exactly what it was run to find, and worse, produces a false sense that the accounts are clean.
So the statements have to be provably whole: opening balance plus transactions equals the printed close, per account, with no missing periods between statements. Both checks are quick and both are automatic on extraction.
See extraction accuracy for what that proves and what it does not — it proves your data faithfully contains what the bank reported, not that every payment was correct.
How documents are handled
TLS in transit, processing in EU data centres, originals deleted immediately after extraction, extracted data encrypted at rest, no model training on customer documents — see security.
Choosing the comparison window
Every detection rule needs a time window, and the choice trades false positives against misses. These are sensible starting points to tune against your own data.
| Rule | Window | Catches |
|---|---|---|
| Same payee, same amount | 30 days | Re-sent invoices, manual plus batch |
| Same payee, same amount | 90 days | Slow re-send cycles; more noise |
| Same invoice number, any payee | 12 months | Duplicated vendor records |
| Similar payee, same amount | 30 days | Trading name vs legal name |
| Amount and near-amount | 30 days | Discount taken twice, gross and net |
| Round-number repeats | Exclude recurring | Subscriptions and rent create noise |
Duplicates through payment processors and cards
Card and processor payments create their own duplicate pattern: an invoice paid by card by one person and again by transfer by another, or a subscription charged to two different cards after a renewal.
These are harder to spot because the payee name on a card line is often the processor's descriptor rather than the supplier's, so grouping by payee does not bring them together. Sorting by amount within a window catches more of them than sorting by name.
Converting card statements alongside the bank account is what makes the check complete — the credit card statement is a separate document and its transactions are the ones most likely to be missed.
How often to run the check
Before every payment run for the pre-payment check, because that is the version that prevents rather than recovers. It adds minutes to a run that already exists.
Monthly for the retrospective check on actual bank data, alongside the statement reconciliation — the two find different things and both are quick once the data is extracted.
Annually as a sweep over the full year, ideally before year end, since recovery is easier while a relationship is current and while the supplier's own records still show the credit clearly.
The two moments duplicates spike
Duplicates are not uniformly distributed across the year. Two moments produce far more than the baseline, and both are predictable enough to plan around.
The first is a system migration. Invoices can enter twice — once in the old system and once in the new — and a payment run built from both is the classic outcome. Running a duplicate check on the first three payment runs after a cutover is cheap insurance, and it is exactly when nobody has spare attention.
The second is a staffing change or a busy period, where urgent manual payments are made outside the normal run and never recorded in the same place. The rule that prevents it is simple and rarely enforced: every manual payment gets logged where the batch is built, on the day it is made.
The check you can ask the supplier to run
Suppliers can see something you cannot: whether your account carries a credit balance. Asking a large supplier whether any unapplied credits or payments on account sit against you is a two-minute email that occasionally recovers real money.
It is also the fastest way to find an overpayment made years ago, which no amount of analysis on your own side will surface if the payment looked ordinary at the time.
Combine it with the statement reconciliation rather than treating it as separate — a statement showing a credit balance is the same finding arriving through a different door.
The boundary, stated plainly
FlowParse is a document-extraction engine, not an accounts-payable platform and not an ERP. It has no approval workflow, no purchase-order system, no vendor master, no payment execution and no ledger of its own. Nothing here approves, posts or pays anything.
What it does is turn the documents this work depends on — purchase orders, invoices, delivery and goods-received notes, supplier statements, remittance advice and bank statements — into structured, comparable data, with a completeness check on the statements so the numbers you compare are provably whole.
That is deliberately half the job. The other half — deciding what an exception means, approving a payment, posting a journal — belongs to your process and your people, and any tool claiming otherwise is describing something you would still have to supervise.
The one-hour version
Convert the last twelve months of your main payment account, sort by payee and amount, and look for the same amount to the same payee within thirty days. That is the highest-yield check and it takes an hour including the reading.
If it finds nothing, you have bought certainty cheaply. If it finds something, it has paid for itself several times over — and you now know to run it before every payment run instead of once a year.
Whatever the result, write down which patterns you checked and over what period. A duplicate check nobody documented gets repeated from scratch next year, and the value of the exercise compounds only if the next person can see what was already covered and where the gaps were.
Check a year of payments in an hour
Convert your statements, sort by payee and amount, and see every repeated payment — before the next run rather than after.