Duplicate Payment Prevention: Agentic Checks Before Every Payment Run

Duplicate payment prevention is usually treated as a recovery exercise: an audit firm combs through last year's ledger and claws back what it can. A better approach stops the money leaving in the first place, by checking every line of the payment proposal before it goes to the bank. This article sets out the patterns behind duplicate and erroneous supplier payments, why standard ERP checks miss many of them, and the preventive checks an agent can run before each payment run. It also covers how to govern that agent so finance keeps control of every decision.

1. Why Do Duplicate Payments Still Happen?

Duplicates rarely come from carelessness alone. They come from the way invoices enter the organisation. The same supplier invoice might arrive as a PDF by email, as a paper copy posted to a site office and as a line on a reminder statement weeks later. Each route can create a separate document in the ERP, keyed by a different person. One clerk types the reference as INV-0042, another as 42. One posts it to the parent supplier, another to a vendor record created for a branch. The ERP sees two valid invoices.

Erroneous payments are a wider family. They include paying the wrong amount because a unit price was mistyped, paying a credit note as if it were an invoice, paying in the wrong currency, paying a supplier whose bank details were changed by a fraudster, and paying an invoice already settled manually. Good duplicate payment prevention has to cover this whole family, because the controls that catch one pattern often catch its neighbours. A check on recent bank detail changes protects against honest mistakes and deliberate fraud alike.

2. The Patterns Behind Erroneous Supplier Payments

The same patterns recur across ERPs and industries. Near-duplicate references with transposed digits, added prefixes or dropped leading zeros. Duplicate vendor records holding the same VAT registration or trade licence under two supplier IDs. Same supplier, same amount, different date, often where a statement line was keyed as a new invoice. Invoices split to sit under an approval limit. Urgent manual payments followed by the original invoice going through the normal run. Recurring charges such as rent posted twice in one period.

Take a distribution group with entities in Dubai and Riyadh that share a logistics provider. The provider invoices each entity separately but sometimes sends a consolidated invoice to group finance. If both the entity invoices and the consolidated one are posted, nothing in either ledger looks wrong. The duplication only shows when someone looks across entities, which is exactly where most ERP rules stop. Erroneous supplier payments of this kind are not exotic. They are the ordinary result of how multi-entity groups buy.

3. Where Standard Duplicate Invoice Detection Falls Short

Most ERPs ship with a duplicate invoice detection rule. In SAP, Oracle and Microsoft Dynamics 365 it typically checks for an exact match on a combination of supplier, reference, date, amount and company code. That rule is useful and should stay switched on. The weakness is that it is exact. Change one character in the reference, or post against a second vendor ID, and the invoice passes. Teams then loosen the rule, warnings multiply, and clerks learn to override them without reading.

Post-payment recovery audits catch some of what slips through, but they work on money that has already gone. Recovering an overpayment from a supplier is slow and awkward; recovering it from a fraudulent account is often impossible. Rule-based bots layered on the ERP help at the margin, yet they share the same rigidity: a bot comparing fields cannot judge that two differently worded invoices describe one delivery. The gap that duplicate payment prevention needs to close is judgement applied consistently, at volume, before release.

4. Duplicate Payment Prevention Checks an Agent Runs Before Every Payment Run

The agent sits between the payment proposal and its approval. When AP generates the proposal, the agent reads every line and tests it against open and paid items across all entities and a long window of history. It applies fuzzy matching to references, ignoring prefixes, spaces and leading zeros. It looks for the same amount within a short date range for one supplier, or for suppliers sharing a tax registration number. It compares invoice images and line items, so two documents describing the same delivery are flagged even when header data differs.

A second set of checks targets erroneous payments rather than duplicates. Has this vendor's bank account changed since the last payment, and was the change verified by call-back? Is a credit note being paid out instead of netted? Does the payment currency match the invoice and purchase order? Was the invoice already cleared by a manual payment or netting run? Is the supplier blocked or on a sanctions list? These are payment run controls most teams know they should apply but rarely have time to run on every line.

