Price-List Versions: Which List Was In Force That Day
A price-variance block is often just the wrong price-list version applied. Learn how effective dates, gross list prices, and net prices decide which list was in force.
A supplier agrees a price list with you in January. In March it issues a new list, effective 1 April, with a 4% increase on a range of fittings. You place an order on 28 March — still under the old list — but the goods ship in April and the invoice applies the new list. The ERP compares the billed price against the net order price it captured at purchase-order time, sees a gap, and blocks the invoice for payment with a price variance. Nothing is fraudulent and no one fat-fingered a figure: a different price-list version was in force than the one the order was priced on. A price-list version is the dated edition of a supplier’s price file, and knowing which one applied on a given day is often the whole answer to a price-variance block.
Definition
A price-list version is a specific, dated edition of a supplier’s price file — the complete set of prices and terms valid between an effective date and an expiry date. One version carries the gross list price (the published catalog figure before discount), the discount group and discount scale that turn it into a net price, any contract price fixed in a framework agreement, and the volume breaks that change the net price by quantity. When a supplier re-issues its list, it is publishing a new version; the part number does not change, but the figure attached to it on a given date does.
Inside an ERP, this is expressed as price and condition records that each carry a validity period: the record that applies is the one whose period contains the relevant date, so two records for the same part can coexist, told apart only by their effective and expiry dates. “The price” is never a single number — it is a number plus the version it belongs to.
| Price-list concept | What it carries | Why the version matters |
|---|---|---|
| Gross list price | Published catalog price before any discount | A re-issued list can move the gross even when the discount is unchanged |
| Net price | Gross minus discount group, discount scale, and volume break | Any input that moves between versions moves the net the invoice is checked against |
| Contract price | A fixed net price in a framework agreement | A contract can lapse or renew between versions, overriding the standard list |
| Effective / expiry date | The validity period of the record | Decides which version is in force on the order date |
Why price-list versions break invoice matching
The order and the invoice are priced from two different versions, and the matching engine knows only one of them. When the PO is created, the ERP reads the version in force on the order date and stores that net price on the line. Weeks later the invoice arrives, billed on whatever version the supplier has since loaded. The check compares the billed price against the stored net order price — and if the list was re-issued in between, the two were never meant to agree. The result is a textbook invoice price variance raised against a figure that was correct under its own version.
Intake makes this worse when a new price file is loaded over the old one instead of beside it. Overwrite the previous version and you destroy the effective dates that prove which list applied, so no one can later show the old price was right. The same failure hides in the net-price inputs: a changed discount group, a dropped volume break, or a lapsed contract can move the net while the gross looks untouched.
| Scenario | Which list was applied | Result |
|---|---|---|
| Order before a price increase, goods shipped after | PO on old version, invoice on new version | Variance block on a legitimately older price |
| New price file loaded over the old one at intake | Old effective dates lost | No evidence of which version was in force on the order date |
| Contract price lapsed between versions | Invoice falls back to standard list | Net price jumps; the block looks like an overcharge |
| Volume break re-tiered in the new version | Same quantity, different break applied | Net price moves with no change to the gross list price |
Messy vs. trusted: what versioning price lists changes
| Before version control | After version control |
|---|---|
| Each new price file overwrites the last; the old list is gone | Every version kept with its effective and expiry dates |
| Invoice checked against whatever list is loaded today | Invoice checked against the version in force on the order date |
| A legitimate price increase looks identical to an overcharge | Version change and overcharge are told apart automatically |
| Net price reverse-engineered by hand to explain a block | Gross, discount, and net known and sourced for every version |
| Analysts clear the same supplier's variances every month | A version mismatch posts clean without a manual exception |
How to keep price-list versions straight across a supplier catalog
- 1Capture effective and expiry dates at intake
Record the validity period on every price file the moment it arrives, before any figure reaches a PO or an invoice check. A version with no dates is unusable as evidence of which list applied.
- 2Version, never overwrite
Load each new price file beside the previous one, not on top of it. Keeping the old version is the only way to prove the older price was correct for an order placed under it.
- 3Diff each new version against the one in force
Compare the incoming list against the current one so you see which gross prices, discounts, and volume breaks moved. A price-list diff surfaces the changed lines before they become blocked invoices, and a margin and markup calculator confirms the net the new gross and discount should produce.
- 4Bind the order to the version in force on its order date
Price each PO from the version whose validity period contains the order date, and stamp that version onto the line so the figure can be traced later.
- 5Reconcile the invoice against that version
Check the billed price against the version the order was bound to, not the latest list, so a genuine increase is separated from an error instead of both landing in the same queue.
Related
Glossary
Invoice Price Variance Explained
Why an ERP raises a price variance, what it compares, and when the gap is a version mismatch rather than an error.
Glossary
What Is Unit of Measure (UOM)?
The other half of a correct price check — the unit the price is measured against, and the conversion factors behind it.
Glossary
What Is Data Normalization?
Turning messy supplier price files into consistent, comparable records so versions can be diffed at all.
Tool
Price List Diff
Compare two versions of a supplier price file and see exactly which prices, discounts, and breaks changed.
Tool
Margin and Markup Calculator
Recompute the net price a gross list price and discount should produce before you trust a new version.
Playbook
Map Supplier Attributes to Your Schema
Map supplier price-file fields, dates, and discounts onto one canonical model so versions stay comparable.
FAQ
What is a price-list version?
A price-list version is a dated edition of a supplier’s price file: the gross list prices, net prices, contract prices, discounts, and volume breaks valid between an effective and an expiry date. The same part can carry one price in January and another in April, so the version, not just the price, tells you which figure applied to an order.
Why does a new price list cause an invoice price variance?
The order captured the net price from the version in force on the order date; the invoice was billed on a later one. The ERP compares the two, sees them diverge, and raises a price variance — even though each was correct under its own version. It is a version mismatch, not a billing error, and widening the tolerance only hides it.
What is the difference between gross list price, net price, and contract price?
The gross list price is the published catalog price before any discount. The net price is what you pay after the discount group, scale, and volume break are applied to it. A contract price is a net price fixed in a framework agreement that overrides the standard list. All three live inside a version, so changing the version can move the net.
How do effective dates decide which price list applies to an order?
Price and condition records carry a validity period, and the one that applies is whichever period contains the relevant date. For a purchase that is normally the order date, not the invoice date, so an order placed before a new list takes effect should bill on the old list. Overwriting the old version erases the proof of which list applied.
Can I fix a version mismatch by widening the price tolerance?
No. Widening the tolerance releases the invoice in front of you and silently accepts real price errors on every one after it, because it cannot tell a version change from an overcharge. Keep both versions instead, bind each order to the version in force on its order date, and reconcile against that version rather than the latest.
How does Claro help with price-list versions and invoice reconciliation?
Claro ingests every supplier price file as a dated version, preserves its effective and expiry dates instead of overwriting the previous list, and resolves each line to one trusted product record so the gross, discount, and net price are known for every version. At invoice time it reconciles each line against the version in force on the order date, with a source trace — separating a genuine version change from an overcharge automatically.
REVIEW-NOTES
- Conceptual/commercial entry — no ERP message numbers used. Per the brief appendix, no SAP/ERP message number exists for the price-list-version topic, so none is cited. The entry speaks generally about price/condition records carrying validity periods (effective/expiry dates) without attributing a message class or number. No M8/MM/RU numbers appear anywhere in this file.
- No invented statistics. The “4%” increase and the January/March/April dates in the intro are an illustrative scenario, not a cited figure; they describe a generic situation rather than claiming a measured outcome.
- Intra-cluster inline links deferred. The glossary-guide pairing and hub links to not-yet-existing
siblings (e.g.
tolerance-key,discount-group,net-net-price) are omitted from inline prose to keep the readiness audit green. All inline markdown links point only to pages confirmed present on disk (glossary/invoice-price-variance,glossary/unit-of-measure,glossary/data-normalization,tools/price-list-diff,tools/margin-markup-calculator,playbooks/map-supplier-attributes-to-schema). Add sibling cross-links in the final wiring commit once those pages ship.
Claro
See how Claro handles this in production
This concept is one piece of keeping a catalog trusted. See how Claro resolves identity, enriches missing attributes, and validates every update before it reaches your PIM or ERP.
Learn more