Articles
Why your price list is wrong by the time it reaches the counter
Five copies of one price and one authority: how a change propagates, the four routes a stale price takes, and what the invoice must keep.
- pricing
- erp
- operations
A price is wrong at the counter because five copies of it exist and only one is allowed to be right. The change goes into the system; the printed sheet, the saved quote, the copy of last month's invoice and the figure in a salesperson's memory keep the old one. What reaches the customer is whichever copy is closest to hand, and that is rarely the copy that will be invoiced.
Where does the price actually live?
In five places, each with a different owner: the price table in the system; the sheet taped to the counter; a message in a WhatsApp group; the head of the salesperson who has sold these items for years; and the invoice itself, either the template it prints from or the last copy kept.
Only one decides what the customer is charged, and it need not be the file called "the price list": authority is whatever the invoice is generated from. That sounds obvious until the invoice comes out of the accounting package while the price table lives in the shop application — two systems, two prices, and the one that reaches the customer wins by accident.
| Copy of the price | Who reads it | Cost when it is stale |
|---|---|---|
| System price table | Everyone, if it prints the invoice | None, it is the authority |
| Printed sheet | The counter | A sale at an old price |
| Saved quote | The customer | A dispute you lose on paper |
| Old invoice | Whoever copies it | A price from an unknown month |
| Memory | The fastest salesperson | A price nobody can trace |
How does a change actually propagate?
Follow one item from the supplier's increase to the counter. Somebody decides the new price, then the work begins, because typing the figure is the smallest part of it. The sheet must be reprinted, the salespeople told, and told again when the message scrolls away. Open quotes must be reissued or allowed to expire. The online shop has its own field, updated by somebody else.
Most businesses get the typing right and lose everything after it: the change happened, the propagation did not.
Underneath sits the date. A price change is rarely effective "now": it starts on the first of the month, or the next delivery, or the moment old stock runs out. A field holding one value cannot say that, so the change lands on the day somebody remembers — a different day per salesperson, and two prices for one item in the same week.
Which routes does a stale price take to the customer?
Four, and each needs a different fix.
The printed sheet. It carries no date, so nobody can tell whether it is current. It is defended by whoever printed it, which makes it expensive to correct in front of a customer.
The saved quote. A quote written three weeks ago and accepted today carries the price of the day it was written. Without an expiry it is a standing offer at last month's price — and honouring it is correct, which is why it must be priced in advance.
The copy of an old invoice. "Give me the same as last time" is a fair request, and the easy answer is to duplicate the old invoice, prices included. The items were what was asked for; the prices came along by accident.
The remembered number. The most experienced person is the most dangerous source: usually right, occasionally a month behind, and never checked for exactly that reason.
What is the difference between a price list and a price rule?
A price list is one row per item. A price rule answers what the invoice asks: for this customer, this quantity, this delivery, on this date, what is the price?
Three dimensions a list cannot hold. The customer: an agreed price for one builder, which belongs to the account, not the item. The quantity: a price per pallet that differs from the price per unit, so one item has several correct prices on one day. The delivery: whether the figure includes transport to the wilaya or stops at the warehouse gate — the commonest argument on a delivered order, and not a price until attached to a condition.
With only the list, every non-standard sale becomes a figure typed by hand. Not necessarily wrong that day, but unexplainable three months later — and then the argument is about who agreed to the price, not about the price.
What must the invoice keep so a past price can be explained?
Per line: the price used, the rule that produced it, any discount and who approved it, the cost at the time, and the date the rule took effect. Not the current price, but the price as of the invoice date.
A table storing only the current value rewrites history: reopen a March invoice, reprint it, the total changes. It is a trust problem before an accounting one, and it is the discipline the versioning and provenance rules published by the W3C ask of any dataset — keep the previous value and say when each one applied.
How do you stop the drift this month?
- Change one price and walk to the counter. Note where the old figure still appears.
- Name the copy the invoice is generated from. That copy is the authority; write it down.
- Stop printing prices. Print codes and a lookup, or a sheet stating the date it was valid.
- Give every quote an expiry date, and reissue rather than extend.
- Move each hand-typed price into a rule tied to a customer, a quantity or a delivery condition, with an approver.
- Version the price table with a valid-from date per row instead of overwriting.
- Record on the invoice line which rule produced the price, and check a sample monthly.
Where this goes wrong
Two authorities, both printing invoices. The shop system prices the order, the accounting package prices the invoice, and the gap surfaces as a rounding error nobody investigates until a customer does.
The change announced in a group chat. No date, no item list, no proof anyone read it. Half the team applies it, which is worse than none.
Fixing it with credit notes. Correcting each order afterwards keeps the sale and hides the drift as an accounting cost, so the price is never fixed at the source.
What this does not cover
This is not about what the price should be; that is a commercial decision. It does not cover tax treatment, multi-currency pricing, or indexed contracts where the price follows a supplier's published rate — each needs a rule about which date the rate is taken from. It assumes one authority per invoice: where a second document with its own prices is legally required, the two need a check, not attention.
We build the price rule into the system that prints the invoice, so a change happens once and an old invoice can still explain itself.
Services in this article
Articles
Related articles.
Why your stock count never matches the system
Counts drift because two places accept stock movements and neither owns the number. What to record, what to count, and what to fix first.
- inventory
- erp
- operations
Two systems, one customer: who owns the record
When two systems both accept edits to the same customer, both look right and neither is. How to assign an owner per record, and what a sync must answer.
- integration
- data
- operations
One stock number across several shops: what actually breaks
With a second shop, the transfer becomes the weak point: an item sold on one side, bought on the other, owned by nobody in the van. What to model first.
- inventory
- logistics
- multi-site
Start a project
Have something to build?
One short brief is enough. You get a written scope and a fixed quote before anything starts.
