Glossary · Payments

Duplicate payment: definition and how it works in accounts payable

Paying the same supplier obligation more than once, usually because the invoice was keyed with a different number, the supplier exists twice in the vendor master, or a statement or reminder was paid as well as the invoice.

Definition

Paying the same supplier obligation more than once, usually because the invoice was keyed with a different number, the supplier exists twice in the vendor master, or a statement or reminder was paid as well as the invoice.

Also called: double payment, paid twice

Example. Invoice INV-01043 for $8,420 is paid by ACH on the 3rd; the supplier's reminder, keyed as 1043, is paid by check on the 28th. The vendor now holds a $8,420 credit that the buyer must ask for back.

What it means

Duplicate payment, also called a double payment or being paid twice, is paying the same supplier obligation more than once. It covers the obvious second payment and the less obvious one: an invoice keyed under a different number, the same supplier set up twice in the vendor master, or a statement or reminder paid on top of the invoice. It is one kind of overpayment, but the defining point is the repeated obligation.

The practical test is not whether two payment records look identical. Exact repeats are usually blocked by the ERP; the ones that get through look different to the system: INV-1043, 1043 and 0001043. The obligation is the same, but the key, vendor record or payment route differs enough that the control does not catch it.

When the second payment leaves, the supplier usually holds the money as a credit on its ledger. A statement of account shows it. Recovery is a refund request or an offset against the next invoice, which is why the vendor record and the statement belong in the same review rather than in separate chores.

How it works in practice

Duplicate payment routes are ordinary AP work: one invoice paid by check and again by ACH, a payment run re-sent, two entities paying a shared supplier, or a reminder keyed as a new invoice. Each route leaves different evidence, so clerks should compare vendor, amount and obligation, not invoice number alone.

Invoice INV-01043 for $8,420 is paid by ACH on the 3rd; the supplier's reminder, keyed as 1043, is paid by check on the 28th. The vendor now holds a $8,420 credit that the buyer must ask for back.

Your ERP may stop exact repeats, but the control depends on clean vendor records and invoice keys. A clerk who keys 1043 from a reminder has created a new-looking item. A clerk who keys 0001043 has done the same. The payment then needs approval like any other, and the approval step is where the second payment should be questioned.

Where it goes wrong

The most common keying mistake is treating a reminder or statement as a fresh invoice. A clerk keying from the supplier's reminder may use 1043 while the original invoice carries INV-01043. Another may add or drop leading zeros: 0001043. The amount, vendor and due date can all look ordinary, so the item moves through review without a challenge.

Vendor master data causes a second family of errors. If the supplier exists twice in the vendor master, the same obligation can be paid under two records, and the statement of account may be requested for only one of them. A duplicate vendor record can also hide the credit that would otherwise offset the next invoice.

Payment-run and entity errors are easy to miss. A payment run re-sent after a bank-file issue, or two entities paying a shared supplier, can produce a second payment that looks like a different obligation. A supplier's reminder paid as well as the invoice is the same failure in slower motion: the reminder is not a new obligation.

What to check

Before release, compare the invoice with open items for the same vendor and amount. Ask whether 1043, INV-1043 and 0001043 point to one obligation. Check the vendor record for a second set-up of the same supplier. The invoice number is a key, not proof that the obligation is new.

After payment, use the statement of account to look for credits the supplier is holding. A debit balance in accounts payable can be the ledger signal that a supplier account is owed back, but the statement is the supplier's view and should be reconciled to your own open items. If the two disagree, trace the payment before requesting a refund.

Recovery is a refund request or an offset against the next invoice. Keep the request, the supplier response and the offset in the vendor record so the next clerk does not pay the credit out again. Rules and timing differ by country, company and contract, so check the contract and local policy before netting or writing off.

Controllers should look for patterns by vendor, payment method and entity, not only one invoice at a time. A vendor with repeated credits, a payment method that changes between check and ACH, or a shared supplier across entities deserves a closer review of the vendor record and the statement.

Questions

What causes a duplicate payment?

Duplicate payment usually comes from an invoice keyed under a different number, a supplier set up twice in the vendor master, or a statement or reminder paid as well as the invoice. It can also happen when one invoice is paid by check and again by ACH, a payment run is re-sent, or two entities pay a shared supplier.

How do I recover a duplicate payment from a supplier?

Ask the supplier for a refund or an offset against the next invoice, and support the request with the statement of account. The supplier usually holds the money as a credit on its ledger. Rules and timing differ by country, company and contract, so check the contract and local policy before agreeing to an offset.

How can AP prevent duplicate payments?

Keep the vendor master clean, compare invoice number variants such as INV-1043, 1043 and 0001043, and review the statement of account before paying a reminder. Check payment runs that are re-sent and payments made by more than one entity. Exact repeats are usually blocked by the ERP, so the review should focus on the payments that look different.

Updated Nov 6, 2026. Figures on this page are calculated by ERPSav from the definitions shown. The explanatory text is drafted with AI from those figures and checked automatically before it is published. General information only, not legal, tax or financial advice.