The Subcontractor Invoice Paid Twice
The same invoice got paid twice. Eleven thousand dollars to a drywall subcontractor who had already been paid in March - and nobody caught it until the year-end review. It wasn't fraud. It was two people, two inboxes, and no one matching the invoice to the contract.
Here is the uncomfortable part: the team that paid it twice was a good team. Organized, busy, well-meaning. Which raises the question this article answers - if careful people keep paying the same invoice twice, the problem isn't the people. It's the gap between the invoice and the thing it's supposed to match.
How a duplicate actually gets paid
It rarely looks dramatic. The subcontractor submits a progress invoice in March; it gets approved, coded, and paid. In May the same invoice comes back - maybe because their own bookkeeping flagged it as outstanding, maybe because the PDF got forwarded a second time. A different person opens it this time. They see a valid invoice, a familiar vendor, a reasonable amount. They approve it. Two approvals, two payments, one piece of work.
Nobody did anything obviously wrong. Each approver checked what was in front of them. The failure is that what was in front of them never included the one fact that mattered: this work was already billed and already paid.
The real culprit: nothing ties the invoice to the contract
Every invoice is a claim against a commitment - a line in a contract, a purchase order, a schedule of values. When the invoice and the commitment live in the same place, a duplicate is obvious: the line is already marked paid. When they live apart - the contract in a folder, the invoice in email, the payment in the accounting system - there is no single screen where already paid shows up. You're relying on a human to remember a transaction from two months ago. Memory is not a control.
This is why the duplicate-payment problem scales with how busy and how decentralized you are. More invoices, more approvers, more inboxes - more room for the same claim to slip through twice.
Invoices arrive by email. so there is no shared, ordered record of what came in and when.
Approval is per-document, not per-commitment. each invoice is judged on its own, never against the contract it draws down.
The contract lives somewhere else. answering how much is left on this agreement takes ten minutes, if anyone asks at all.
Different people approve different invoices. no one person holds the full payment history for a single vendor.
What the leakage actually costs
Industry rules of thumb put duplicate and over-payments at a fraction of a percent of total spend - small as a percentage, painful as a number. On a roughly $40-million capital program, even a tenth of a percent is $40,000 walking out the door, usually never recovered because no one notices in time. The chart below shows the pattern: the tighter the link between invoice and contract, the smaller the leak.
The point isn't the exact figures - those vary by organization. The point is the shape. Matching invoices to a spreadsheet helps; matching them to the actual contract, in one system, nearly closes the gap. Control quality, not effort, is what moves the number.
What to do before the next cheque goes out
You don't need new software to start. You need one rule and one habit.
Match every invoice to a commitment. no contract line or purchase order, no payment. This single rule catches most duplicates on its own.
Keep a running tally per agreement. track invoiced-to-date against the contract value so an over-bill is visible immediately.
Give each vendor one payment history. one place where every invoice and payment for that subcontractor lives, so the second copy lands next to the first.
Eventually the spreadsheet buckles, and you want invoices, contracts, and payment status living in one auditable place - that's the gap we built XNM-VISION to close. But even on paper, the rule no commitment, no payment will catch the next double cheque before it clears.
We've watched this exact pattern play out with change orders nobody matched to the original scope - more anatomies of an overrun are here.
