How duplicate payments slip through AP

Every accounts-payable team has a story about a duplicate payment they caught before it went out. Fewer have a clear accounting of the ones they didn't catch. The uncomfortable truth is that duplicate payments are far more common than most organizations realize — industry estimates typically put accidental overpayments at 0.1–0.5% of total AP spend, which sounds small until you're running $5M through the ledger annually.

The problem isn't negligence. It's that duplicates are engineered by the conditions of normal AP workflow to look exactly like legitimate payments.

The most common entry points

Vendor resubmission after a "lost" invoice

Vendors follow up on unpaid invoices. Sometimes that means resubmitting the original invoice, often with a new date or a revised invoice number. If the original was already in queue — delayed by a vacation, a dispute, or a system migration — you end up with two entries for the same underlying delivery. Both look legitimate. Both might pass approval.

Purchase-order splitting and line-item rounding

When a vendor breaks a large order into multiple shipments and invoices each separately, each invoice looks like a fraction of the total. AP staff processing high volumes often can't hold the full order history in context. A shipment that was invoiced, held, and re-invoiced after a correction looks like two separate deliveries unless someone checks the item-level detail.

Portal payments plus emailed invoices

Many vendors now offer payment portals that let buyers pay directly. But they also send invoice emails through the usual AP workflow. Without tight coordination, the portal payment and the AP-processed payment can both go through — one as an ACH from the portal, one as a check from AP. The two channels don't share a ledger entry until the bank reconciliation catches the discrepancy.

Month-end and year-end pressure

High-volume close periods compress review time. Invoices that sat in queue get batch-processed. The approval shortcuts that accumulate under deadline pressure — "I'll check the backup documentation tomorrow" — create windows where duplicates slide through with a legitimate approval signature on both.

System migrations and ledger imports

When a company migrates to a new accounting system, historical invoices get imported in bulk. If the import doesn't de-duplicate on invoice number and vendor and amount, any invoice that existed in both old and new systems can end up paid twice: once from the old system's workflow before migration, once from the imported record in the new one.

Why standard controls don't catch all of them

Three-way matching (PO, receipt, invoice) is the standard control, but it only works if:

• The PO reference is consistent across documents (vendors don't always use your PO number)
• The receipt exists and is linked (drop shipments, services, and subscriptions often bypass this)
• The matching threshold is tight enough (many systems flag only exact matches, missing near-duplicates with a transposed digit or a slightly different amount)

Most AP systems also check invoice numbers for duplicates — but only within their own records. If a vendor changes their invoice numbering convention, or if a legitimate credit memo and a new invoice share a number, the check produces a false positive or misses the actual duplicate.

What duplicate detection in the ledger catches

Automated detection that works backward from the ledger — rather than forward from the intake workflow — catches what controls miss. By comparing paid transactions on vendor, amount, and date proximity, you can surface:

• Same vendor, same amount, payments within a configurable window (common for subscription renewals that get processed through both the vendor portal and AP)
• Same vendor, invoices with different numbers but identical amounts and near-identical dates
• Payments that reconcile to the same underlying PO or service delivery

The key difference from intake controls is that ledger-level detection operates on what actually happened, not what should have happened. It doesn't require the original documents — just the payment records — and it runs continuously, so it catches things that slipped through weeks or months ago, not just today's batch.

The recovery question

Catching a duplicate after payment is different from preventing one before. Most vendors will issue a credit on the next invoice or refund via ACH if approached promptly and professionally. The longer the gap, the harder the conversation. Which is another reason early detection — automated, continuous, and ledger-based — tends to recover more than periodic audits.

If you're running QuickBooks Online, the transaction history you need is already there. The question is whether you're looking at it systematically.