Can three-way match catch a rate schedule violation?

Executive Summary

Three-way match confirms that an invoice agrees with a purchase order and a receipt. It answers whether the right item arrived in the right quantity and whether someone approved the purchase. It does not open the underlying contract, so it cannot confirm the price on the invoice is the price the contract actually specifies for that volume, tier, or period.

A rate schedule violation happens inside the number itself: a rate card that was updated on paper but not in the ERP, a tier threshold the vendor's system never re-checked, or a surcharge that should have expired last quarter and did not. Three-way match passes all of these because the PO, the receipt, and the invoice can agree with each other while all three are wrong against the contract.

Closing that gap means checking the invoice against the contract document directly, line by line, on the rate itself rather than on the paperwork trail around it. That is a different control, run against a different source document, and it is where a margin drift review starts.

1. What does three-way match actually check?

Three-way match compares three documents: the purchase order, the receiving record, and the invoice. It confirms the vendor billed for what was ordered, in the quantity that arrived, at the unit price stated on the PO. That is a match against the PO's price field, not against the contract clause that set the price in the first place.

If the PO itself carries a stale or wrong rate, three-way match confirms the invoice against that wrong number and passes it.

The control exists to stop a narrow set of errors: billing for goods never ordered, billing for quantities never received, or paying twice against the same PO. Those are real problems and three-way match handles them well.

But the PO's unit price is typically populated once, at order creation, from whatever rate was loaded into the ERP at that time. Three-way match treats that price as the reference truth. It has no step that reopens the contract document and checks whether the loaded rate still matches the rate card, the tier the customer is actually in, or a surcharge schedule that changed.

A rate schedule violation is a mismatch between the invoice and the contract, not between the invoice and the PO. Those are usually the same number. When they diverge, because the source rate feeding the PO was never updated, three-way match has nothing to catch, since everything it checks still agrees.

2. Why do rate schedule violations pass through undetected?

A rate schedule violation survives three-way match because the error sits upstream of every document the control compares. If the rate loaded into the PO is wrong, the receipt and the invoice can both agree with it perfectly. The control was designed to catch disagreement between documents, and a stale rate produces agreement everywhere, just agreement on the wrong number.

The contract itself is never one of the three documents being matched.

Rate cards live in contract PDFs, addenda, and side letters, not inside the ERP as a structured, versioned field. When a vendor renegotiates a rate, someone has to manually update the ERP's price table or the PO template. If that update does not happen, or happens on the vendor's system but not the buyer's, the PO keeps generating at the old rate indefinitely.

Three-way match has no mechanism to detect that the underlying contract changed. It was never given the contract as an input. It compares documents to each other, and none of those three documents is the contract itself.

This is why a rate schedule violation can run for an extended stretch of invoices, all internally consistent, all passing every AP control, while diverging further from the contract with each billing cycle.

3. Which mechanisms does three-way match rely on, and where do they stop?

Three-way match runs three discrete checks: quantity match, item match, and price-to-PO match. Each one stops at the document boundary it was built to compare. None of the three tests the rate against the contract clause that set it, the volume tier the account should currently sit in, or an escalation formula tied to an index.

Understanding these as separate, bounded checks explains exactly why a rate-level problem sits outside all three.

These checks were built to compare documents generated inside the same purchasing workflow. None of them was designed to reopen a contract.

A. Quantity and item match

This check confirms the units and SKU or service line on the invoice equal what the receiving record shows arrived. It is a physical-count check. A wrong contracted rate applied to the correct quantity of the correct item passes this check without issue, because quantity and item identity are not what a rate schedule violation touches.

B. Price-to-PO match

This check confirms the unit price on the invoice equals the unit price on the PO. It is a document-to-document comparison, not a document-to-contract comparison. The PO's price field is populated from whatever rate table was current at PO creation, and three-way match has no step that revalidates that source table against the contract on a recurring basis.

4. What would actually catch a rate schedule violation?

Catching a rate schedule violation requires comparing the invoice's rate directly against the contract document, on a recurring basis, rather than against the PO or the receipt. That means reading the rate card, the tier structure, and any surcharge or escalation clause, then checking each invoice line against those terms specifically. This is a contract compliance check, a different control from three-way match, run against a different source document entirely.

