What duplicate payments cost before anyone finds them

Duplicate payments cost most organizations between 0.8% and 2% of total annual disbursements, according to the American Productivity & Quality Center. A separate SAP Concur study found 1.29% of processed invoices are duplicates, averaging $2,034 each. The real cost is not the duplicate itself. It is the share never recovered because it was found too late.

Run the arithmetic against your own volume before reading further. A distributor processing 40,000 supplier invoices a year, at the 1.29% rate SAP Concur measured, issues roughly 516 duplicate invoices annually. At $2,034 average value, that is about $1.05 million leaving the business twice.

That number is not the one that should concern a CFO. The one that should is the percentage of it that never comes back.

‍

Why the recovery rate matters more than the duplicate rate

A duplicate caught before the payment run costs a few minutes. A duplicate caught during next month's supplier statement reconciliation costs a phone call and a credit note. A duplicate caught eleven months later, after the supplier has been acquired, changed accounting systems, or written the balance off to miscellaneous income, is usually gone.

The ACFE's Occupational Fraud 2026: A Report to the Nations found the median scheme ran about 12 months before detection across 2,402 cases in 143 countries. Detection lag is the variable that converts a controllable error into a permanent loss, and it behaves the same way for honest duplicates as it does for deliberate ones.

This is why "we run a duplicate report quarterly" is not a control. It is a recovery process, and a slow one.

‍

Why do duplicate payments occur if the ERP already checks for them?

Duplicate payments occur despite ERP duplicate checking because that check compares an exact match on three fields: vendor ID, invoice number, and invoice amount. If any one field differs by a single character, the check passes and the payment goes out. Most duplicate invoices differ in at least one field.

The three fields your ERP compares

The configuration differs by system, but the pattern holds across Sage 300, Epicor Vantage, QuickBooks Desktop, older Dynamics GP and NAV installs, and most in-house ERPs. The duplicate invoice warning is driven by a stored key, usually some combination of:

• Vendor ID, the internal record number, not the supplier's legal name
• Invoice number, as keyed, character for character
• Invoice amount, sometimes with a tolerance band, often without
• Invoice date, in some configurations

The check is a lookup. It asks whether a voucher already exists with this exact key. If the answer is no, the voucher posts.

That behaviour is correct. It is also narrow. A duplicate check that only catches identical keys catches only the duplicates that were already easy to catch.

‍

The three ways the check fails

Most guides on this topic give you a list of causes: data entry errors, duplicate vendor records, multiple invoice channels, rush payments, fraud. All accurate, all disconnected. Sorted by what actually happens inside the system, they collapse into three classes.

Notice what is absent from that table. The plain case, where a supplier emails the same invoice twice, it gets keyed twice with identical vendor ID, invoice number, and amount, and the ERP blocks the second one, does not appear. That case is handled. It is precisely why finance teams believe the control works.

Every duplicate that reaches the bank got there because the key was broken, the check was skipped, or the check looked in the wrong ledger.

‍

Where legacy ERP duplicate detection breaks down

Legacy ERP duplicate detection breaks at five specific points: the check fires at voucher entry rather than invoice arrival, invoices enter through channels that never reach voucher entry, the check is scoped to a single entity, partial payments and credit memos alter the amount field, and the vendor master file itself holds duplicate records.

The check fires at voucher entry, not at invoice arrival

There is a gap between the moment an invoice enters your organization and the moment it becomes a voucher. In most AP teams that gap is measured in days. The invoice sits in a shared inbox, on a file server, in a project manager's email, in a pile on a desk. The ERP knows nothing about any of it.

Bill.com's own guidance concedes the point in passing: accounting software may only be reconciled monthly from bank downloads, so by the time a duplicate has cleared the account it is too late to stop. That is the right diagnosis, and it identifies a design problem rather than a discipline problem. Every control the ERP offers sits downstream of the point where duplicates are created, which is also why they surface so late in the AP month-end close.

Invoices that never reach the checked path

