The five-test margin drift checklist

A five-test checklist for finding margin drift in vendor invoices: rate cards, volume tiers, surcharges, rebates, and duplicate vendor records.

Twitter LinkedIn WhatsApp
Ask AI: ChatGPT Claude Gemini Grok
The five-test margin drift checklist

Margin drift is the gap between what a vendor contract says and what the invoice actually charges. It builds up quietly: a rate card version that never synced to the ERP, a surcharge that outlived the condition that justified it, a rebate nobody reconciled against the actual.

A checklist forces the question at five specific points instead of hoping a general invoice review catches it. Each test targets one mechanism where a contract term and a billed line can diverge, and each one is checkable against data your AP team already holds.

Executive Summary

Margin drift rarely shows up as one dramatic overcharge. It accumulates across five recurring mechanisms: a stale rate card, an unrecognized volume tier, a surcharge past its expiration condition, a rebate never claimed against the actual, and a vendor billing under two different records. Each mechanism sits in a different system, which is exactly why a general invoice review misses them: no single check tests all five.

The five-test checklist exists to close that gap without new software. It gives an AP or controller team five discrete pass or fail checks, each with a stated data requirement, that can be run against a sample of vendor invoices in an afternoon.

What changes is specificity. A team running "review invoices for accuracy" finds what happens to be visible. A team running five named tests against five named mechanisms finds what those mechanisms actually produce, and can point to which contract clause failed and why.

1. What is the five-test margin drift checklist?

It is five discrete checks run against a sample of vendor invoices, each testing one mechanism that lets a contract term and a billed amount diverge: the rate card, the volume tier, the surcharge expiration date, the rebate accrual, and the vendor master record. A test passes when the invoice matches the contract on that specific point, independent of whether it passes the other four.

The five tests are independent by design. A vendor can pass the rate card test and fail the surcharge test on the same invoice, because the two failures come from different documents: a price sheet on one side, a fuel or accessorial schedule on the other. Testing them separately is what makes the results usable, because each failure points a reader back to one specific contract clause instead of a vague "overbilled" flag.

Running all five against every invoice is not the goal. A sample large enough to be representative of a vendor's billing pattern, checked on all five tests, tells you more than a full population checked on one.

  1. Rate card match: Confirms the unit price on the invoice matches the current, signed rate card, not a prior version.
  2. Volume tier trigger: Confirms a volume threshold in the contract actually applied once spend crossed it.
  3. Surcharge expiration: Confirms a surcharge tied to a condition or date stopped billing once that condition ended.
  4. Rebate accrual: Confirms an earned rebate was accrued and actually claimed, not left on the vendor's books.
  5. Duplicate vendor record: Confirms the vendor is not billing under two different vendor master entries at once.

2. How do you run the rate card match test?

Pull the current signed rate card for the vendor, then compare its unit prices line by line against a sample of recent invoices. A pass means every billed unit price matches the current sheet. A fail means the invoice is billing against an older price file, which is the single most common way a renegotiated rate never reaches the invoice.

This test needs two documents open side by side: the signed rate card and the invoice detail, not the summary total. Summing invoices to a contract total can hide a line that is wrong in one direction and offset by a line wrong in the other.

The usual point of failure is not fraud. It is that the rate card lives in a contract folder and the ERP price file lives somewhere else, and nobody owns the step of pushing an update from one to the other. That gap is the subject of price file governance, and it is worth reading separately from this checklist because it explains why the same failure recurs even after a correction.

The rate card test also depends on the invoice supporting a true three-way match. If the invoice, purchase order, and receipt do not tie to the same unit price field, the mismatch can hide inside a matched invoice.

3. How do you run the volume tier trigger test?

Total the vendor's billed volume for the period and compare it against the tier thresholds written in the contract. A pass means the invoice reflects the lower per-unit rate once cumulative volume crossed the threshold. A fail means the vendor kept billing the lower tier's rate after volume justified the better one.

Volume tiers fail quietly because the trigger depends on a running total, not a single invoice. A vendor billing correctly on every individual invoice can still fail this test across the quarter, once volume is summed and compared to the tier schedule.

Run this test on a period long enough to cross at least one tier boundary. A single month of invoices from a vendor near a threshold will not show the failure; a full quarter will.

The contract language matters here more than in the other tests. Some tiers apply retroactively to all volume once crossed, others apply only prospectively from the crossing point forward. Reading the clause before running the test avoids flagging a correct invoice as a failure.

