Can three-way match catch not-to-exceed overrun?

Executive Summary

Three-way matching confirms that an invoice's price and quantity agree with the purchase order and the receiving record. A not-to-exceed cap is a separate promise: total billed cost on a job or work order will not pass a stated ceiling, regardless of what the PO line items say individually. Three-way match has no field for that ceiling and no step that sums against it.

The result is structural, not a failure of diligence. An invoice can match its PO line by line, unit by unit, and still push the job's cumulative total over the NTE cap, because the match runs invoice by invoice and the cap runs job by job. Nothing in the standard three-way flow aggregates across invoices to test a running total against a contract ceiling.

Closing that gap means adding a control that tracks cumulative billing against the NTE value stated in the contract or work order, separate from and in addition to the price and quantity checks three-way matching already performs. The diagnostic and the contract compliance audit exist for exactly this kind of contract-side term that the ERP was never configured to read.

1. What does three-way matching actually check?

Three-way matching compares three documents for one invoice: the purchase order, the receiving record, and the invoice itself. It confirms the vendor billed the price on the PO, for the quantity received, without a currency or unit mismatch. That is the full scope of the check.

It runs per invoice, against per-line data, and stops once those three documents agree with each other, with no reference to any contract ceiling.

The control was designed to catch a specific error: a vendor billing $42 per unit against a PO that says $38, or invoicing for 500 units when the receiving dock logged 480. Both are line-level discrepancies, and three-way matching finds them reliably because the comparison is arithmetic and the source documents sit in the same system.

That design choice is also its boundary. The match has no concept of a job, a work order lifecycle, or a running total across multiple invoices tied to the same engagement. Each invoice clears or fails on its own terms.

An NTE clause does not live at the line level. It caps the sum of everything billed against a scope of work, across however many invoices that scope generates. A control built to compare one invoice to one PO has no mechanism for tracking a sum that spans invoices it has already closed out.

2. Why does an NTE cap fall outside that check?

A not-to-exceed cap constrains cumulative cost across a job, not any single invoice's price or quantity. Three-way matching evaluates one invoice against one PO and one receipt, with no running total carried forward. An invoice can be individually correct, correct price, correct quantity, correct unit, and still be the invoice that pushes the job's cumulative billing past the ceiling the contract set.

Consider a maintenance work order with an NTE of a stated dollar value, billed across four separate invoices as the job progresses. Three-way matching checks invoice one against its PO line and passes it. It checks invoice two the same way, invoice three, invoice four. Each passes independently.

No step in that sequence asks what invoices one through four sum to, and whether that sum exceeds the NTE stated in the work order. The receiving system was never asked to hold that number, and the match was never configured to test against it.

This is not a flaw in execution. It is a scope boundary. Three-way matching answers whether an invoice matches its own PO, and an NTE overrun is a violation of a different question entirely: whether the total billed on a job stays under its ceiling.

3. Which contract terms live outside the ERP's field structure?

An NTE cap typically sits in a statement of work or a signed contract PDF, not as a structured field the ERP enforces automatically. The same is true of rebate thresholds, volume tier breakpoints, and surcharge expiration dates. None of these get tested unless someone maps the contract term to a rule and checks invoices against it, which is a step outside the standard receiving-and-matching workflow.

These terms share one trait: they are written in prose, in a signed document sitting outside the ERP, rather than as a configured field the system checks automatically. Someone has to read the contract, extract the term, and build the rule before any invoice can be tested against it.

• Not-to-exceed ceilings: A cumulative dollar cap on a job or work order, tracked nowhere in the PO-to-receipt chain.
• Rebate thresholds: A volume level that triggers a credit back, invisible to a control that checks price and quantity only.
• Volume tier breakpoints: A rate that should step down past a quantity threshold, which the match has no reason to recompute.
• Surcharge expiration dates: A temporary charge with an end date buried in a contract, not in the ERP's rate table.

4. How would a control actually catch an NTE overrun?

Catching an NTE overrun requires a running total, not a line comparison: the contract's stated cap held as a reference value, and every invoice against that job or work order added to a cumulative sum tested against it. This is a job-level aggregation step layered on top of, not instead of, three-way matching, since price and quantity checks still matter independently of whether the cumulative cap has been reached.

