How to spot NTE overrun on IT services bills

Executive Summary

A not-to-exceed overrun happens when billed fees on a statement of work exceed the dollar ceiling the contract sets, and the invoice still gets paid. The mechanism is straightforward: an AP workflow matches an invoice to a purchase order and a receipt. It does not match the invoice to the NTE figure written into a separate SOW document.

If the PO was cut for a round number and the SOW cap is lower, or a change order raised the PO without raising the underlying cap, the overrun is invisible at the point of payment.

The fix is not closer reading at invoice time. It is a control that reads the SOW cap into a tracking record before the first invoice lands, accumulates billed amounts against it line by line, and flags the invoice that would cross the ceiling before it is approved. Without that record, the cap exists only in the contract file.

This page covers how the overrun forms, what a working check looks like, and where it differs from a labor rate problem or a scope problem that can appear on the same invoice.

1. What counts as a not-to-exceed overrun?

A not-to-exceed overrun is cumulative billing on a statement of work that exceeds the dollar ceiling the SOW states, whether the ceiling is crossed on one invoice or gradually across several. It applies to the total fee for a defined phase or deliverable, not to an individual line item or hourly rate. A vendor billing under its approved rate can still overrun the cap if enough hours are logged against a fixed-fee phase.

The cap sits in the SOW, not the PO. A purchase order often gets cut for an estimate or a round number at project kickoff, and that PO number is what most three-way matching checks against. The SOW's NTE figure is a separate constraint layered on top of it.

An overrun can happen in one invoice, when a single billing period reports more fees than the remaining balance under the cap allows. It can also happen gradually, where each individual invoice looks reasonable and only the running total, checked against the SOW, shows the ceiling has been passed.

The distinction matters because a system that only checks each invoice in isolation, never the cumulative total, will approve every invoice in a gradual overrun without ever flagging one.

2. Why does three-way matching miss this?

Three-way matching checks the invoice against the purchase order and the goods or services receipt. It confirms the vendor billed what was ordered and received. It does not read the SOW's dollar ceiling, because that ceiling usually lives in a PDF or a signed document outside the ERP, not in a field the matching engine can query.

A PO number and an NTE cap answer different questions. The PO says a vendor is authorized to bill up to a certain amount for a certain scope. The NTE cap, buried in the SOW's terms, says the total fee for a phase or deliverable cannot exceed a separate figure regardless of how the PO was structured.

When the two numbers match, the gap never surfaces. When they diverge, because the PO was set generously or a change order expanded it without updating the underlying cap, the matching engine has nothing to compare against. It approves the invoice because the invoice matches the PO, not because it matches the contract.

Catching the overrun requires a separate record: the SOW's cap, entered once, tracked against every invoice billed to that engagement over its life.

3. How do you track cumulative billing against a cap?

Tracking cumulative billing means recording the SOW's NTE figure at engagement setup, logging every invoice paid against that SOW as it arrives, and running a subtraction before each new invoice is approved: cap minus amount already billed. If the new invoice would push the running total past zero remaining, it is flagged before payment rather than caught afterward.

The mechanism has two moving parts, and both need to exist before the check works at all.

A. Setup at contract signing

The NTE figure and the phase or deliverable it covers need to be entered into a tracking record the moment the SOW is signed, before the first invoice arrives. If this step is skipped, there is nothing later invoices can be checked against, and the cap becomes a clause nobody consults again until a dispute forces someone to reread the contract.

B. Running balance at each invoice

Each approved invoice reduces the remaining balance under the cap. The check that matters is not whether one invoice looks reasonable on its own, but whether the sum of everything paid to date under that SOW, plus this invoice, still fits inside the ceiling. That running subtraction is the entire mechanism.

4. What does a change order do to the cap?

A change order can legitimately raise a not-to-exceed cap when scope genuinely expands, but the new figure has to be written down and the tracking record updated at the same time the PO is revised. When only the PO is revised and the cap is not, later invoices get checked against the wrong ceiling, and an overrun against the true contract terms can clear as approved.

Change orders are a normal part of professional services engagements. Scope shifts, a phase runs longer than estimated, and the vendor and buyer agree to a higher ceiling in writing.

The risk is procedural, not contractual. A procurement team revises the PO to reflect the new authorized amount, because that is the number the ERP enforces at the point of payment. If the SOW addendum recording the new cap is signed separately and never makes it into the same tracking record, the PO and the true cap can drift apart again, just in the other direction this time.

