How ₹14 Lakh in Overpayments Hides Across 6 Months of Vendor Invoices
Vendor overpayments accumulate silently when invoice unit prices drift from contracted rates. Here's how the gap forms — and how to surface it before it compounds.
Verse HQ
Your vendor has been raising prices by 2.8% every quarter for two years. No single invoice triggered a review — each increase stayed within your 5% tolerance threshold. But compounded, you are now paying 23% more than your contracted rate. Across ₹2.4 crore in annual spend with this vendor, that is ₹55 lakh in overpayment that accumulated one quarter at a time. None of it was flagged. None of it was recovered.
Three Ways Vendor Overpayments Accumulate
Unit price drift is the most common and the hardest to detect through standard AP controls. An invoice is approved not because anyone checked the unit rate against the contract, but because the invoice total looks reasonable, the format is correct, and the vendor is familiar. If the contract specifies ₹380 per unit and the vendor invoices ₹420 per unit — as in the scenario above — the overpayment is invisible unless someone specifically compares the invoice rate to the contracted rate for that SKU or service.
Price drift often happens with no fraudulent intent. A vendor increases rates at renewal. The updated rate gets applied to new invoices. But nobody updated the contract in the AP system, so the old contracted rate is still the reference point — and nobody is checking against it.
Quantity overbilling shows up when the invoice quantity exceeds what the GRN recorded as received. The vendor delivers 180 units, the GRN is raised for 180, and the invoice bills for 200 at ₹450 each. The overpayment is ₹9,000 per invoice. If this vendor invoices monthly and the error persists for 12 months, that is ₹1.08 lakh recovered only if someone eventually reconciles the GRN against the invoice history.
Unenforced short-delivery penalties are the most overlooked category. Many procurement contracts include a clause: if delivered quantity falls below 95% of ordered quantity, a 2% penalty applies. In practice, this clause goes unenforced because no one in AP is reading contracts during invoice processing. The invoice arrives for the full PO value minus the delivered quantity, the GRN confirms partial receipt, and the payment goes out without anyone calculating the penalty owed.
Why Standard AP Controls Don't Catch This
The standard AP control set — duplicate check, PO match on totals, approvals — does not check unit rates against contract price schedules. The PO total and the invoice total might match even when individual line-item unit prices are wrong, if quantities have been adjusted to keep the total consistent.
A contract signed 18 months ago is rarely in the same system as the invoice being processed today. The contract is in a shared drive or a filing cabinet. The invoice is in an email inbox. The person processing the invoice knows what the PO says. They do not know what the contract says about rate schedules and penalty clauses.
What Surfacing Overpayments Requires
Detecting vendor overpayments requires checking the invoice against three things simultaneously: the PO (for the quantity-price relationship on this specific transaction), the GRN (for the quantity actually received), and the contract (for the agreed unit rate and any penalty clauses).
This is not a manual process that scales. A finance team doing this for 400 invoices per month would spend their entire working time on the comparison and still make errors. What scales is a system that holds the contract rate schedule and checks every invoice line item against it automatically.
The pattern is consistent: a small discrepancy, repeated across dozens of invoices, compounding quietly. The money does not disappear in one transaction — it leaks, one invoice at a time, until someone asks a question that nobody in the AP team has the data to answer: what are we actually paying per unit, and is that what we agreed to pay?