4. How do you run the surcharge expiration test?

Identify every surcharge line tied to a condition or date in the contract, such as a fuel index threshold or a temporary accessorial fee, and check whether that condition still held on the invoice date. A pass means the surcharge condition was still active. A fail means the surcharge kept billing after its own trigger expired.

Surcharges are written with a start condition far more often than an end condition, which is why this test exists separately from the rate card test. A rate card error is usually a stale price. A surcharge error is usually a live charge that should have stopped.

The practical difficulty is that the expiration condition often lives outside the ERP entirely, in a fuel index, a seasonal clause, or a one-time project scope that ended. Three-way matching checks the invoice against the purchase order and receipt; it does not test whether a surcharge's underlying condition has lapsed.

Surcharge sunset dating as a control is the fix for this test recurring every period: building an expiration date into the system record at the point the surcharge is first approved, rather than relying on someone remembering to check it later.

5. How do you run the rebate accrual test?

Compare the rebate accrued on the books against the rebate actually claimed and received from the vendor for the same period. A pass means the two figures match within a stated tolerance. A fail means an earned rebate sits accrued but unclaimed, which is margin the company already counted but never collected.

This test requires two figures that are rarely pulled together: the accrual entry from the general ledger and the vendor's own rebate statement or credit memo. Most AP review checks the invoice against the purchase order and receipt; it does not test the rebate ledger against the vendor's rebate statement, because those two documents sit in different systems.

A gap between accrual and actual is not automatically a vendor error. It can be a timing difference, a claim filed late, or a threshold the company itself never crossed. The test's job is to surface the gap, not to assume its cause.

Rebate accrual against actual is worth reading on its own, because the reconciliation step it describes is the one this test depends on and the one most AP calendars never schedule.

6. How do you run the duplicate vendor test?

Search the vendor master for records sharing a tax ID, remit-to address, or near-identical name, then check whether invoices from both records reference the same underlying contract. A pass means each vendor has one record and one billing history. A fail means the same vendor is billing under two records, which can produce a duplicate payment neither record shows alone.

Duplicate vendor records are easy to miss because each individual record looks clean. The problem only appears when the two records are compared against each other, which most AP workflows never do since each invoice is approved against its own vendor record in isolation.

Vendor master hygiene and the duplicate vendor problem covers the setup work that prevents this: standardizing tax ID and remit-to fields at intake so a second record cannot be created without a match warning firing first.

Where a duplicate is confirmed, n-way invoice matching across both records, not just the purchase order and receipt, is what surfaces whether the same invoice or a near-duplicate was paid twice under different vendor numbers.

7. How often should you run the five tests?

Run the full five-test set at least quarterly against every vendor above a stated spend threshold, and monthly against any vendor already flagged from a prior failure. The right cadence depends on how much billing volume moves between tests, not a fixed calendar rule; a vendor billing daily accumulates drift faster than one billing annually.

The cadence question is really a choice between two control philosophies. A periodic run of the five tests catches drift after it has accumulated for a quarter. A continuous check on each new invoice catches it before payment, at the cost of building the check into the invoice workflow itself.

Continuous enforcement vs. periodic audit: choosing a cadence works through that tradeoff in full; the short version is that periodic testing needs no new system and continuous testing needs no lookback.

However a company chooses to run it, the checklist works best as a standing item rather than a one-time exercise. The quarterly margin drift review: a control design pattern describes how to build the five tests into a recurring review rather than a single audit.

A starting cadence by vendor risk, to adjust against your own billing volume.

Vendor profile Suggested test frequency Why
High spend, prior failure Monthly Drift compounds fastest where volume and history are both present.
High spend, clean history Quarterly Volume justifies regular testing even without a known issue.
Low spend, any history Annually or at renewal Low invoice volume limits how much drift can accumulate between checks.

8. What do you do when a test fails?

Document the specific contract clause the invoice failed against, not just the dollar variance, then route it to the vendor as a dispute referencing that clause. A failure is evidence for a credit request, not an automatic overcharge; some gaps resolve as timing differences once the vendor responds with their own records.

The clause reference is what makes a dispute defensible. A vendor presented with "this invoice looks high" can reasonably ask for specifics. A vendor presented with "line 14 bills $X per unit against a rate card signed on this date at $Y per unit" has a narrow set of responses: correct it, or produce a newer rate card the requester has not seen.

