You catch it on the bank statement, not before. Two payments to the same vendor, three days apart, same amount. Someone has to call the vendor, ask for the money back, and hope there's a future invoice to net it against — because an actual refund check is its own multi-week process.
That's the version everyone recognizes. The quieter version is worse: it never gets caught at all, because nothing ever looked wrong. The second payment was for a slightly different amount, or landed in a different month, and it just reads as a normal expense.
How a duplicate actually gets in
"Someone entered it twice" undersells how this actually happens. In practice, duplicate invoices get into an AP process a handful of specific ways, over and over:
- The same invoice arrives twice. A vendor emails an invoice, and it also shows up in a vendor portal or the mail. Two people — or the same person on two different days — process each copy as if it's new.
- A reminder invoice looks new. A vendor sends a "friendly reminder" 30 days after the original, because their AR system doesn't know it's already been paid. If your AP process can't quickly confirm "we already paid this," the reminder gets processed as a fresh bill.
- The vendor exists twice in your books. "Ace Supply," "Ace Supply Co.," and "Ace Supply Company" are three different vendor records to most accounting software, even though they're the same company. An invoice paid under one record doesn't get checked against invoices already paid under the others.
- More than one intake channel, no single point of entry. Email, a physical mailbox, a vendor portal, a forwarded message from someone else's inbox — when invoices can arrive from more than one direction, no single person or system ever sees the whole picture at once.
None of this requires anyone to be careless. It requires exactly the conditions most small and mid-sized AP processes actually run in: a handful of people, more than one channel, and volume that outpaces anyone's memory.
Why "just double-check" doesn't hold up at volume
The standard advice is to search for the vendor and amount before approving anything. That's genuinely good practice — worth doing regardless of what tools you use, and more on that below. But it depends on the invoice actually being searchable: the vendor name spelled the same way as last time, an invoice number that's actually unique instead of reused across renewal cycles, an amount that hasn't been re-typed with a transposed digit. It also depends on someone remembering to do it every time, including on the Friday afternoon when there are twenty more invoices in the queue than usual.
That's not really a discipline problem. It's a volume problem. A person can hold maybe a few dozen recent invoices in working memory. An AP process running at real volume has hundreds.
What it actually costs
This is common enough to have real research behind it, not just anecdotes. Benchmarking research from APQC (the American Productivity & Quality Center) puts duplicate or erroneous disbursements at roughly 0.8%–2% of a company's annual outgoing payments, and a widely cited SAP Concur analysis found that about 1.29% of processed invoices were duplicates — averaging just over $2,000 each (source). For a business paying out a few million dollars a year, that range isn't a rounding error. And that's before counting the time spent finding the mistake, contacting the vendor, and waiting on a refund that isn't guaranteed to come back at all.
What actually helps — with or without a tool
Two changes reduce duplicate payments meaningfully on their own, no software required:
- One intake point. Route every invoice — however it arrives — through a single inbox or person before it's entered anywhere. This alone closes the "multiple channels, no one sees the whole picture" gap, one of the most common causes above.
- A standard vendor naming convention, enforced when a new vendor is added, not cleaned up after the fact. One canonical name per vendor means a search for "who have we already paid" actually returns everyone you've paid.
Neither is glamorous. Both are free, and both work. It's the same shape of fix as a cost-center naming convention for project tracking — a naming discipline that costs nothing and makes everything downstream, manual or automated, work better.
Where it stops being something a person can catch reliably
Past a certain volume, checking every new invoice against everything already paid — by vendor, by amount, by date, by the actual content of the file itself — stops being a discipline problem and becomes a matching problem. And matching problems are exactly what's worth handing to a system instead of a person's memory.
That's what duplicate detection in ClarionOps does. Every new document is checked against everything already on file, two ways: an exact match on the file's content, which catches the same PDF re-uploaded or re-forwarded regardless of what it's named, and a fuzzy match on vendor plus invoice number, or vendor plus an amount and date close enough to be the same bill re-scanned. A flag isn't an automatic rejection — a reviewer sees a direct link to the original and either confirms it's a duplicate or dismisses the flag with a reason, logged like any other decision in the audit trail.
The single intake point and the vendor naming convention above are still worth doing regardless. They're what keeps the exceptions rare enough that a flagged duplicate stays the unusual thing it should be, instead of becoming background noise nobody has time to actually check.