How do you prevent not-to-exceed overrun?

Executive Summary

A not-to-exceed clause is a ceiling written into a contract, purchase order, or statement of work. It stops mattering the moment nobody checks the invoice against it. Three-way matching confirms an invoice against a purchase order and a receipt; it does not test whether a running total against a project has crossed the dollar figure written into a separate contract clause.

The fix is not more scrutiny from the AP team. It is a control that carries the cap forward from the contract into every invoice review, tracks it cumulatively across a project rather than line by line, and flags the invoice that would push the total over before it pays.

Where that control does not exist yet, a retrospective audit finds the overruns already paid and gives you the language to close the gap going forward.

1. What is a not-to-exceed overrun?

A not-to-exceed overrun is a billed amount that exceeds a dollar ceiling stated in a contract, purchase order, or statement of work for a defined scope of work or time period. The cap is meant to be a hard stop. An overrun means it was crossed and paid anyway, usually because whatever process approved the invoice compared it only against the line items on that invoice, never against the ceiling written elsewhere.

The clause itself is usually a single sentence: total charges for a scope of work will not exceed a stated dollar figure without written approval. It shows up most in contract labor, maintenance and repair work, and project-based IT and professional services, where the scope is defined once and billed over weeks or months.

The overrun is cumulative by nature. Any single invoice can look ordinary: a reasonable number of hours, a normal rate, a plausible material charge. The problem only appears when that invoice is added to every prior invoice against the same purchase order or statement of work and the running total crosses the ceiling.

That is also why it survives standard AP review. Nothing about the individual invoice looks wrong.

2. Why does three-way matching miss the cap?

Three-way matching checks that an invoice agrees with a purchase order and a receipt of goods or services. It confirms quantity and unit price line by line. It was never built to hold a running total against a separate contract clause, and most purchase orders are not written with the not-to-exceed figure encoded as an enforceable limit the matching system can check against.

The purchase order itself is often the weak link. A PO raised for a project frequently states an estimated amount rather than the actual not-to-exceed ceiling from the master contract, and the two numbers can diverge without anyone reconciling them.

Even where the PO does carry the correct figure, matching software checks each invoice in isolation against that PO's remaining balance, not against a contract clause that may span multiple purchase orders raised over a project's life.

The result: a control built to prevent price and quantity errors is asked to also prevent budget overruns, a different problem with a different data source.

3. Where does the cap actually get lost?

The cap gets lost at the handoff between the people who negotiate the contract and the people who approve invoices against it. Procurement or legal signs the statement of work with the ceiling in it. AP receives invoices with no visibility into that document. Nobody owns the job of translating a contract clause into a number a payment system checks.

This gap shows up in three distinct places across a project's life: at the document handoff, in day-to-day ownership of the invoice approval, and again whenever scope actually changes mid-project.

A. The document gap

The not-to-exceed figure lives in a PDF statement of work or contract amendment, not in the ERP. Unless someone manually enters it as a control, it has no mechanical presence in the invoice approval workflow at all.

B. The ownership gap

Procurement negotiates the cap and moves to the next contract. The project manager who requested the work approves invoices for reasonableness, not against a ceiling they may never have seen. AP pays what is coded and approved.

C. The change-order gap

Some overruns are legitimate: scope changed and a written change order raised the cap. The problem is invoices billed against the old ceiling continuing to post after scope changed, with no one confirming the change order was actually signed before payment continued.

4. How do you build a control that actually catches it?

Preventing a not-to-exceed overrun requires three things working together: the ceiling entered as a number in the system that approves invoices, a running total tracked cumulatively against that ceiling rather than checked line by line, and an approval gate that stops the invoice which would cross the cap rather than one that reviews it after payment.

None of these four steps requires new software if a controller is willing to maintain a tracking sheet by project. They do require someone assigned to own it, because a control nobody is accountable for degrades within a few invoice cycles.

1. Encode the ceiling: At contract signature, enter the not-to-exceed figure into the purchase order or a linked tracking field, not just the contract file.
2. Track cumulatively: Sum every invoice against that PO or statement of work as it posts, not just the current invoice against its own remaining balance.
3. Gate the crossing invoice: Route any invoice that would push the cumulative total over the cap to approval before payment, not after.
4. Reconcile change orders first: Require a signed change order to raise the tracked ceiling before any invoice above the old cap is approved, not after it has already posted.