A single failed test on one invoice is a data point, not a pattern. Before escalating, check whether the same test fails across the vendor's other recent invoices; a one-time failure often traces to a data entry error rather than a systemic gap.

Where a pattern does emerge across multiple tests or multiple periods, that is the signal to move from a one-off dispute to a structural fix, whether that means correcting the price file, resetting the surcharge expiration date, or merging the duplicate vendor record.

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

9. Frequently Asked Questions (People Also Ask)

What is the five-test margin drift checklist?

A set of five independent checks run against vendor invoices: rate card match, volume tier trigger, surcharge expiration, rebate accrual against actual, and duplicate vendor record. Each test targets one mechanism where a contract term and a billed amount can diverge, and each can fail or pass on its own regardless of the other four.

Do I need software to run these five tests?

No. Every test can be run manually against a sample of invoices, the signed rate card, the rebate statement, and the vendor master file. The checklist is designed to work with documents an AP or controller team already has, not a new system.

How many invoices should I sample for each test?

Enough to represent the vendor's billing pattern across a period long enough to cross any volume tier or surcharge condition in the contract, typically a full quarter rather than a single month. A small sample from one month can miss a tier or expiration failure entirely.

Which test should I run first if I can only run one?

There is no ranking that applies to every vendor; the right first test depends on which contract clause carries the most dollar exposure for that specific vendor. A vendor with a large surcharge schedule warrants the expiration test first; a vendor on a tiered rate card warrants the volume tier test first.

What counts as a passing rate card match?

The unit price billed on the invoice matches the currently signed rate card, not a prior version, on every sampled line. A partial match, where some lines tie and others do not, should be recorded as a fail on the specific lines that diverge, not scored as an overall pass.

Can a failed rebate accrual test mean the vendor is right?

Yes. A gap between accrued and actual rebate can be a timing difference, a claim filed but not yet processed, or a threshold the company has not actually crossed. The test surfaces the gap; confirming the cause requires pulling the vendor's own rebate statement before treating it as an error.

How is the duplicate vendor test different from a normal vendor master review?

A normal vendor master review checks each record for completeness on its own. This test compares records against each other, looking for a shared tax ID, remit-to address, or near-identical name that suggests one vendor is billing under two separate records, which a single-record review cannot surface.

Should every vendor be tested on the same cadence?

No. The right cadence depends on billing volume and prior history rather than a single company-wide rule. A high-spend vendor with a known prior failure warrants monthly testing; a low-spend vendor with a clean history can be tested annually or at contract renewal.

What do I do with the results of the checklist?

Route each failure to the vendor as a dispute that cites the specific contract clause and invoice line, not just the dollar variance. Track whether the same test fails again on the vendor's next invoices before deciding whether the fix needs to happen at the vendor or inside your own price file or vendor master data.

Executive Summary

Margin drift rarely shows up as one dramatic overcharge. It accumulates across five recurring mechanisms: a stale rate card, an unrecognized volume tier, a surcharge past its expiration condition, a rebate never claimed against the actual, and a vendor billing under two different records. Each mechanism sits in a different system, which is exactly why a general invoice review misses them: no single check tests all five. The five-test checklist exists to close that gap without new software. It gives an AP or controller team five discrete pass or fail checks, each with a stated data requirement, that can be run against a sample of vendor invoices in an afternoon. What changes is specificity. A team running "review invoices for accuracy" finds what happens to be visible. A team running five named tests against five named mechanisms finds what those mechanisms actually produce, and can point to which contract clause failed and why.

1. What is the five-test margin drift checklist?

It is five discrete checks run against a sample of vendor invoices, each testing one mechanism that lets a contract term and a billed amount diverge: the rate card, the volume tier, the surcharge expiration date, the rebate accrual, and the vendor master record. A test passes when the invoice matches the contract on that specific point, independent of whether it passes the other four. The five tests are independent by design. A vendor can pass the rate card test and fail the surcharge test on the same invoice, because the two failures come from different documents: a price sheet on one side, a fuel or accessorial schedule on the other. Testing them separately is what makes the results usable, because each failure points a reader back to one specific contract clause instead of a vague "overbilled" flag. Running all five against every invoice is not the goal. A sample large enough to be representative of a vendor's billing pattern, checked on all five tests, tells you more than a full population checked on one. 1. Rate card match: Confirms the unit price on the invoice matches the current, signed rate card, not a prior version. 2. Volume tier trigger: Confirms a volume threshold in the contract actually applied once spend crossed it. 3. Surcharge expiration: Confirms a surcharge tied to a condition or date stopped billing once that condition ended. 4. Rebate accrual: Confirms an earned rebate was accrued and actually claimed, not left on the vendor's books. 5. Duplicate vendor record: Confirms the vendor is not billing under two different vendor master entries at once.

