Price file governance checklist

Executive Summary

A price file governance checklist is only useful if someone owns the moment a new rate enters the system, not just the moment it is reviewed a year later. The mechanism behind most stale-rate drift is not a bad vendor; it is a price file that was loaded once, at contract signing, and never touched again while the invoice stream kept charging against it as if nothing had changed.

A checklist fixes this only if it forces four things to happen on a schedule: someone names who can change a rate, someone confirms the file matches the current contract, someone tests a sample of invoices against that file, and someone logs the exceptions.

This page gives you the checklist itself and the order to run it in. It is written for the AP lead or controller who has to operationalize price file governance, not just diagnose that it is missing. Each control below answers a specific failure mode: an unauthorized rate change, a file that drifted from the signed contract, an invoice that charged against neither.

Used quarterly, this checklist turns price file governance from a one-time upload event into a standing control. That is the whole difference between a file that is accurate on day one and a file that stays accurate.

1. What does a price file governance checklist actually contain?

A price file governance checklist names five controls: who can add or change a rate, what document authorizes each entry, how often the file is reconciled against the signed contract, how a sample of invoices is tested against the file, and where exceptions get logged. It is not a description of the price file itself. It is a schedule of who checks it, against what, and how often, with a record left behind each time.

Write the checklist as a table, not a paragraph. Each row is a control, not a description. A control has an owner, a frequency, and a place the result gets recorded, even if that place is a shared spreadsheet.

The five rows that matter most: rate change authorization, contract-to-file reconciliation, sample invoice testing, exception logging, and vendor notification of file updates. Skip any one of them and the file drifts quietly, because a price file that nobody reconciles against the contract will still look complete. It will just be complete and wrong.

The checklist should also state what does NOT belong on it. It is not a tool for renegotiating rates or chasing rebates. It is narrower than that: it only confirms that the number sitting in the system still matches the number in the signed agreement.

2. Who should own each line on the checklist?

Rate entry belongs to whoever has system access to the price file, usually AP or IT, and that access should be logged and restricted. Contract reconciliation belongs to the person who holds the signed agreement, usually procurement or the contract owner. Invoice sample testing belongs to AP or an internal audit function.

No single person should both enter a rate and approve it: that separation is the control itself.

Separation of duties is the point of naming owners at all. If the same person who loads a new rate also signs off that it is correct, the checklist becomes a formality rather than a control.

Smaller AP teams sometimes cannot achieve full separation with headcount alone. In that case, a second reviewer for high-value vendor categories, checked less frequently for low-value ones, is a reasonable compromise, as long as the reduced frequency is a documented decision and not a default.

• Rate entry: Restricted to a named role with system access, never a shared login. Every change should carry a timestamp and a user ID.
• Change authorization: A separate person confirms the new rate matches a signed amendment or rate schedule before it goes live, not after.
• Reconciliation: The contract owner, usually procurement, compares the live file against the current agreement on a fixed schedule.
• Sample testing: AP or internal audit pulls a sample of paid invoices and checks them against the file, independent of whoever loaded it.
• Exception logging: Any mismatch gets a written record: the invoice, the file value, the contract value, and what was done about it.

3. How often should the price file be reconciled against the contract?

Reconcile the price file against the underlying contract on a fixed calendar schedule, not only when a new contract is signed or a dispute arises. A quarterly reconciliation catches a rate change that should have expired, a surcharge that should have sunset, or a tier that should have stepped down, before those errors compound across a full year of invoices. An annual-only check leaves months of invoices priced against a stale file before anyone notices.

The schedule matters more than the depth of any single check. A quarterly reconciliation that only samples ten line items catches more drift over a year than one exhaustive annual review, because it catches errors while the invoice volume behind them is still small.

Tie the reconciliation date to a fixed point, such as the first week of each quarter, rather than to whenever the reviewer has time. A checklist that runs on availability instead of a calendar stops running the first time someone gets busy.

For vendors with volume tiers, rebate clauses, or time-bound rate schedules, reconciliation should happen more frequently than for a flat-rate vendor, because those contract terms are the ones most likely to change without a corresponding file update. See how a stale price file compounds over a year in price file governance.

4. What should the invoice sample test actually check?

The invoice sample test pulls a set of recently paid invoices and checks each line against three things: the price file value, the signed contract value, and the amount actually charged. A pass means all three agree. A mismatch between the file and the contract is a governance failure; a mismatch between the invoice and the file is a billing error the vendor should be asked to explain.