Some invoices never become vouchers until after the money has moved. The rush payment authorized over the phone on the last day of the month. The wire sent from treasury against a PDF forwarded by a site manager. The manual cheque cut because a supplier threatened to hold a delivery. Each is entered into the ERP afterwards, as a record of something that already happened, and by then the duplicate check has nothing left to prevent.

Count your real arrival routes before assuming this does not apply to you. A shared AP inbox, a folder on a file server, an S3 bucket, a SQL table, records held inside the accounting system itself, and the personal inboxes of four managers who have been told twice to stop accepting invoices directly.

One supplier, two entities, two ledgers

Multi-entity groups run duplicate checks per company code by default. If the same invoice is keyed into the parent and into the operating subsidiary, both checks pass. Within each ledger, the invoice is genuinely unique.

This case gets almost no coverage, and it tends to produce the largest individual duplicates, because intercompany and shared-service invoices skew high value. A shared services centre processing for six entities is running six duplicate checks that cannot see one another.

Partial payments and credit memos break the amount field

A supplier invoices $84,200. You dispute $6,000 of it and pay $78,200. Three weeks later the dispute resolves and the balance is paid against the same invoice number. You now hold two vouchers with the same vendor, the same invoice number, and different amounts, both legitimate.

Run the sequence in reverse and you get a real duplicate that looks legitimate. The original $84,200 is paid, a credit memo for $6,000 is applied, and a re-keyed voucher for $78,200 posts cleanly because no prior voucher matches that amount. The amount field, the control most AP teams trust most, is the one ordinary commercial disputes break every month.

When the vendor master file generates the duplicates

Stripe, NetSuite, and Bill.com all identify duplicate vendor records as a cause, and all three are right. What they leave out is why the file gets that way and stays that way.

Vendor records duplicate for reasons the AP team does not control. A supplier relocates and a new record is created against the new address. A company is acquired and invoices under two names through the transition. Procurement adds a vendor under a trading name while finance holds the legal entity. NetSuite recommends one Tax ID per vendor and restricting master file access to a small authorized group, which is correct advice that most mid-market teams cannot follow, because the person who adds vendors is the person who processes the invoices.

Treat the vendor master file as a control that will degrade, not one you fix once.

‍

How duplicate payments and accounts payable fraud overlap

Duplicate payments and accounts payable fraud overlap because billing schemes, the most common form of asset misappropriation the ACFE tracks, produce transactions that look exactly like honest duplicates. An AP team that routinely writes duplicates off as clerical noise has trained itself not to investigate the anomaly that signals a live scheme.

The ACFE's Occupational Fraud 2026: A Report to the Nations analyzed 2,402 cases across 143 countries, totalling more than $3.4 billion in losses, with a median loss of $104,000 per case and a median duration of about 12 months before detection. Across the Report to the Nations series, billing schemes have consistently been identified as the most common form of asset misappropriation and one carrying a high median loss.

A billing scheme is, mechanically, a duplicate payment with intent. A supplier invoice is resubmitted with an altered reference. A shell vendor is set up with a name close enough to a real one to survive a glance. An employee approves a second payment and arranges for the refund to be redirected. Each one breaks the same composite key that honest duplicates break.

Two consequences follow.

First, your duplicate report is also a fraud report. If nobody reads it as one, a scheme runs for roughly the ACFE's median twelve months before anyone asks a question.

Second, and this is the trade-off no vendor guide names: tightening detection raises false positives. Widen the amount tolerance and every partial payment flags. Fuzzy-match invoice numbers and every branch-prefixed reference flags. Hand a two-person AP team 400 alerts a week and they stop reading them by week three, at which point the new control performs worse than the one it replaced. The ACFE found that 84% of perpetrators displayed at least one behavioural red flag before detection, which is a finding about attention rather than about software.

‍

How to find duplicate payments already in your ledger

Finding duplicate payments already in your ledger takes four queries: same vendor and same amount within a 90 day window, the same invoice number across different vendor IDs, invoice numbers normalized to strip punctuation and leading zeros, and the same amount and date across separate company codes.

Four queries that surface most of them

