Who Is Responsible for Catching NTE Overrun?

Executive Summary

A not-to-exceed cap is a contract term, not a line item on the invoice, and no single role in a standard AP workflow is built to test it. Procurement negotiates the cap and moves to the next contract. AP matches the invoice to a purchase order and a receipt, neither of which carries the cap value.

The vendor invoices its own actual cost, which can honestly exceed the ceiling without anyone at the vendor doing anything wrong.

The mechanism that lets an NTE overrun through is a gap between where the term lives and where the check runs. The cap sits in a contract document or a change order, often as text rather than a data field. Three-way matching checks the invoice against the PO and the receipt; it does not test whether the total charged sits under a cap negotiated somewhere else.

What changes it is assigning the cap a place to live outside the contract PDF, and assigning one role the job of testing invoiced totals against it before payment. That role can sit in AP, in procurement, or in a dedicated compliance function. What matters is that the assignment exists and is not assumed to be covered by an existing step.

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

A not-to-exceed overrun happens when a vendor invoices a job, a change order, or a project phase for more than the ceiling the contract sets for it. The cap is meant to protect the buyer from open-ended cost growth on time-and-materials or scope-based work. The overrun is not fraud by default: it is simply an invoice that was never checked against the specific dollar ceiling that governs it, because that ceiling lives in a document the payment process does not.

NTE caps appear most often in contract labor, maintenance and repair, and IT and professional services work, where the final cost depends on hours or materials that are not fixed in advance. The contract sets the ceiling as a safeguard: the vendor can bill actual cost up to that number, not beyond it.

The overrun itself is simple to state and easy to miss. The invoiced total for the job exceeds the cap stated in the contract or the change order that authorized the work. Catching it requires two things at once: knowing the cap, and having someone check the invoice against it before the payment runs.

2. Why does standard AP review miss this?

Three-way matching checks that an invoice agrees with a purchase order and a receipt of goods or services. None of those three documents typically carries the not-to-exceed value as a field the matching system can compare against. The cap lives in the contract or change order text, so the invoice can pass every standard match and still sit above the ceiling the contract actually set for that job.

A purchase order usually authorizes a vendor and a general scope of work. A receipt confirms the work happened. Neither one encodes a dollar ceiling tied to a specific change order, because that ceiling was negotiated separately, often in a contract amendment or an email approving a scope change.

The AP clerk processing the invoice sees a vendor, a PO number, and a total that reconciles against both. Every field the matching software checks agrees. The cap is simply not one of the fields being checked, so the invoice clears.

3. Who typically owns the contract terms that set the cap?

The role that negotiates the not-to-exceed cap, usually procurement or a project owner in facilities, IT, or maintenance, is rarely the role that reviews invoices for payment. The cap gets written into a contract or change order and then the negotiating team moves to the next engagement. Nobody downstream inherits the job of holding invoices to that specific number unless the handoff is built into the process on purpose.

Whichever team writes the cap into the deal understands why it was set and what it was meant to cover. That knowledge rarely travels past contract execution unless a process is built to carry it forward.

Accounts payable sees every invoice and controls the payment decision, which makes it the natural checkpoint. But it works from the PO and receipt, not the contract language, and has no reason to open a contract file for every invoice unless the process specifically asks for that check on capped work.

A. Procurement or project owner

This is the role with the clearest view of what the cap was meant to cover and why it was set at that level. They know the scope, the change order history, and the reason a ceiling exists at all. But their workflow ends at contract execution, not at invoice payment, so the knowledge does not travel with the invoice unless someone builds a path for it.

B. Accounts payable

AP sees every invoice and controls the payment decision, which makes it the natural checkpoint. But AP works from the PO and receipt, not the underlying contract language, and has no reason to open a contract PDF for every invoice unless the process specifically asks for that check on capped work.

4. Can a policy alone fix this, or does it need a system?

A written policy that says AP checks invoices against NTE caps does not by itself create a place where AP can find the cap value quickly for every invoice. Without a reference the cap has to be re-read from the original contract each time, which slows review and invites the check to be skipped under volume. A policy assigns responsibility; a shared reference is what makes the responsibility practical to execute consistently.

