How do you quantify losses from NTE overrun?

Executive Summary

A not-to-exceed clause caps what a vendor may bill for a defined scope of work, but the cap only protects margin if someone checks each invoice against it. When AP pays against a purchase order or a prior invoice amount instead of the contract ceiling, an invoice can clear the cap for months before anyone notices. The loss is not the overrun on one invoice; it is the overrun compounded across every invoice paid the same way since the cap was first breached.

Quantifying it means rebuilding a timeline, not reading a single bill. You need the contract's stated ceiling, the scope it applies to, and every invoice billed against that scope since the engagement started. The overrun on each invoice is the billed amount minus the ceiling, and the total loss is the sum of those overruns, not an average or an estimate carried forward.

The mechanism that lets this go unnoticed is procedural, not a fraud problem: three-way matching checks quantity and price against a purchase order and a receipt, and a purchase order rarely encodes a not-to-exceed condition at all. Once you have the total, the fix is a control that flags the next invoice against the same ceiling before it pays, not just a recovery of what already went out the door.

1. What does a not-to-exceed clause actually cap?

A not-to-exceed clause sets a maximum dollar amount a vendor may bill for a defined scope of work over a defined period: a project, a maintenance term, a staffing engagement. It does not cap a rate or a unit price on its own; it caps the total. An invoice can carry an approved rate and still breach the clause if cumulative billing against that scope passes the ceiling.

The clause is only meaningful if the scope it covers is written.

The scope definition matters more than the number itself. A ceiling written against "IT services for Q3" is nearly impossible to test because almost any invoice from that vendor can be argued to fit. A ceiling written against a named project, statement of work, or purchase order number can be tested invoice by invoice.

Some contracts set one ceiling per invoice and a separate aggregate ceiling for the full term. Both need to be tracked, because a vendor can stay under the per-invoice cap every month and still clear the aggregate cap by the eighth invoice.

2. How do you calculate the overrun on a single invoice?

The overrun on one invoice is the amount billed against the covered scope minus the contract ceiling for that same scope and period, with any negative result treated as zero. This requires isolating the line items that actually apply to the capped scope, since a single invoice can mix capped work with change orders or out-of-scope items billed separately. Skipping that isolation step is the most common source of an overstated or understated figure.

Start by pulling every line item on the invoice and matching each to the contract's scope description. Line items outside the described scope, such as an approved change order billed under its own rate, do not count toward the ceiling and should be excluded before you subtract.

Once the in-scope total is isolated, the calculation is simple: in-scope billed amount minus the ceiling. If the contract states the ceiling net of tax or freight, apply the same basis to the invoice total, or the subtraction compares two different things.

3. How do you total the loss across multiple invoices?

Sum the per-invoice overrun across every invoice billed against the same scope since the ceiling took effect, not since the discrepancy was first noticed. A single vendor relationship often spans a dozen or more invoices under one statement of work, and a control gap that missed the first overrun typically keeps missing every one after it until someone rebuilds the full sequence. The total loss is that full sum, and a partial count understates it.

Build a simple ledger: invoice date, invoice number, in-scope billed amount, ceiling in effect, overrun. List every invoice against the scope in date order, even ones that came in under the ceiling, so the pattern of when the breach started is visible.

Watch for a ceiling that changed mid-term through an amendment. If the contract was amended to raise the ceiling on a given date, invoices before that date are tested against the old number and invoices after against the new one. Applying the wrong ceiling to the wrong period is a common way this total goes wrong.

4. Why does three-way matching miss this?

Three-way matching checks that the invoice quantity and price agree with the purchase order and the goods receipt. A not-to-exceed condition is a contract term, not a purchase order field, so the match has nothing to compare it against. An invoice can match its purchase order line perfectly and still breach the ceiling set in the underlying contract, because the two documents are tracking different things.

A purchase order typically states a quantity and a unit rate. A not-to-exceed clause states a cumulative dollar ceiling across a scope and period. Unless someone has manually encoded the ceiling as a purchase order limit, and kept it updated through every amendment, the systems have no shared field to check.

This is a description of what the control does, not an assessment of how often it fails. The gap exists by design: the purchase order system and the contract repository are built to answer different questions, and neither is built to answer this one on its own.

A. What matching does check

Three-way matching confirms the invoiced quantity does not exceed what was ordered and received, and the invoiced unit price matches the purchase order price. This catches a vendor billing for units never delivered or applying an unapproved rate.

B. What matching does not check

It does not test a cumulative dollar ceiling across multiple invoices, because a purchase order is usually issued per transaction or per period, not as a running total against a contract term. The ceiling lives in the contract document, outside the fields the match compares.

5. What documents do you need before you start the calculation?