Query 1: Same vendor ID, same amount, payment dates within 90 days. Catches the classic resubmission. Expect heavy false positives from recurring fixed charges, so exclude rent, subscriptions, and equipment leases before you start, or you will spend the first afternoon clearing them.

Query 2: Same invoice number, different vendor ID. Catches the duplicate vendor record case. False positive rate is low. Most hits here are real.

Query 3: Normalized invoice number. Strip spaces, hyphens, slashes, and leading zeros, then group. Catches INV-5656 against INV5656, and 0004512 against 4512. This is the query most finance teams have never run, and it is usually where the money is.

Query 4: Same amount, same invoice date, different company code. Catches the multi-entity failure. Only relevant if you run more than one ledger, and it requires pulling both sets into one place, which is why it rarely gets done.

Run all four against 24 months of history, not 12. Given the ACFE's 12 month median detection lag, a 12 month window systematically excludes the cases that have already cost the most.

‍

When a recovery audit is worth the contingency fee

Third-party recovery audit firms typically work on contingency, taking a percentage of what they recover. NetSuite's guidance notes that these audits both recover funds and help remediate the underlying controls, which is fair.

The honest version: a contingency audit earns its fee when transaction volume is high enough that the four queries above will never be run consistently in-house, and when nobody currently owns the follow-up. It is poor value when the queries have already been run, the findings are known, and the real blocker is that no one has time to chase 40 credit notes. That is a staffing problem, and paying a percentage of recoveries does not repair the process that produced them.

‍

How to prevent duplicate payments without replacing the ERP

Preventing duplicate payments without replacing the ERP requires three changes: match on a normalized key instead of an exact one, move the duplicate check upstream so it runs before the invoice is keyed, and close the channels that bypass entry entirely. None of the three requires an ERP migration.

Fix the key, not the symptom

Cleaning the vendor master file treats one symptom. Normalizing the matching key treats the cause.

A normalized key strips what varies without changing meaning: punctuation, spaces, leading zeros, case, and known supplier-specific prefixes. Match on that rather than the raw string and the INV-5656 problem disappears. Add a tolerance band on amount instead of exact equality and the partial payment case comes back into range.

The objection is predictable and usually correct. That is a change to matching logic, matching logic lives inside the ERP, and changing it is an IT project with a queue and a budget line. Which is exactly why the rule needs to live outside the ERP, and needs to be editable by the person who actually knows that one particular supplier prefixes every invoice with a two-letter branch code.

Move the check upstream of entry

The check should run when the invoice arrives, not when it is keyed. In practice that means every incoming invoice is captured, normalized, and compared against both open vouchers and paid history before anyone opens the ERP.

This is a sequencing change, not a software category. It closes the gap described earlier, where an invoice sits in an inbox for four days while the ERP knows nothing about it. It also produces the second-order benefit AP teams actually feel: a duplicate flagged at arrival costs one email to the supplier, while the same duplicate flagged at reconciliation costs a credit note, a ledger adjustment, and an awkward conversation.

Be realistic about what capture alone achieves here. OCR invoice processing reads fields off a page; it does not decide whether two readings describe the same obligation. The matching logic is the control, not the extraction.

Close the channels that bypass entry

Every route an invoice can take into the business needs to end at the same checkpoint. That is a plumbing problem, not a policy problem, and telling managers to stop forwarding invoices has a poor track record. The workable version routes each channel into one processing path automatically, so compliance does not depend on anyone changing a habit.

‍

What to check before buying duplicate payment software

Six capabilities separate a duplicate payment control from a duplicate payment report: normalized rather than exact matching, a check that fires before ERP entry, ingestion from every arrival route, cross-entity coverage, posting without an API, and named ownership of every exception raised. The last two narrow most shortlists sharply.