2. How do you run the rate card match test?

Pull the current signed rate card for the vendor, then compare its unit prices line by line against a sample of recent invoices. A pass means every billed unit price matches the current sheet. A fail means the invoice is billing against an older price file, which is the single most common way a renegotiated rate never reaches the invoice. This test needs two documents open side by side: the signed rate card and the invoice detail, not the summary total. Summing invoices to a contract total can hide a line that is wrong in one direction and offset by a line wrong in the other. The usual point of failure is not fraud. It is that the rate card lives in a contract folder and the ERP price file lives somewhere else, and nobody owns the step of pushing an update from one to the other. That gap is the subject of [price file governance](/guides/price-file-governance-why-annual-uploads-create-twelve), and it is worth reading separately from this checklist because it explains why the same failure recurs even after a correction. The rate card test also depends on the invoice supporting a [true three-way match](/guides/the-three-way-match-gap-what-your-erp-structurally-cannot). If the invoice, purchase order, and receipt do not tie to the same unit price field, the mismatch can hide inside a matched invoice.

3. How do you run the volume tier trigger test?

Total the vendor's billed volume for the period and compare it against the tier thresholds written in the contract. A pass means the invoice reflects the lower per-unit rate once cumulative volume crossed the threshold. A fail means the vendor kept billing the lower tier's rate after volume justified the better one. Volume tiers fail quietly because the trigger depends on a running total, not a single invoice. A vendor billing correctly on every individual invoice can still fail this test across the quarter, once volume is summed and compared to the tier schedule. Run this test on a period long enough to cross at least one tier boundary. A single month of invoices from a vendor near a threshold will not show the failure; a full quarter will. The contract language matters here more than in the other tests. Some tiers apply retroactively to all volume once crossed, others apply only prospectively from the crossing point forward. Reading the clause before running the test avoids flagging a correct invoice as a failure.

4. How do you run the surcharge expiration test?

Identify every surcharge line tied to a condition or date in the contract, such as a fuel index threshold or a temporary accessorial fee, and check whether that condition still held on the invoice date. A pass means the surcharge condition was still active. A fail means the surcharge kept billing after its own trigger expired. Surcharges are written with a start condition far more often than an end condition, which is why this test exists separately from the rate card test. A rate card error is usually a stale price. A surcharge error is usually a live charge that should have stopped. The practical difficulty is that the expiration condition often lives outside the ERP entirely, in a fuel index, a seasonal clause, or a one-time project scope that ended. Three-way matching checks the invoice against the purchase order and receipt; it does not test whether a surcharge's underlying condition has lapsed. [Surcharge sunset dating as a control](/guides/surcharge-sunset-dating-as-a-control) is the fix for this test recurring every period: building an expiration date into the system record at the point the surcharge is first approved, rather than relying on someone remembering to check it later.

5. How do you run the rebate accrual test?

Compare the rebate accrued on the books against the rebate actually claimed and received from the vendor for the same period. A pass means the two figures match within a stated tolerance. A fail means an earned rebate sits accrued but unclaimed, which is margin the company already counted but never collected. This test requires two figures that are rarely pulled together: the accrual entry from the general ledger and the vendor's own rebate statement or credit memo. Most AP review checks the invoice against the purchase order and receipt; it does not test the rebate ledger against the vendor's rebate statement, because those two documents sit in different systems. A gap between accrual and actual is not automatically a vendor error. It can be a timing difference, a claim filed late, or a threshold the company itself never crossed. The test's job is to surface the gap, not to assume its cause. [Rebate accrual against actual](/guides/rebate-accrual-vs-actual-the-reconciliation-nobody-runs) is worth reading on its own, because the reconciliation step it describes is the one this test depends on and the one most AP calendars never schedule.

6. How do you run the duplicate vendor test?