Assigning the check to a named role is the necessary first step and it is often skipped entirely. A policy that assumes AP will just look up the contract for every capped invoice adds friction that competes with processing volume and due dates.

The more durable fix separates the two problems: decide who owns the check, and separately, give that person a place to see the cap value without re-reading a contract every time. A spreadsheet, a shared field in the PO system, or a dedicated tracking tool all solve the second problem differently, but none of them solve the first. Ownership has to be assigned before a tool matters.

5. What does a working NTE control actually look like?

A working control names one role responsible for testing invoiced totals against the cap before payment, keeps the cap value somewhere that role can see without opening a contract file, and defines what happens when an invoice approaches or exceeds it. Without all three, the control exists on paper but not in practice, and an invoice above the ceiling clears the same review path as one within it.

None of the three pieces works alone. A named owner without a visible cap value ends up re-reading contracts under deadline pressure and skipping the check. A visible cap value with no named owner sits in a spreadsheet nobody is accountable for checking.

The trigger point and resolution path matter just as much: an invoice that crosses the cap needs a defined next step, not a judgment call made differently each time it happens.

• Named owner: One role, not a shared assumption, is accountable for checking capped invoices against their ceiling before payment.
• Accessible cap value: The dollar ceiling is recorded somewhere the owner can see it without reopening the original contract document each time.
• A trigger point: A defined threshold, such as an invoice nearing or crossing the cap, routes to review rather than passing straight to payment.
• A resolution path: A documented next step when an invoice exceeds the cap: hold payment, request a credit, or confirm a written scope change that authorized the excess.

6. How do you find out whether this control already exists at your company?

Pull a sample of invoices tied to contracts or change orders that carry a stated not-to-exceed value, then ask a simple question of each one: did anyone compare the total charged to the cap before payment, and can they show where they found the cap number. If the answer is no, or if it takes finding and reopening the original contract, the control does not exist in practice, whatever the policy manual says.

This test works because it separates the policy from the practice. A company can have a written rule requiring NTE checks and still have zero invoices where the check actually happened, because nobody made it easy to do.

The same sample also shows where the cap information currently lives: in a shared tracker, in someone's inbox, or only in the original signed contract. That answer points directly at what to fix first, whether that is assigning the role, building the reference, or both.

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

7. Frequently Asked Questions (People Also Ask)

Is a not-to-exceed overrun the vendor's fault or ours?

Neither by default. The vendor is invoicing its actual cost, which can honestly land above the cap. The overrun becomes a real problem only if nobody checks the invoice against the cap before paying it, which is a control gap on the buyer's side, not a vendor error.

Does three-way matching catch NTE overruns?

No. Three-way matching checks the invoice against the purchase order and the receipt. None of those documents typically carries the not-to-exceed value as a field, so an invoice can pass the match and still exceed the cap set in the underlying contract or change order.

Should procurement or AP own the NTE check?

Either can, but only if the role is explicitly assigned and given a way to see the cap without reopening the contract each time. Procurement knows the scope behind the cap; AP controls the payment decision. Assuming the other team covers it is how the gap forms.

What is the difference between an NTE overrun and a volume tier misapplication?

A not-to-exceed overrun is a total dollar ceiling on a specific job or change order being exceeded. A volume tier misapplication is a pricing structure keyed to quantity being applied at the wrong tier. Both are contract terms an invoice can violate without tripping a standard match.

Can an NTE overrun be legitimate?

Yes, if a documented scope change or written approval raised the ceiling before the work was billed. The problem is not every overrun; it is an overrun nobody checked against the original cap or the approval that changed it.

How do we know if this is costing us money right now?

Pull invoices tied to capped contracts or change orders and check whether the billed total was ever compared to the stated cap before payment. If that comparison did not happen, or happened inconsistently, an overrun could have cleared without anyone catching it.

Does a purchase order system stop this on its own?

Not unless the cap value is entered as a field the system checks against the invoice total. Most PO systems authorize a vendor and a scope, not a dollar ceiling tied to a specific change order, so the system approves the match without ever testing the cap.

Who should resolve an invoice that exceeds its cap?

Whoever owns the assigned check should hold the payment and route it to the person who can confirm whether a scope change authorized the excess. That is usually the project owner or procurement contact who negotiated the original cap.