The duplicate payment that gets through.

A duplicate payment can begin like this: the same invoice arrives twice, and both copies pass.

Picture an invoice that reaches AP by email on Monday and through a supplier portal on Thursday. The second copy carries a slightly different reference. It sits against a second record for the same supplier, created some time ago. Every check runs and every check passes, so the payment run pays both. Nobody sees it until reconciliation. No alarm sounds along the way, because from the system’s side nothing has gone wrong.

The point is not that automation is missing. Duplicate payments get through because the data the automation checks against is split.

What are duplicate payments?

Duplicate payments are payments made more than once for the same invoice. Controls against them are not new. US government auditors have long said that payment controls should ensure that duplicate payments are avoided.

Duplicates are also one of the most quantifiable AP failures, because they show up in reconciliation. That makes them a useful place to look at how well your controls fit together, since a missed duplicate points straight back to the data behind the check.

Automation moved that check into software. It did not change what the check depends on. A duplicate check is only as good as the supplier and invoice data it can compare against. That data is where the gaps open up, and the check keeps passing while they do.

Why automated checks still miss duplicate payments

Automated checks compare each incoming invoice with the records they can see, so the system treats a duplicate that looks different as a new invoice.

The automation did exactly what it was built to do.

The failure was in the data it was checking against. That does not mean finance teams have been careless. Ordinary system design makes this failure likely. A duplicate can slip past in three ordinary ways.

A second route

An invoice can enter AP through more than one route, such as a mailbox, a portal or a business user’s inbox. If the check only looks at invoices that arrived the same way, the check may never compare a copy that arrives another way. Each route works as designed, yet the copy passes.

A slightly different reference

Matching can rely on the invoice reference. A re-sent invoice with a changed or re-keyed reference can therefore look new, even though it asks for the same money for the same work. A strict match sees a different reference and moves on. A person reading both invoices would see the same supplier and the same amount.

Two active records

The third way compounds the other two. When one supplier has two active records, the check may not compare an invoice paid against one record with the invoices paid against the other.

How a second supplier record hides a duplicate

A supplier with two records in the system looks like two different suppliers to the matching engine. The engine is not wrong. It matches exactly what it holds.

Records split in ordinary ways. Teams set a supplier up in more than one entity or system, or re-key its details years later, and no one notices that a record already exists. Garret Pearse, Finance Technology Consultant at SoftCo, put the consequence plainly in our Protect Every Payment webinar: “Duplicate supplier records muddy the water in terms of who you should be paying.”

This is the same data problem described in our piece on master data drift, where supplier records age while the world around them changes. Master data drift and duplicate payments are connected, because a duplicate is, in most cases, a downstream effect of fragmented master data.

The Supplier Control Framework starts from the same point. It treats the supplier, not the invoice on its own, as the unit of control.

How to test your duplicate check

You can test your own set-up without a project. Four questions show whether the check is comparing everything it should.

1. Does the check compare invoices across every route they can arrive through, or only within one?
2. Does matching depend on an exact invoice reference, or can it recognise a close one?
3. Can one supplier hold more than one active record, in one system or across several?
4. Who owns the decision to merge or retire a record, and when was it last made?

If any answer is “it depends” or “mostly”, the gap is in the data, not in the team. Controls exist at each point, but they operate on fragments. That is the pattern the framework calls control in isolation.

Question three is the quickest to answer. A supplier list sorted by name or bank details can show records that look alike, and that is often enough to tell you whether the gap exists.

Why recovery is not a control strategy

Duplicate payments show up in reconciliation, and by then the money has gone. The team’s work becomes finding the payment, contacting the supplier and waiting for a refund or a credit note. Meanwhile, the supplier record that let the duplicate through is still there, ready to do it again.

Finding a duplicate after payment is useful, but it measures the failure rather than preventing it, and it does nothing about the record behind it. That work is necessary, but it is clean-up. It happens after the control has already missed. Recovery is not a control strategy.

What one verified supplier record changes

One verified, active supplier record per supplier, in place before any invoice is processed, gives the matching check a single supplier to compare against, so an invoice paid against one record is no longer hidden from the check.

That is upstream control, and the framework names it as its first principle: push controls upstream. The matching control itself belongs to the invoice capture and validation stage, which we cover separately.

None of this needs a bigger team or another layer of checks. It needs the data the checks rely on to describe each supplier once. If your supplier records are split, your automation is already doing its job on the data it has. The next step is the data.