# How Do You Detect Not-to-Exceed Overrun?

> Detection methods for not-to-exceed overrun on service vendor invoices, from clause language to audit steps CFOs can run today. Read the full guide.

Source: https://valuexpa.com/insights/how-do-you-detect-not-to-exceed-overrun
Publisher: ValueXPA (https://valuexpa.com)
Updated: 2026-09-07

---

Margin drift is the gap between what a vendor contract says and what the invoice actually charges. A not-to-exceed overrun is one specific shape that drift takes: a project, work order, or labor engagement carries a stated ceiling, and the cumulative billing quietly runs past it while each individual invoice still looks payable on its own.

Detecting it is a tracking problem more than a review problem. The cap lives in the contract; the overrun lives in the sum of invoices paid over time. Catching it means connecting those two records deliberately, because nothing in a standard AP workflow does it automatically.

## Executive Summary

A not-to-exceed overrun happens when a vendor bills past a contractual cap and the invoice still gets paid because nothing in the payment workflow checks the cumulative total against that cap. Three-way matching confirms an invoice against a purchase order and a receipt. It does not sum every invoice issued against a project or a labor rate against the NTE clause that governs them, so the overrun accumulates one payment at a time, invisible in any single transaction.

Detecting it requires reading the contract for the actual cap language, tracking cumulative billed amounts against that cap across every invoice tied to the same purchase order or statement of work, and flagging the invoice that crosses the line rather than the one that looks unusual on its own.

What changes this is a control that runs at the cumulative level, not the line level: a running total per contract or PO, checked against the stated ceiling every time a new invoice arrives, with the comparison happening before payment rather than during a periodic reconciliation months later. Where that control does not exist, the diagnostic reconstructs it retrospectively across 12 to 18 months of historical spend and quantifies what already went out the door.

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

**A not-to-exceed overrun occurs when the cumulative amount billed against a purchase order, statement of work, or labor engagement exceeds the ceiling written into the governing contract or PO, regardless of whether any single invoice looks reasonable on its own. The cap can be stated as a dollar total, a labor-hour limit converted to dollars, or a per-phase ceiling on a multi-phase project. The overrun is the total crossing the line, not any one invoice being wrong in isolation.**

The NTE clause is usually written into the purchase order, the statement of work, or a master services agreement referenced by both. It sets a dollar ceiling the vendor is not authorized to bill past without a change order or written approval. Some contracts phrase it as an hourly cap converted to dollars at a stated bill rate; others set it per project phase rather than for the whole engagement.

The overrun itself is arithmetic: sum every invoice paid against that PO or SOW, compare the running total to the ceiling, and identify the point where the sum exceeds it. A single invoice that looks entirely ordinary, correct hours, correct rate, correct line items, can still be the one that pushes the total over the cap. That is why reviewing invoices one at a time misses it: the defect is in the total, not in the document.

## 2. Why does three-way matching not catch this?

**Three-way matching checks that an invoice agrees with its purchase order and its receipt: same vendor, same items, same quantities, same price. It does not sum invoices across time against a separate ceiling figure, because the NTE cap usually lives in contract text rather than in a PO line item the matching engine reads. The control was built to catch billing errors on a single invoice, not accumulation across a series of them.**

Three-way matching is a point-in-time check. It confirms that what was ordered, received, and billed line up for the transaction in front of it. That is a real control, and it catches real errors: wrong quantity, wrong unit price, an item that was billed but never delivered.

What it does not do is hold a running total in memory across every invoice tied to the same PO and test that total against a ceiling defined elsewhere. If the NTE cap is written into contract language rather than entered as a field the ERP tracks, there is no place in the matching logic for the comparison to happen. Each invoice passes its own check while the aggregate quietly climbs past the number the contract actually allows.

## 3. How do you build a cumulative tracking control for NTE caps?

**Extract the NTE ceiling from every contract and purchase order into a single reference table, keyed to the PO or SOW number. Maintain a running total of invoices paid against each key. Compare the new cumulative total to the ceiling every time an invoice is received, before payment, and flag anything that would cross the cap. This turns a clause buried in contract text into a number the payment workflow can actually check.**

A control like this only works once the ceiling exists somewhere a system can read it, rather than sitting unread in a contract file. Everything downstream depends on that table being complete and current, including any amendments that changed the original cap.

### A. Building the reference table

Every PO or SOW carrying an NTE clause needs its ceiling recorded in one place, not left in the contract PDF where AP never opens it. Include the cap amount, whether it applies to the whole engagement or per phase, and the approval path required to raise it. This table is the thing three-way matching lacks: a place for the ceiling to live where a system can check against it.

### B. Running the comparison before payment

Each new invoice against a tracked PO adds to that PO's running total. The check that matters happens before the invoice is approved for payment: does the new total exceed the ceiling in the reference table? If yes, the invoice holds for review rather than being paid and reconciled later, when the vendor has already been paid past the cap and recovery becomes a negotiation instead of a routine hold.

## 4. Can you detect an overrun that already happened?

**Yes. A retrospective review pulls every invoice tied to a given PO or SOW over the contract period, sums them, and compares the total to the ceiling stated in the governing document. This is exactly the reconstruction a margin drift review performs across historical spend when no cumulative control existed at the time. The finding is the amount paid beyond the cap, which can be recoverable if the vendor billed past an enforceable ceiling without an approved change order.**

Retrospective detection does not need a real-time system. It needs the contract file, the PO history, and the full invoice record for the engagement, matched up by PO or SOW number rather than by invoice date. Once every invoice is attributed to its governing contract, the arithmetic is the same as the forward-looking control: sum, compare, flag.

The harder part is usually not the math. It is locating the governing NTE language in the first place, since it can sit in a master agreement, an amendment, or a change order that was never linked back to the PO in the ERP. A review of service vendor spend against contract terms is built around solving that linkage problem across a full vendor file rather than one engagement at a time.

## 5. Does an approved change order ever make an overrun legitimate?

**Yes. A written, approved change order that raises the ceiling makes the higher total legitimate, and it is not an overrun. The distinction that matters is whether the increase was authorized before or after the vendor billed past the original cap. An overrun discovered after the fact with no matching change order in the file is the finding; an overrun with a signed authorization on record is a contract amendment, not drift.**

This is where detection has to be more than a math check. Before flagging a crossed cap as recoverable, confirm whether a change order exists that raised the ceiling, and whether it was signed before the invoices that relied on it were issued. A change order signed after the fact to paper over an overrun already billed is a different situation: it may still represent a legitimate business decision, but it is worth flagging separately from an overrun with no authorization at all.

Treating every crossed cap as an automatic finding without checking for authorization produces false positives that undermine the credibility of the review. The clean version of this control checks both conditions: was the cap exceeded, and if so, was there a signed authorization on record before it was.

## 6. Which service categories carry the most NTE exposure?

**Not-to-exceed clauses appear wherever billing is time-and-materials rather than fixed-fee: contract labor and staffing engagements, IT and professional services projects, and maintenance and repair work billed by the hour. Each of these categories structures its NTE cap differently, so tracking cumulative totals against the right ceiling requires knowing which format the specific contract uses rather than applying one template across every vendor.**

The mechanics of the ceiling change by category, so a single detection template rarely fits all of them without adjustment for how each contract states its cap.

- **Contract labor and staffing:** Caps are typically an hourly rate times an approved hour count, and [shift or overtime premiums](/glossary/shift-and-overtime-premium-misuse) can push the total past the cap faster than straight time would.

- **IT and professional services:** Project-based NTE caps often apply per phase, so a total that looks fine against the whole engagement can already be over on an individual phase.

- **Maintenance and repair:** Time-and-materials work orders frequently carry an NTE tied to the specific job, separate from any annual service agreement covering the same vendor.

For the wider pattern this sits inside, start with the [margin drift](/insights/margin-drift-spend-leakage-guide) guide. See also [the six categories drift hides in](/guides/indirect-spend-audit-categories) and [what is margin erosion? causes and prevention for manufacturers](/guides/what-is-margin-erosion-causes-and-prevention-for).

## 7. Frequently Asked Questions (People Also Ask)

### What is a not-to-exceed clause?

It is contract or purchase order language that sets a ceiling on total billing for a project, phase, or labor engagement. The vendor is not authorized to bill past that ceiling without a signed change order raising it. The clause can state the cap as a dollar total, an hour count converted to dollars, or a per-phase limit.

### Why does my ERP not flag an NTE overrun automatically?

Most ERPs match an invoice against its purchase order and receipt, not against a cumulative total tracked over the life of a contract. If the NTE ceiling was never entered as a trackable field, there is nothing in the system for a new invoice to be compared against, so the overrun accumulates unnoticed.

### Is every crossed NTE cap a billing error?

No. A written, approved change order signed before the additional work was billed makes a higher total legitimate. The overrun worth investigating is one with no matching authorization in the file, or one where the change order was signed after the vendor had already billed past the original cap.

### Can an NTE overrun be recovered after the invoices are already paid?

Yes, if the overrun is confirmed against contract language and no valid change order authorized it. Recovery at that point is a claim against the vendor for amounts billed outside the contract's authorized ceiling, and the strength of the claim depends on how clearly the original cap was documented.

### How far back should I check for NTE overruns?

A margin drift diagnostic typically reviews 12 to 18 months of historical spend across service vendor categories, since that window covers most active contracts and purchase orders without requiring records outside normal retention periods.

### Does a per-phase NTE cap change how detection works?

Yes. Tracking has to sum invoices within each phase separately rather than against the whole engagement, since a total that looks fine overall can already have crossed the ceiling on one phase while other phases are under budget.

### What documents do I need to check for an NTE overrun?

The governing contract or statement of work with the NTE clause, the purchase order it is tied to, every invoice issued against that PO or SOW, and any change orders that might have raised the original ceiling.

### Who should own the cumulative tracking control?

AP typically owns the payment workflow where the check would run, but the reference table of contract ceilings usually has to come from procurement or the contract owner, since that is where the original NTE language and any amendments are kept.

### Is an NTE overrun the same as billed scope beyond contract?

They are related but distinct. An NTE overrun is a cumulative dollar total exceeding a stated ceiling. Billed scope beyond contract is work performed or items billed that fall outside what the contract authorized at all, regardless of the dollar total.

### Is contract complexity quietly draining your operating margin?

A small systematic drift between your negotiated contracts and your actual vendor billing compounds quietly across a year of invoices. Stop guessing at your exposure and run a targeted audit.

**[Take the Free Screener → https://valuexpa.com/margin-drift-screener](https://valuexpa.com/margin-drift-screener)**

## Executive Summary

A not-to-exceed overrun happens when a vendor bills past a contractual cap and the invoice still gets paid because nothing in the payment workflow checks the cumulative total against that cap. Three-way matching confirms an invoice against a purchase order and a receipt. It does not sum every invoice issued against a project or a labor rate against the NTE clause that governs them, so the overrun accumulates one payment at a time, invisible in any single transaction. Detecting it requires reading the contract for the actual cap language, tracking cumulative billed amounts against that cap across every invoice tied to the same purchase order or statement of work, and flagging the invoice that crosses the line rather than the one that looks unusual on its own. What changes this is a control that runs at the cumulative level, not the line level: a running total per contract or PO, checked against the stated ceiling every time a new invoice arrives, with the comparison happening before payment rather than during a periodic reconciliation months later. Where that control does not exist, the diagnostic reconstructs it retrospectively across 12 to 18 months of historical spend and quantifies what already went out the door.

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

A not-to-exceed overrun occurs when the cumulative amount billed against a purchase order, statement of work, or labor engagement exceeds the ceiling written into the governing contract or PO, regardless of whether any single invoice looks reasonable on its own. The cap can be stated as a dollar total, a labor-hour limit converted to dollars, or a per-phase ceiling on a multi-phase project. The overrun is the total crossing the line, not any one invoice being wrong in isolation. The NTE clause is usually written into the purchase order, the statement of work, or a master services agreement referenced by both. It sets a dollar ceiling the vendor is not authorized to bill past without a change order or written approval. Some contracts phrase it as an hourly cap converted to dollars at a stated bill rate; others set it per project phase rather than for the whole engagement. The overrun itself is arithmetic: sum every invoice paid against that PO or SOW, compare the running total to the ceiling, and identify the point where the sum exceeds it. A single invoice that looks entirely ordinary, correct hours, correct rate, correct line items, can still be the one that pushes the total over the cap. That is why reviewing invoices one at a time misses it: the defect is in the total, not in the document.

## 2. Why does three-way matching not catch this?

Three-way matching checks that an invoice agrees with its purchase order and its receipt: same vendor, same items, same quantities, same price. It does not sum invoices across time against a separate ceiling figure, because the NTE cap usually lives in contract text rather than in a PO line item the matching engine reads. The control was built to catch billing errors on a single invoice, not accumulation across a series of them. Three-way matching is a point-in-time check. It confirms that what was ordered, received, and billed line up for the transaction in front of it. That is a real control, and it catches real errors: wrong quantity, wrong unit price, an item that was billed but never delivered. What it does not do is hold a running total in memory across every invoice tied to the same PO and test that total against a ceiling defined elsewhere. If the NTE cap is written into contract language rather than entered as a field the ERP tracks, there is no place in the matching logic for the comparison to happen. Each invoice passes its own check while the aggregate quietly climbs past the number the contract actually allows.

## 3. How do you build a cumulative tracking control for NTE caps?

Extract the NTE ceiling from every contract and purchase order into a single reference table, keyed to the PO or SOW number. Maintain a running total of invoices paid against each key. Compare the new cumulative total to the ceiling every time an invoice is received, before payment, and flag anything that would cross the cap. This turns a clause buried in contract text into a number the payment workflow can actually check. A control like this only works once the ceiling exists somewhere a system can read it, rather than sitting unread in a contract file. Everything downstream depends on that table being complete and current, including any amendments that changed the original cap. ### A. Building the reference table Every PO or SOW carrying an NTE clause needs its ceiling recorded in one place, not left in the contract PDF where AP never opens it. Include the cap amount, whether it applies to the whole engagement or per phase, and the approval path required to raise it. This table is the thing three-way matching lacks: a place for the ceiling to live where a system can check against it. ### B. Running the comparison before payment Each new invoice against a tracked PO adds to that PO's running total. The check that matters happens before the invoice is approved for payment: does the new total exceed the ceiling in the reference table? If yes, the invoice holds for review rather than being paid and reconciled later, when the vendor has already been paid past the cap and recovery becomes a negotiation instead of a routine hold.

## 4. Can you detect an overrun that already happened?

Yes. A retrospective review pulls every invoice tied to a given PO or SOW over the contract period, sums them, and compares the total to the ceiling stated in the governing document. This is exactly the reconstruction a margin drift review performs across historical spend when no cumulative control existed at the time. The finding is the amount paid beyond the cap, which can be recoverable if the vendor billed past an enforceable ceiling without an approved change order. Retrospective detection does not need a real-time system. It needs the contract file, the PO history, and the full invoice record for the engagement, matched up by PO or SOW number rather than by invoice date. Once every invoice is attributed to its governing contract, the arithmetic is the same as the forward-looking control: sum, compare, flag. The harder part is usually not the math. It is locating the governing NTE language in the first place, since it can sit in a master agreement, an amendment, or a change order that was never linked back to the PO in the ERP. A review of service vendor spend against contract terms is built around solving that linkage problem across a full vendor file rather than one engagement at a time.

## 5. Does an approved change order ever make an overrun legitimate?

Yes. A written, approved change order that raises the ceiling makes the higher total legitimate, and it is not an overrun. The distinction that matters is whether the increase was authorized before or after the vendor billed past the original cap. An overrun discovered after the fact with no matching change order in the file is the finding; an overrun with a signed authorization on record is a contract amendment, not drift. This is where detection has to be more than a math check. Before flagging a crossed cap as recoverable, confirm whether a change order exists that raised the ceiling, and whether it was signed before the invoices that relied on it were issued. A change order signed after the fact to paper over an overrun already billed is a different situation: it may still represent a legitimate business decision, but it is worth flagging separately from an overrun with no authorization at all. Treating every crossed cap as an automatic finding without checking for authorization produces false positives that undermine the credibility of the review. The clean version of this control checks both conditions: was the cap exceeded, and if so, was there a signed authorization on record before it was.

## 6. Which service categories carry the most NTE exposure?

Not-to-exceed clauses appear wherever billing is time-and-materials rather than fixed-fee: contract labor and staffing engagements, IT and professional services projects, and maintenance and repair work billed by the hour. Each of these categories structures its NTE cap differently, so tracking cumulative totals against the right ceiling requires knowing which format the specific contract uses rather than applying one template across every vendor. The mechanics of the ceiling change by category, so a single detection template rarely fits all of them without adjustment for how each contract states its cap. - Contract labor and staffing: Caps are typically an hourly rate times an approved hour count, and [shift or overtime premiums](/glossary/shift-and-overtime-premium-misuse) can push the total past the cap faster than straight time would. - IT and professional services: Project-based NTE caps often apply per phase, so a total that looks fine against the whole engagement can already be over on an individual phase. - Maintenance and repair: Time-and-materials work orders frequently carry an NTE tied to the specific job, separate from any annual service agreement covering the same vendor. For the wider pattern this sits inside, start with the [margin drift](/insights/margin-drift-spend-leakage-guide) guide. See also [the six categories drift hides in](/guides/indirect-spend-audit-categories) and [what is margin erosion? causes and prevention for manufacturers](/guides/what-is-margin-erosion-causes-and-prevention-for).

## Common questions

### What is a not-to-exceed clause?

It is contract or purchase order language that sets a ceiling on total billing for a project, phase, or labor engagement. The vendor is not authorized to bill past that ceiling without a signed change order raising it. The clause can state the cap as a dollar total, an hour count converted to dollars, or a per-phase limit.

### Why does my ERP not flag an NTE overrun automatically?

Most ERPs match an invoice against its purchase order and receipt, not against a cumulative total tracked over the life of a contract. If the NTE ceiling was never entered as a trackable field, there is nothing in the system for a new invoice to be compared against, so the overrun accumulates unnoticed.

### Is every crossed NTE cap a billing error?

No. A written, approved change order signed before the additional work was billed makes a higher total legitimate. The overrun worth investigating is one with no matching authorization in the file, or one where the change order was signed after the vendor had already billed past the original cap.

### Can an NTE overrun be recovered after the invoices are already paid?

Yes, if the overrun is confirmed against contract language and no valid change order authorized it. Recovery at that point is a claim against the vendor for amounts billed outside the contract's authorized ceiling, and the strength of the claim depends on how clearly the original cap was documented.

### How far back should I check for NTE overruns?

A margin drift diagnostic typically reviews 12 to 18 months of historical spend across service vendor categories, since that window covers most active contracts and purchase orders without requiring records outside normal retention periods.

---

ValueXPA runs a fixed-scope Margin Drift Diagnostic that validates every service vendor invoice against contract terms, for $100M+ US industrial manufacturers and distributors. Two to four weeks. The client retains 100% of recoveries. https://valuexpa.com/contact-us