5. What does a retrospective audit find that the control missed?

A retrospective audit reconstructs the cumulative total for every purchase order and statement of work against its stated ceiling, across the full period audited, and flags every project where paid invoices crossed the cap without a matching change order on file. It finds overruns already paid, distinguishes them from legitimate scope changes, and identifies which vendor relationships need the ceiling rebuilt.

The audit works backward from the contract file rather than forward from the invoice queue. Every statement of work and contract amendment is pulled, its not-to-exceed figure recorded, and every invoice coded to that project summed against it.

Where the total exceeds the cap, the next step is checking for a signed change order. If one exists and was simply never linked in the system, the finding is a process gap, not a recoverable amount. If none exists, the amount above the cap is a candidate for recovery or credit.

This is the same reconciliation work described more broadly in a contract labor and staffing audit and a maintenance and repair audit, since not-to-exceed clauses concentrate heavily in both categories.

6. Can this be prevented without new software?

Yes. A not-to-exceed control is fundamentally a tracking discipline, not a technology requirement. A shared tracking sheet that lists every active not-to-exceed ceiling, updates with each invoice posted against it, and is checked before approval closes most of the gap.

The harder requirement is not the tool. It is assigning ownership so the sheet stays current after the person who built it moves to another project.

Where this breaks down in practice is maintenance, not setup. The tracking sheet gets built accurately for the first quarter of a project and stops being updated once the person who owns it changes roles or the project extends past its expected end date.

A system-based control removes the maintenance dependency, because the cumulative total updates automatically as invoices post. That is the case for moving from a spreadsheet to an enforced control, and it is also the case for treating this category differently from one-time reviews: a not-to-exceed cap needs continuous enforcement for the life of the contract, not a single check at signature.

Worked example, using the 1% to 3% band: take a project's total not-to-exceed ceiling, subtract every invoice posted to date, and that remainder is the exposure still open to an uncontrolled overrun. Recomputing that remainder after every invoice, rather than at project close, is what a working control does differently.

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

7. Frequently Asked Questions (People Also Ask)

What is a not-to-exceed clause in a vendor contract?

A not-to-exceed clause sets a maximum dollar amount a vendor can bill for a defined scope of work or time period without separate written approval. It functions as a budget ceiling built into the contract itself, distinct from unit pricing or rate terms covered elsewhere in the agreement.

Why do not-to-exceed overruns happen if the cap is in writing?

The cap being in writing does not mean it is checked at invoice time. Three-way matching validates an invoice against a purchase order and receipt, not against a cumulative total across every invoice billed to date on a statement of work, so the crossing invoice looks ordinary in isolation.

Is a not-to-exceed overrun always a vendor error?

No. Some overruns are legitimate once scope changes and a change order raises the cap. The problem this page addresses is invoices continuing to post above the original ceiling with no signed change order on file, which is a control gap rather than a vendor mistake.

How is a not-to-exceed overrun different from a minimum commitment shortfall?

A not-to-exceed overrun is billing above a ceiling. A minimum commitment shortfall is the opposite condition: paying a penalty or true-up because actual volume or spend fell below a floor the contract required. Both are drift types tracked separately.

Can AP catch this during normal invoice approval?

Standard AP review checks an invoice against its purchase order and receipt. It does not carry forward a contract's not-to-exceed figure or sum prior invoices against it, so catching an overrun during normal approval requires a control built specifically for that cumulative check.

Which vendor categories carry the most not-to-exceed clauses?

Contract labor and staffing engagements and maintenance and repair projects commonly use not-to-exceed ceilings because both bill incrementally against a defined scope. IT and professional services statements of work carry them as well.

What should I ask a vendor if I suspect an overrun already happened?

Ask for a cumulative billing statement against the specific purchase order or statement of work, compared line by line to the contract's stated not-to-exceed figure, and request the signed change order for any period where billing exceeds that figure.

Does a not-to-exceed overrun count as recoverable leakage?

It can, if the amount billed above the cap has no corresponding signed change order. Whether it is recoverable or simply a process gap to fix going forward depends on documentation, which is the split covered on the recoverable versus preventable leakage page.

Is this something legal or contract language can fix on its own?

Contract language sets the ceiling; it does not enforce it. Enforcement requires the ceiling to be tracked cumulatively against invoices as they post. This is general information, not legal advice, and any contract remedy should be reviewed with counsel.