You need the signed contract or statement of work stating the ceiling and the scope it covers, every amendment that changed either one, and every invoice issued against that scope for the full term to date. Missing even one invoice in the sequence breaks the running total, and missing an amendment means testing invoices against a ceiling that no longer applied on the date they were billed.

Start with the contract repository, not the AP system, since the ceiling and scope definitions live there. Cross-check the scope description against how the vendor actually itemizes invoices, because vendors do not always use the contract's own language on their bills.

Where the contract folder is incomplete, the invoice sequence itself can help reconstruct the scope: a run of invoices citing the same statement of work number is good evidence of what the ceiling was meant to cover, even absent the original document.

1. Signed contract or SOW: States the ceiling amount, the scope it covers, and the period it runs over.
2. All amendments: Any change to the ceiling, the scope, or the term dates, in date order.
3. Full invoice history: Every invoice billed against the scope since the contract's start date, not just the ones flagged as unusual.
4. Purchase order records: Useful for cross-checking quantities, but not a substitute for the contract's own ceiling language.

6. How does this fit into a wider margin drift finding?

A not-to-exceed overrun is one of several distinct ways a vendor invoice can drift from its contract, alongside a rebate gap, a volume tier misapplication, or a duplicate payment. Each has its own mechanism and its own calculation method, and a full accounting of leakage against a vendor relationship checks each one separately rather than assuming one drift type accounts for the whole gap between spend and contract terms.

An invoice that clears a not-to-exceed ceiling can, on the same statement of work, also carry a rate that no longer matches an index escalation clause, or a rebate the vendor owes but never issued as a credit. Treating the ceiling breach as the only issue on that vendor relationship risks closing the file early.

This is also where the split between recoverable and preventable leakage matters: a past overrun already paid is a recovery question, while the control that let it recur is a prevention question, and the two need different owners inside finance.

7. How do you stop the overrun from recurring on the next invoice?

Stopping recurrence means checking the cumulative billed total against the contract ceiling before an invoice is approved, not after payment when the only option left is recovery. This requires someone or some system to hold the ceiling and the running total in one place, update it as each invoice posts, and flag the next invoice once it would cross the line, rather than relying on a purchase order match that was never built to test this condition.

The check itself is not complicated once the ceiling and scope are correctly identified: running total plus new invoice amount, compared against the ceiling, before the invoice is coded for payment. The difficulty is operational, keeping that running total current as invoices arrive from different vendors on different schedules against dozens of active statements of work.

A contract compliance audit builds this running total once, as part of establishing the true state of every capped engagement, which is also the point at which the historical overrun gets quantified using the method above.

For the wider pattern this sits inside, start with the margin drift guide.

8. Frequently Asked Questions (People Also Ask)

What counts as an in-scope invoice for a not-to-exceed calculation?

Any invoice, or line item within an invoice, billed against the specific project, statement of work, or purchase order that the contract's ceiling was written to cover. Change orders or work billed under a separate rate structure are excluded unless the contract explicitly folds them into the same ceiling.

Does a not-to-exceed ceiling reset each invoice or accumulate?

It depends on how the contract is written. Some ceilings apply per invoice, some apply as a running total across the full term, and some contracts state both a per-invoice and an aggregate ceiling. Read the clause itself; do not assume which one applies.

What if the contract amendment history is incomplete?

Reconstruct what you can from the invoice sequence and any correspondence referencing a change in scope or ceiling. State clearly in the finding which periods rest on a confirmed amendment and which rest on inferred scope, so the total is not overstated with false confidence.

Can a vendor dispute an overrun calculated this way?

Yes, and the most common dispute is over scope, whether a given line item was truly covered by the capped statement of work or billed under a separate agreement. Keep the scope match documented line by line so the dispute can be resolved against the contract text rather than argued from memory.

Is a not-to-exceed overrun the same as a rate overcharge?

No. A rate overcharge means the vendor billed an unapproved unit price, which a purchase order match can often catch. A not-to-exceed overrun can occur even at the correct approved rate, once cumulative billing against a capped scope exceeds the ceiling; the rate was never the problem.

Who inside finance should own fixing this going forward?

The overrun already paid is typically a recovery question for AP or the controller. The running-total check that prevents recurrence is a contract compliance function, since it requires reading the contract terms alongside the invoice stream rather than the invoice alone.

Does three-way matching catch a not-to-exceed overrun?

Three-way matching checks invoice quantity and price against the purchase order and goods receipt. It has no field for a cumulative contract ceiling, so an invoice can pass the match cleanly and still breach the ceiling stated in the underlying contract.

How far back should the invoice review go?

Back to the start date of the contract or statement of work that established the ceiling, not just to when the overrun was first suspected. A partial review understates the total because it misses earlier invoices that may already have breached the same cap.