Search the vendor master for records sharing a tax ID, remit-to address, or near-identical name, then check whether invoices from both records reference the same underlying contract. A pass means each vendor has one record and one billing history. A fail means the same vendor is billing under two records, which can produce a duplicate payment neither record shows alone. Duplicate vendor records are easy to miss because each individual record looks clean. The problem only appears when the two records are compared against each other, which most AP workflows never do since each invoice is approved against its own vendor record in isolation. Vendor master hygiene and the duplicate vendor problem covers the setup work that prevents this: standardizing tax ID and remit-to fields at intake so a second record cannot be created without a match warning firing first. Where a duplicate is confirmed, [n-way invoice matching across both records](/guides/n-way-invoice-matching-explained), not just the purchase order and receipt, is what surfaces whether the same invoice or a near-duplicate was paid twice under different vendor numbers.

7. How often should you run the five tests?

Run the full five-test set at least quarterly against every vendor above a stated spend threshold, and monthly against any vendor already flagged from a prior failure. The right cadence depends on how much billing volume moves between tests, not a fixed calendar rule; a vendor billing daily accumulates drift faster than one billing annually. The cadence question is really a choice between two control philosophies. A periodic run of the five tests catches drift after it has accumulated for a quarter. A continuous check on each new invoice catches it before payment, at the cost of building the check into the invoice workflow itself. Continuous enforcement vs. periodic audit: choosing a cadence works through that tradeoff in full; the short version is that periodic testing needs no new system and continuous testing needs no lookback. However a company chooses to run it, the checklist works best as a standing item rather than a one-time exercise. The quarterly margin drift review: a control design pattern describes how to build the five tests into a recurring review rather than a single audit. A starting cadence by vendor risk, to adjust against your own billing volume. | Vendor profile | Suggested test frequency | Why | | --- | --- | --- | | High spend, prior failure | Monthly | Drift compounds fastest where volume and history are both present. | | High spend, clean history | Quarterly | Volume justifies regular testing even without a known issue. | | Low spend, any history | Annually or at renewal | Low invoice volume limits how much drift can accumulate between checks. |

8. What do you do when a test fails?

Document the specific contract clause the invoice failed against, not just the dollar variance, then route it to the vendor as a dispute referencing that clause. A failure is evidence for a credit request, not an automatic overcharge; some gaps resolve as timing differences once the vendor responds with their own records. The clause reference is what makes a dispute defensible. A vendor presented with "this invoice looks high" can reasonably ask for specifics. A vendor presented with "line 14 bills $X per unit against a rate card signed on this date at $Y per unit" has a narrow set of responses: correct it, or produce a newer rate card the requester has not seen. A single failed test on one invoice is a data point, not a pattern. Before escalating, check whether the same test fails across the vendor's other recent invoices; a one-time failure often traces to a data entry error rather than a systemic gap. Where a pattern does emerge across multiple tests or multiple periods, that is the signal to move from a one-off dispute to a structural fix, whether that means correcting the price file, resetting the surcharge expiration date, or merging the duplicate vendor record. For the wider pattern this sits inside, start with the [margin drift](/guides/contract-compliance-controls-p2p) guide.

Questions & Answers

What is the five-test margin drift checklist?

A set of five independent checks run against vendor invoices: rate card match, volume tier trigger, surcharge expiration, rebate accrual against actual, and duplicate vendor record. Each test targets one mechanism where a contract term and a billed amount can diverge, and each can fail or pass on its own regardless of the other four.

Do I need software to run these five tests?

No. Every test can be run manually against a sample of invoices, the signed rate card, the rebate statement, and the vendor master file. The checklist is designed to work with documents an AP or controller team already has, not a new system.

How many invoices should I sample for each test?

Enough to represent the vendor's billing pattern across a period long enough to cross any volume tier or surcharge condition in the contract, typically a full quarter rather than a single month. A small sample from one month can miss a tier or expiration failure entirely.

Which test should I run first if I can only run one?

There is no ranking that applies to every vendor; the right first test depends on which contract clause carries the most dollar exposure for that specific vendor. A vendor with a large surcharge schedule warrants the expiration test first; a vendor on a tiered rate card warrants the volume tier test first.

What counts as a passing rate card match?

The unit price billed on the invoice matches the currently signed rate card, not a prior version, on every sampled line. A partial match, where some lines tie and others do not, should be recorded as a fail on the specific lines that diverge, not scored as an overall pass.

Margin Drift Resources