Distinguishing these two failure types matters because they point to different fixes. If the file itself is wrong, the fix is internal: someone missed an update. If the invoice does not match a correct file, the fix is external: a dispute with the vendor.

Sample size should scale with vendor spend, not vendor count. A high-spend vendor with a single flat rate needs fewer samples than a mid-spend vendor with a tiered schedule and multiple surcharge conditions, because the tiered vendor has more places for the file and the invoice to disagree.

Record the sample result whether it passes or fails. A checklist that only documents failures cannot later demonstrate that testing actually happened on the vendors that passed.

5. What happens when the checklist finds a mismatch?

A mismatch triggers three steps in order: correct the price file if it is wrong, quantify what was overcharged or undercharged while the file was stale, and log both the correction and the quantified amount in the exception record. Do not correct the file and move on without quantifying the invoices already paid against the old value, because that step is the only place the recovery opportunity is captured.

The correction itself is usually simple: update the rate, note the effective date, and confirm the next invoice reflects it. The step teams skip is going back through invoices paid while the file was wrong.

Quantifying the exposure does not require a full audit. It requires pulling invoices from the affected vendor for the period the file was stale and re-pricing them at the correct rate. The difference is what a credit memo request or a dispute should recover.

Log the exception with enough detail that a reader six months later can see what was wrong, when it was caught, and what was recovered. This log becomes the evidence base for the next reconciliation cycle and for any conversation about tightening the checklist itself.

6. How does this checklist fit with a broader margin drift control?

A price file governance checklist is one control among several that keep an invoice honest against its contract. It works alongside vendor master hygiene, surcharge sunset dating, and rebate reconciliation, each catching a different failure point between contract and cash. Running the price file checklist without the others leaves gaps those controls exist specifically to close.

The price file checklist catches a stale rate. It does not catch a duplicate vendor record, an expired surcharge that keeps billing, or an earned rebate nobody claimed. Those are separate mechanisms with separate checklists, and treating one as a substitute for the others leaves real exposure uncovered.

A practical build order: get the price file checklist running first, since it is the most direct link between contract and invoice. Then layer in vendor master hygiene and surcharge sunset dating as the next controls, since both interact with the same price file infrastructure.

A control cadence decision follows naturally from this: whether these checks run on a fixed calendar or are folded into a broader quarterly review is itself worth designing deliberately rather than defaulting to.

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

7. Frequently Asked Questions (People Also Ask)

How often should we run the price file governance checklist?

Reconcile the file against the contract quarterly at minimum, and test a sample of paid invoices against the file on the same cadence. Vendors with tiered rates, rebate clauses, or time-bound surcharges warrant more frequent checks because those terms change more often than a flat rate does.

Who should own the price file governance checklist?

No single owner. Rate entry, change authorization, contract reconciliation, and sample testing should sit with different people or roles, so the person loading a rate is never the same person confirming it is correct.

What is the difference between a price file error and a billing error?

A price file error means the internal system record does not match the signed contract. A billing error means the vendor invoice does not match a price file that is otherwise correct. The first is a governance failure to fix internally; the second is a vendor dispute.

Do we need special software to run a price file governance checklist?

No. A spreadsheet with a fixed reconciliation schedule, a named owner per control, and a logged exception record is sufficient to start. What matters is that the checklist runs on a calendar and leaves a record, not what tool holds it.

What size sample should we test against the price file each cycle?

Scale the sample to vendor spend and contract complexity rather than a fixed number. A high-spend vendor with a single flat rate needs a smaller sample than a mid-spend vendor with tiered pricing and multiple surcharge conditions.

What do we do if the checklist finds a rate that was wrong for months?

Correct the file first, then re-price the invoices paid during the period it was wrong to quantify the amount over- or under-billed. Log both the correction and the quantified amount before pursuing a credit memo or dispute with the vendor.

Does a price file governance checklist replace a full contract compliance audit?

No. It is a narrower, recurring control focused only on whether the price file matches the contract. A full compliance audit covers rate cards, volume tiers, rebate clauses, surcharge schedules, and NTE caps across a wider invoice population.

Should the price file checklist cover rebates and surcharges too?

The price file checklist itself should confirm the rate is current. Rebate accrual and surcharge expiration are related but distinct mechanisms, each with its own reconciliation, and are best run as separate, linked checks rather than folded into one.