Where an invoice failed matching earlier in the process, the agent should know why. If your team already uses agents to triage three-way match exceptions, the pre-payment check can read that history rather than start again. Screening works best at two points: at invoice capture, so the duplicate never reaches the ledger, and at the payment run, as the final gate before cash leaves. The second gate matters because manual payments and late postings happen between the two.

5. Vendor Master Data Changes: The Highest-Risk Moment

Many of the most damaging erroneous payments trace back to vendor master data changes rather than to invoices. A supplier email asks to update bank details. The letterhead looks right, the tone is familiar, and a clerk makes the change. The next payment run sends the money to the new account. Accounts payable fraud prevention starts here, and it is the area where an agent adds the most protection for the least effort, because the signals are specific and the response is simple: hold and verify.

The agent should treat any change to bank details, payment terms or remittance address as a trigger. It checks when the change was made and by whom, whether the request came from the supplier's known email domain, whether an independent call-back was logged, and whether the new account's country matches the supplier's registration. Any payment to a recently changed account is held for human release. This depends on connected data, which is why a governed data layer linking the vendor master, change log and email metadata matters more than the model itself.

6. How Should Finance Govern a Pre-Payment Audit Agent?

An agent that can hold payments has real authority, so its decision rights need to be written down. It may flag a line, hold it from the proposal and explain why. It should not release a held payment, edit bank details or delete invoices. A named person approves every exception, and every check, outcome and override is logged with the evidence used. This is how AITHENTIC builds its agents: each has a defined role, decision rights, escalation logic and a full audit trail, and people approve exceptions.

Treat the agent as a control and test it like one. Internal audit should be able to sample held and released lines, read the reasoning and confirm thresholds were applied consistently. Watching false positives is part of that, because a pre-payment audit that holds too much gets bypassed as quickly as a noisy ERP warning. The principles of model risk management in finance apply directly: documented scope, periodic validation, versioned logic and a clear owner.

The practical answer to how to prevent duplicate payments at scale is to start narrow: one entity, one payment cycle and the checks with the clearest evidence, such as near-duplicate references and recent bank detail changes. Widen to cross-entity matching once the team trusts the holds. A small business with one entity and low volumes may find a disciplined ERP rule and a weekly review enough. For multi-ERP groups, an AP invoice verification agent screening before posting and before payment is the pattern behind AITHENTIC's published outcome of 70%+ touchless accounts payable with AED 1M+ leakage saved.

Key challenges

• Invoices arrive through several channels and get keyed more than once with slightly different data.
• Duplicate vendor records split one supplier's history across IDs and entities, hiding repeat charges.
• Exact-match ERP rules miss near-duplicates, and loosened rules create warnings that clerks override.
• Bank detail change requests are hard to verify and remain a common route for payment fraud.
• Urgent manual payments bypass the normal run and are rarely reconciled against invoices posted later.

The framework

A practical model is a two-gate control run by one agent with clear human ownership. Gate one sits at invoice capture: the agent normalises the reference, checks for exact and near duplicates across all entities and the vendor master, and stops suspect invoices before posting. Gate two sits at the payment proposal: the agent re-screens every line against paid history, manual payments and recent vendor master changes, then sorts each line into release, hold with reason, or block pending verification. AP owns the holds, treasury owns release, and internal audit samples the decision log on a regular cycle. Check logic and thresholds are versioned so any past decision can be reproduced.

How to implement it

1. Map every route by which invoices and payment requests enter the organisation, including inboxes, supplier portals, paper and manual payment forms.
2. Clean the vendor master by merging duplicate records that share tax registration numbers, trade licences or bank accounts.
3. Connect paid history, open items, vendor change logs and invoice images from every ERP into one governed data set the agent can query.
4. Define the agent's checks, decision rights and escalation paths in writing, and agree who may release a held payment.
5. Run the agent in shadow mode alongside the current payment run and compare its holds with what the team actually caught.
6. Switch to hold-and-explain mode for one entity, then extend across entities as false positives fall.

Frequently asked questions