The check has to start from the contract, not from the ERP's stored price. That means extracting the rate card, the volume tier structure, any minimum or maximum charge, and any surcharge or index clause the contract actually specifies, then holding each new invoice against those terms directly.

It also has to run on a recurring basis, not once at PO setup. A rate is only correct at a point in time; a control that checks it once and never again will miss a renegotiation that three-way match still will not see.

This is the work of a contract compliance audit rather than an AP control. It treats the contract as the source of truth and the invoice as the thing being tested against it, the reverse of how three-way match is built.

5. Where does this fit against other drift types in indirect spend?

Rate schedule violation is one of several distinct drift types that a contract-level review checks for, each with its own mechanism and its own place in the contract. They are not ranked against each other here, since no dataset exists to say which runs larger in a given account; each is worth checking on its own terms rather than assumed away because three-way match already ran.

Each drift type below has a different trigger inside the contract and needs its own check.

• Rate schedule violation: The invoiced unit rate no longer matches the rate the contract specifies for that line, tier, or period.
• Volume tier misapplication: The account is billed at the wrong pricing tier for its actual purchase volume under the contract's tier structure.
• Not-to-exceed overrun: Billed amounts pass a contractual cap without a corresponding change order or approval.
• Accessorial charge creep: Surcharges or add-on fees appear or persist beyond what the contract's accessorial schedule allows.
• Index escalation misapplied: An escalation clause tied to a published index is applied using the wrong index value or timing.

6. Should you still run three-way match if it cannot catch this?

Yes. Three-way match still stops duplicate billing, phantom deliveries, and unauthorized purchases, all real and separate problems from rate schedule violations. The point is not to replace it but to recognize what it does not cover, and add a contract-level check for the categories where the loaded rate itself can drift away from the contract without any document ever disagreeing with another.

Dropping three-way match to add a contract check would trade one gap for another. The two controls test different failure modes and neither substitutes for the other.

The practical fix is running both: three-way match for delivery and authorization integrity, and a separate rate-to-contract check for pricing accuracy. A margin drift review typically starts by running the second check against categories like freight, contract labor, and maintenance, where rate structures are complex enough that a stale PO price can persist unnoticed.

Where regulatory or contractual dispute questions arise from a finding, treat this as general information, not legal advice, and involve counsel before acting on a specific contract term.

For the wider pattern this sits inside, start with the margin drift guide. See also the six categories drift hides in and what is margin erosion? causes and prevention for manufacturers.

7. Frequently Asked Questions (People Also Ask)

Does three-way match check contract terms at all?

No. It checks that the invoice agrees with the purchase order and the receiving record. None of those three documents is the contract itself, so a rate that is wrong in all three simultaneously will pass without any flag.

Where does the price on the PO actually come from?

It is typically populated from the ERP's stored rate table at the time the PO is created. If that table was never updated when the contract's rate changed, the PO carries the old rate forward indefinitely, and three-way match validates against that stale figure.

Can ERP automation catch a rate schedule violation instead?

Standard ERP automation, including three-way match, tests documents against each other. It does not reopen the contract PDF or addendum to revalidate a stored rate. Catching this requires a control built specifically to compare invoices to the contract's rate terms directly.

Is a rate schedule violation the same thing as volume tier misapplication?

No. A rate schedule violation is a mismatch between the invoiced rate and the contracted rate for a line. Volume tier misapplication is a specific case where the account is billed at the wrong pricing tier for its actual purchase volume, a related but distinct mechanism.

How long can a rate schedule violation go undetected?

There is no fixed answer, since it depends on how long the stale rate stays loaded and how often anyone checks the invoice against the actual contract. Some are caught within a single billing cycle; others persist across a full contract term if nothing forces a rate reconciliation.

Does a four-way match solve this instead?

A four-way match typically adds a quality inspection step to the existing three. It still compares documents generated within the same ordering and receiving process, not the underlying contract. It does not add a check against the rate card or tier structure.

What document should a rate check actually use as its source of truth?

The contract itself: the rate card, tier table, and any addenda or amendments that changed pricing after signing. The ERP's stored price is a copy of that source, not the source, and copies can go stale without anyone updating them.

Who typically owns catching this inside a company?

It falls between procurement, which negotiates the contract, and AP, which pays the invoice. Neither owns a recurring check that reconciles the two, which is why the gap tends to persist until a dedicated contract compliance review looks for it.