How Developers Quietly Overpay on Contracts
A developer in our market overpaid a contractor by more than $100,000. Nobody on their team caught it. The AP clerk paid every invoice that came in, on time, exactly as she’d been asked. The contract lived in a spreadsheet only the project manager had open. Change orders were in a different file. Contingency was a number on a whiteboard. Nothing in the accounting system knew that the total paid had crossed the contract value plus approved changes.
They found out because the contractor was honest enough to send the money back.
That’s the part worth sitting with. It wasn’t a careless team or a dishonest vendor. It was good people running a real business on a system that couldn’t see what had been committed versus what had been paid. And it’s not always going to be a contractor who returns the money.
Why overpayments happen — the three places they hide
Contract overpayments aren’t one mistake. They’re the predictable result of contract data and invoice data living in different places. They hide in three spots, and for most developers running construction in spreadsheets, all three are present at once:
- Change orders that never made it into the contract value. Approved verbally or over email, agreed by everyone — but never formally added to the contract document the AP team can see.
- Contingency draws treated as standard invoices. Paid out of the contingency pool without anyone tracking what’s left against it.
- A contract value the AP clerk doesn’t have open. The number sits in a spreadsheet the project manager maintains, not in front of the person approving the next invoice.
When two or three of these are true, the AP team is approving invoices against air. They don’t know the contract value, whether a change order was approved, or whether contingency is used up. Nobody is being careless — the system just isn’t built to give them the answer. That’s why these overpayments are so quiet, and why they tend to be bigger than people expect.
What catches it before the check cuts
The fix isn’t a stronger AP team. Your AP team is already doing what it was asked to do. The fix is that the invoice can’t be approved unless the system can see four things at once:
- The contract value
- All approved change orders
- All contingency draws against this contract
- Everything already paid to this vendor against this contract
When those four numbers live in the same system as the AP queue, the next invoice gets matched against them before it goes out for approval. If approving it would push you past the contract value plus approved changes, the system stops the workflow — not a yellow flag, a red one. You can still pay it: issue a new change order to cover it, or override with multi-party approval that lands in the audit trail forever. You just can’t pay it by accident.
Stopping a $30,000 overpayment is worth more than any month-end report. Stopping a $100,000 one is worth more than the entire implementation.
It’s not about your team. It’s about the system.
Every developer we tell this story to has the same first reaction: “our team is too good for that to happen here.” So was the team in the story. The overpayment had nothing to do with how careful they were and everything to do with a system that couldn’t connect four numbers living in four different files.
If your contracts, change orders, and contingencies live in spreadsheets your AP team can’t see, the question isn’t whether an overpayment is possible. It’s how big it gets before someone catches it — and whether they catch it before or after the money’s gone. That’s worth a conversation.
Frequently Asked Questions
How do real estate developers overpay on contracts?
Developers overpay when contract data and invoice data live in separate places. The contract value sits in a spreadsheet the AP team can’t see, change orders are approved informally and never added to that value, and contingency is drawn against without tracking what’s left. The AP clerk pays each invoice as it arrives, and because nothing connects the total paid to the contract value plus approved changes, the payments can quietly cross the contract amount without anyone noticing until it’s too late.
What is an AP-to-contract match?
An AP-to-contract match is a control that checks every incoming invoice against the contract before it can be approved — comparing it to the contract value, approved change orders, contingency draws, and the amount already paid to that vendor on that contract. If approving the invoice would push the total past the contract value plus approved changes, the system stops the workflow. This is what prevents an overpayment from being cut, rather than discovering it after the money is gone.
How do you track change orders to prevent overpayment?
Change orders prevent overpayments only when they’re tied to the contract value the AP team sees. That means every approved change order updates the contract’s authorized amount in the same system that approves invoices, so the AP-to-contract match reflects it automatically. When change orders are approved verbally or by email and live in a separate file, the AP team approves invoices against a contract value that’s already out of date — which is one of the most common ways overpayments happen.
What is contingency tracking in construction contracts?
Contingency tracking monitors draws against a contract’s contingency pool so the developer always knows how much remains. Overpayments occur when contingency draws are entered as ordinary invoices, paid without being charged against the pool, so the contingency appears available when it’s actually spent. Proper tracking treats a contingency draw differently from a standard invoice and reduces the remaining balance, keeping the contract’s true committed total accurate.
Can QuickBooks track construction contracts and change orders?
QuickBooks records vendor invoices and payments but has no native concept of a construction contract with a committed value, approved change orders, a contingency pool, and an AP-to-contract match. Developers using QuickBooks typically track contracts and change orders in separate spreadsheets, which the AP team doesn’t see when approving invoices. That gap — invoices approved without visibility into the committed contract total — is exactly where overpayments hide.