Every change order needs to update one place: the record that tracks cumulative billing against the current cap, sourced from the latest signed document, not from whichever number was last typed into the purchase order.

5. How is this different from a labor rate problem?

A labor rate deviation is a per-hour price charged above the rate card. An NTE overrun is a total-fee ceiling exceeded regardless of the rate charged per hour. A vendor can bill exactly its approved rate card and still overrun the cap simply by logging more hours than the fixed-fee budget allows, which is why the two require separate checks.

Rate deviations and NTE overruns often get treated as the same problem because they surface on the same invoice, from the same vendor, in the same review cycle. They are not the same mechanism.

A rate check compares the hourly or daily figure on the invoice to the rate card in the master agreement. It catches a vendor billing above its contracted rate. It does not catch a vendor billing at the correct rate for far more hours than a fixed-fee phase was scoped to cover.

An NTE check compares a running total to a ceiling. It catches the overrun regardless of whether the rate itself was correct. A full invoice audit for this category runs both checks separately, because a vendor can pass one and fail the other on the same document. For the rate side of this, see labor rate deviations against master service agreements.

6. Should the check use a fixed cap or a percentage buffer?

Some contracts specify the NTE as a hard dollar figure with zero tolerance; others build in an approval threshold, such as requiring sign-off once billing reaches a stated percentage of the cap. Either structure works as a control input, as long as the number, whichever form it takes, is entered into the tracking record at signing and checked against every invoice, not just the final one.

A hard cap is the simplest to track: one number, one running balance, one flag when the balance would go negative. Some SOWs build in an early-warning threshold instead, requiring notice or sign-off once cumulative billing reaches a stated share of the total cap, well before the ceiling itself is reached.

Either form works as an input to the same tracking mechanism. What breaks the control is not which form the contract uses, but treating the threshold as advisory and only checking the final total once the engagement has already closed out, by which point the invoices have already been paid.

For the wider pattern this sits inside, start with the margin drift guide. See also the six categories drift hides in and accessorial charge audit: the surcharges nobody validates.

7. Frequently Asked Questions (People Also Ask)

What is a not-to-exceed clause in an IT services contract?

A not-to-exceed clause sets a dollar ceiling on what a vendor can bill for a phase, deliverable, or the whole engagement, regardless of hours actually worked. It caps the buyer's total exposure for that scope of work, distinct from the hourly or daily rate charged.

Can a vendor bill above the NTE cap if they got verbal approval?

A verbal approval does not change the contract. If the cap needs to move, it should be documented as a formal change order or SOW addendum, with the new figure entered into the tracking record used to check future invoices, not left as an undocumented exception.

Does a purchase order amount equal the NTE cap?

Not necessarily. A PO is often cut at project kickoff for an estimate, while the NTE cap lives in the SOW itself. The two numbers can diverge if the PO was set generously or revised by a change order that did not also update the SOW's stated ceiling.

How far into a project does an NTE overrun usually show up?

It can appear on a single invoice if one billing period alone exceeds the remaining balance, or build gradually across several invoices that each look reasonable in isolation. Only a running total checked against the cap catches the gradual version before the engagement closes out.

Is an NTE overrun the same issue as a rate card violation?

No. A rate card violation is a per-hour or per-day price above the contracted rate. An NTE overrun is a total-fee ceiling exceeded even at the correct rate, simply because more hours were logged than the fixed-fee budget allows. They require separate checks on the same invoice.

Who is responsible for tracking the NTE cap, procurement or AP?

The cap needs to be entered into a tracking record at contract signing, which is typically a procurement or contract management function, and then checked against every invoice as it arrives, which is an AP function. The overrun gets missed when neither team owns the handoff between the two steps.

Does a change order automatically raise the NTE cap?

Only if the addendum recording the new cap is signed and entered into the same tracking record used to check invoices. Revising the purchase order alone, without updating the underlying SOW cap on record, leaves the true contractual ceiling unchanged even though the ERP shows a higher authorized amount.

What documents does ValueXPA's diagnostic check for an NTE overrun?

The diagnostic matches signed SOWs and any change order addenda against the full billing history for that engagement, line by line, to identify where cumulative billed fees crossed the stated cap and by how much.