1. Normalized matching, tested on your own data. Hand the vendor INV-5656 and INV5656 during the demo and watch what happens. Demo datasets are clean by construction, so a clean demo proves nothing about your supplier file.
2. A check that fires before entry. Anything that evaluates after the voucher posts is a reporting tool. Useful for recovery, not a control.
3. Ingestion from every arrival route. Count your real channels first, including the manager inboxes nobody admits to, then hold the vendor's list against yours.
4. Cross-entity coverage. Most tools check one ledger at a time. If you run six company codes, this is the capability that decides the purchase.
5. Posting without an API. In legacy and desktop ERP environments this eliminates most of the market before pricing is discussed.
6. Named ownership of exceptions. A flagged duplicate needs to arrive with a person's name on it. If the vendor's answer is that it appears in a report, you are buying a list.

Cross-entity coverage and API-free posting are where most vendors quietly fail. Raise both in the first call, not the fourth.

‍

How LayerNext handles duplicate payments on legacy ERPs

LayerNext addresses duplicate payments by operating outside the ERP rather than inside it. Its agents ingest invoices from every arrival channel, apply per-supplier matching rules written in plain English, and post to the ERP through its own interface, including desktop systems with no API. Exceptions become assigned tasks rather than report lines.

Measured against the six criteria above, here is what that means in practice.

It posts to ERPs that have no API

Most AP automation depends on an integration endpoint. Epicor Vantage, QuickBooks Desktop, Sage 300 on-prem, older Dynamics GP installs, and in-house systems written by someone who left in 2011 do not have one, and replacing them is a multi-year project competing against every other capital request in the business.

LayerNext's computer-use agent operates the ERP through the application's own interface, the same way an AP clerk does, including desktop software with no web portal. No API, no middleware, no integration project. This is the constraint that decides most shortlists in legacy environments, which is why it is worth confirming before the pricing conversation. See the specifics for Epicor AP automation without an API and Sage AP automation.

Matching rules are written by finance, not by IT

The normalized-key fix described earlier only works if someone can encode supplier-specific logic, and only survives if that logic can be changed the week a supplier changes their numbering.

LayerNext holds these in a Business Rules section. Rules are written in plain English, held per entity, and edited by the finance team directly without waiting on a development cycle. The system uses an indexed rule search tree so the correct rule is retrieved by supplier name even when thousands of rules exist. That last detail is the one that matters at scale: per-supplier matching logic is only useful if it works past the twenty suppliers one person can hold in their head.

Every arrival channel feeds one checked path

The system ingests from a dedicated email address that listens for incoming files, a bot running on internal machines that pulls documents from local disks and retrieves records from the accounting software directly, connections to any SQL database inside the business, cloud storage including AWS S3 and Google Cloud, and API connections where they exist, such as QuickBooks.

The channel count is not the point. The point is that an invoice arriving by any route meets the same check at the same stage, which closes the bypass class of failure described earlier.

Exceptions become tasks with owners

When something needs a human decision, the agent creates a task in the enterprise portal rather than a line in a report. The example from LayerNext's own documentation is an invoice carrying the wrong tax for the province it shipped to: the system raises a todo, the reviewer looks it up by invoice number, and clears it with their judgment recorded.

A suspected duplicate behaves the same way. It reaches a named person with the invoice attached, and the queue shows whether anything is outstanding. When every task sits in Done, no human input is currently required. The Insight Board in the same portal shows processing counts and how many items are waiting on clarification.

This is the answer to the false-positive trade-off named earlier. The failure mode of nearly every duplicate control is not detection. It is that detection produces a list, and lists do not have owners.

Workflows change without a development cycle

Duplicate controls tighten over time. You add a rule after an incident, widen a tolerance after a month of noise, add a second approval on high-value suppliers.

Each of those is a workflow change, and in an ERP each one is a project. LayerNext workflows are configured as a sequence of steps rather than code, so a new validation step or an added check goes in without a development and testing cycle. That matters less on day one than in month nine, when the rules you wrote at go-live have met reality.

What this does not do

It does not clean your vendor master file for you, and a badly duplicated master file will still generate work. It does not remove the judgment call on a flagged exception; it routes that call to a person and records the answer. And any approach that reads an application's interface depends on that interface being reasonably stable, which is worth raising directly if your ERP is mid-upgrade.

For the wider picture of what this covers beyond duplicates, see AP automation software.

‍

Frequently asked questions

‍

‍