Not-to-exceed overrun in IT and professional services

Executive Summary

A not-to-exceed clause caps what a vendor may bill against a statement of work. The overrun happens at the boundary between two documents that are approved by different people at different times: the SOW that sets the cap, and the timesheet or milestone invoice that draws against it. Nobody owns the running total in between.

AP matches the invoice to a purchase order, not to the cumulative spend against the SOW's ceiling, so the ceiling can be crossed for several billing cycles before anyone notices.

The mechanism is procedural, not fraudulent. A consultant logs hours honestly, a manager approves a timesheet honestly, and the sum of honest approvals still exceeds the cap because no single approval step checks the running total against the contract. Change orders that should reset the cap are sometimes issued after the fact to match spend already committed, which converts a control into a formality.

What changes it is moving the check from the invoice to the running total: a control that compares cumulative billed-to-date against the SOW ceiling before each payment, not after the engagement closes.

1. What is a not-to-exceed clause meant to control?

A not-to-exceed (NTE) clause sets a dollar ceiling on what a vendor may bill against a statement of work, regardless of hours logged or milestones reached. It exists because time-and-materials pricing has no natural stopping point: the vendor is paid for effort, not outcome, so the client sets the outcome's price boundary separately, in the contract, as a hard cap on cumulative billing.

An NTE cap is a single number attached to a scope of work, not to a time period and not to a line item. It sits on top of whatever rate card and hour estimate produced the SOW's original budget. The cap is meant to survive scope estimation being wrong in the vendor's favor.

The cap only functions if something tracks cumulative billing against it continuously. A rate card tells you whether a single hour is priced correctly. An NTE cap tells you whether the sum of all approved hours, across every invoice issued since the SOW started, has crossed a ceiling nobody re-checks at each payment.

That distinction matters because the two failures require different controls. A wrong rate is visible on one invoice. An NTE breach is only visible when someone adds up several invoices against the original number in the SOW, which is exactly the step that AP's normal matching process does not perform.

2. How does an NTE overrun actually happen?

The overrun happens because the SOW that sets the cap and the timesheet that draws against it are approved by different people, at different times, with no shared running total between them. Each individual timesheet looks reasonable to the manager who signs it. The cap is breached by the accumulation of reasonable approvals, not by any single invoice that looks wrong on its own.

Take a typical sequence: the SOW sets a fixed cap for a multi-month engagement. The first stretch of months runs on plan. Partway through, scope expands informally, a manager verbally agrees to additional hours to keep the project moving, and nobody issues a change order because the work is urgent and the paperwork can wait.

The timesheets that follow are each approved individually, each accurate to hours actually worked.

By the later months, cumulative billing has passed the cap. The invoice for that period looks like every invoice before it: correct rate, correct hours, manager's signature. Nothing on that single document signals a breach, because the breach is a property of the sum, not the invoice.

A change order eventually appears, often dated to match spend that already happened rather than to authorize spend in advance. At that point the NTE cap has stopped functioning as a control and become a record of what was already paid.

3. Where does AP's normal review miss this?

Three-way matching checks the invoice against the purchase order and the goods or services receipt. It confirms the rate is right and the hours were approved. It does not test cumulative billing against a separate contract ceiling, because the NTE cap lives in the SOW document, not in the PO line the AP system was built to match against.

AP systems match against a purchase order number and a rate. If the PO was issued for the full engagement value up front, the system may show remaining PO balance, but that balance depletes at the rate invoices are submitted, not at the rate the contract intended. It will not flag a breach caused by informal scope expansion that a change order hasn't yet caught up with.

If the PO was issued per phase or per invoice, there is no single document in the AP system that carries the SOW's original ceiling at all. The cap exists only in the contract file, which AP does not open at invoice time.

A. What the control has to compare

The check that catches an NTE overrun is arithmetic across documents: cumulative dollars billed to date on a given SOW, compared against the ceiling stated in that SOW, updated at every invoice rather than at contract renewal. That comparison has to run before payment, not as a year-end reconciliation, because by year-end the money is already gone.

4. Which contract terms make the overrun more likely?

Three SOW design choices widen the gap between the cap and what actually gets billed: a cap stated as a total with no phase-level sub-caps, a change-order process that permits verbal or after-the-fact authorization, and a time-and-materials rate structure with no milestone or deliverable tied to the cap. Each removes a point where someone would otherwise have to check the running total.

A single project-wide cap with no phase breakdown means nobody is forced to reconcile spend until the whole budget is gone. Splitting the cap into phase-level sub-ceilings, each requiring its own sign-off to cross, creates more checkpoints without changing the total authorized spend.

A change-order clause that allows retroactive documentation removes the clause's actual function. If a change order can be issued after the spend it describes, the cap stops constraining anything in real time; it only produces paperwork that matches whatever was already billed.