The mechanism has two parts. First, the NTE value has to be extracted from the contract or work order and stored somewhere the AP process can reference, since it rarely exists as a native ERP field. Second, each new invoice against that job needs its amount added to a running total for that job specifically, then compared against the stored cap before or at the point of payment.

Neither part is exotic. But both require a system, or a person, that reads the contract document and tracks state across invoices over the life of a job. That is a different job than matching one invoice to one PO, and it is why the overrun survives a clean three-way match: the match was never asked the cumulative question.

5. Does this mean three-way matching is broken?

No. Three-way matching does what it was designed to do, catching price and quantity discrepancies at the invoice level, and removing it would reopen exactly those errors. The issue is scope, not defect: an NTE overrun is a cumulative, job-level condition, and no invoice-level control, however well run, tests a cumulative condition. The fix adds a layer; it does not replace the one already working.

It is worth separating a control's design limit from a control failure. Three-way matching was never specified to sum across invoices or read a contract's cap. Judging it against that standard sets it up to fail a test it was not built for.

The practical implication is additive. A contract compliance audit maps NTE values, rebate terms, and tier breakpoints against actual invoicing activity precisely because that mapping sits outside what receiving and matching already do. It is complementary work, not a replacement for three-way matching, which still catches the line-level errors it was designed to catch.

6. How does an NTE overrun differ from other drift types in AP?

A not-to-exceed overrun is a cumulative, job-level breach of a contract ceiling. A duplicate payment is a single invoice paid twice. A missed credit memo is a credit the vendor issued but the buyer never applied. Each drift type fails a different control at a different point, so a fix built for one rarely catches another; each needs its own check mapped to its own contract term.

An NTE overrun requires tracking a sum over time against a ceiling. A duplicate payment requires checking whether an invoice number, or its amount and vendor combination, has already been paid, a lookup problem rather than an aggregation problem. A missed credit memo requires matching a vendor-issued credit document to an open AP balance, a reconciliation problem.

The common thread across these is not a shared mechanism, since the failure points are different, but a shared cause: each is a contract or vendor-side term that lives outside the fields the ERP checks by default. Recognizing which category a given finding belongs to determines which control closes it. Treating every finding as one generic overbilling problem tends to produce a fix that closes one gap and leaves the rest open.

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

7. Frequently Asked Questions (People Also Ask)

Does three-way matching test a not-to-exceed cap at all?

No. Three-way matching compares an invoice's price and quantity to its purchase order and receiving record. An NTE cap is a cumulative ceiling across a job's total billing, which requires summing multiple invoices, a step three-way matching does not perform.

Can an invoice pass three-way matching and still violate an NTE clause?

Yes. An invoice can carry the correct price and quantity against its own PO line and still be the invoice that pushes a job's cumulative billing past the NTE ceiling stated in the contract, because the match never checks the running total.

Where is the NTE value usually stored if not in the ERP?

Typically in the signed contract, statement of work, or work order document itself, as unstructured text or a line in a PDF, rather than as a structured field the ERP references during invoice processing.

Is fixing this a matter of configuring three-way matching differently?

Not directly. Three-way matching operates per invoice. Catching an NTE overrun requires a separate, job-level control that tracks cumulative billing against a stored cap, layered alongside the existing match rather than built into it.

Does adding NTE tracking replace three-way matching?

No. Three-way matching still catches price and quantity errors at the invoice level, which an NTE-tracking control does not test. The two address different failure points and both stay necessary.

How is an NTE overrun different from a volume tier misapplication?

An NTE overrun is a breach of a cumulative cost ceiling. A volume tier misapplication is billing at the wrong rate because a quantity threshold was crossed and the rate never stepped down. Both are contract terms the ERP does not test by default, but they require different checks.

Who typically finds NTE overruns if AP does not?

A contract compliance audit maps NTE values and other contract-side terms against actual invoicing activity across a job's life, which is the aggregation step standard AP workflows do not perform.

Does this apply to a single invoice or a whole job?

An NTE overrun is a whole-job condition. It only becomes visible once every invoice tied to that job or work order is summed and compared against the ceiling, not when any one invoice is reviewed on its own.