Time-and-materials pricing with no deliverable or milestone attached to the cap means the only variable being tracked is hours, and hours have no natural ceiling of their own. A cap tied to a deliverable at least gives the approver a second signal, beyond the running dollar total, that scope has moved beyond what was priced.

5. How do you build a control that catches this before payment?

The control is a running-total check: before approving any invoice against a time-and-materials SOW, compare cumulative billed-to-date, including the invoice in front of you, against the SOW's stated NTE ceiling. If the sum exceeds the cap, the invoice does not get paid on the existing PO until a change order raises the ceiling or the excess is rejected.

This requires the SOW's cap value to exist somewhere AP can see it at invoice time, not just in a contract repository procurement owns. A shared field, even a simple tracker outside the ERP, that carries SOW number, ceiling, and running total is enough if it is checked every cycle.

The check has to happen before the invoice is approved for payment, not during a periodic audit. A quarterly reconciliation catches the breach after the money has left, which converts the finding into a dispute with the vendor rather than a payment that was never made.

The same running-total logic extends to related risks: a vendor billing under a SOW that never had a matching change order for expanded scope is functionally the same failure as scope creep in professional services SOWs, and the underlying control, a live comparison between contracted ceiling and cumulative spend, addresses both.

6. How do you recover an overrun that already happened?

Recovery starts with reconstructing cumulative billing per SOW across its full life, not per invoice, because the breach is only visible in the sum. Compare that running total against the ceiling stated in the original SOW and any properly dated change orders, then treat any excess billed without a preceding, dated authorization as a candidate for credit or offset against future work.

The reconstruction takes every invoice tied to a given SOW, in date order, and builds a running total against the ceiling at the time each invoice was submitted. A change order issued after an invoice does not retroactively authorize that invoice; it only authorizes billing from its own effective date forward.

This produces a defensible position with the vendor because it separates work performed, which is not in dispute, from authorization to bill for it beyond the contracted ceiling, which is a distinct question. Vendors keep their own record of when a scope conversation happened and can confirm or contest the timeline.

General information, not legal advice: whether unauthorized amounts are recoverable as an overpayment or must be resolved as a contract dispute depends on the SOW's own terms and any course-of-dealing history with that vendor, and should be reviewed against the actual contract language before demanding a credit.

For the wider pattern this sits inside, start with the margin drift guide. See also accessorial charge audit: the surcharges nobody validates and rate card enforcement: why approved timesheets still produce wrong invoices.

For the wider pattern this sits inside, start with the margin drift guide. See also accessorial charge audit: the surcharges nobody validates and rate card enforcement: why approved timesheets still produce wrong invoices.

7. Frequently Asked Questions (People Also Ask)

Is a not-to-exceed overrun the same thing as overbilling?

No. Overbilling means the rate or hours on an invoice are wrong. An NTE overrun can happen with a correct rate and honestly logged hours; the failure is that the sum of correct invoices exceeds the ceiling the SOW set, not that any single invoice misstates work performed.

Who is responsible for catching an NTE breach: AP or procurement?

Neither owns it by default. AP matches invoices to purchase orders and receipts, not to a SOW's cumulative ceiling. Procurement typically owns the contract file but does not see invoices as they are approved. The gap exists because the check falls between the two functions unless someone explicitly assigns it.

Does a purchase order for the full contract value prevent this?

Not on its own. A full-value PO shows remaining balance, but that balance depletes as invoices are submitted, not as scope changes. It will not flag a breach caused by informal scope expansion until a change order updates the number, which is often after the spend already happened.

Can a change order fix an overrun after it happens?

A change order can authorize future billing from its effective date forward. It cannot retroactively authorize invoices already paid before it was issued. Treating a backdated change order as covering prior spend converts a control into paperwork rather than an actual authorization.

What should be tracked to catch this before payment instead of after?

Cumulative dollars billed to date against each SOW's stated ceiling, checked at every invoice, not at contract renewal or year-end. This can live in a simple shared tracker outside the ERP if the ERP itself does not carry the SOW's ceiling as a field.

Is an NTE overrun something we can dispute with the vendor?

It depends on the SOW's own terms and the history of how scope changes were handled with that vendor. This is general information, not legal advice; review the actual contract language before treating any excess as recoverable.

Does this apply to fixed-fee engagements too?

The mechanism described here is specific to time-and-materials billing against a ceiling, where hours have no natural stopping point. A fixed-fee engagement has a different failure mode: the risk there is scope reduction without a corresponding fee adjustment, not a cumulative billing breach.

How is an NTE overrun different from a rate card violation?

A rate card violation is visible on a single invoice: the billed rate does not match the contracted rate. An NTE overrun is only visible across multiple invoices, since it is a property of the running total against the SOW ceiling, not of any one invoice's rate or hours.