Wholesale pricing structures, explained
Price books, contract rates, quantity breaks and promotions all resolve onto the same product on the same day. Here is how the layers fit together.
Retail pricing is a number attached to a product. Trade pricing is a question: what does this customer pay for this product, in this quantity, this week. The answer usually comes from several layers, and most of the difficulty in wholesale software is in resolving them in a defined order.
The layers, roughly in order
Most distributors run some subset of these, whether or not they describe them this way:
- A base or list price. What the product costs before anything is applied. Often the retail price, often not used directly by anybody.
- A price book or price level. A whole set of prices attached to a class of customer: standard trade, key account, group. The bulk of accounts sit on one of a handful of these.
- A contract or agreement rate. A negotiated price on specific products for one customer, usually with an expiry date, usually agreed in a meeting nobody wrote down properly.
- A quantity break. Buy more of this line, pay less per unit. Applies per line or per order, and which one matters enormously.
- A promotion. Time-boxed, sometimes supplier-funded, sometimes a free line rather than a discount.
The order of resolution is the whole game
Two systems can hold identical data and produce different prices, because they disagree about precedence. Does a contract rate beat a promotion? Does a quantity break apply on top of a contract rate, or instead of it? Does the group price apply if the specific customer has a rate for only some lines?
There is no universally right answer. There is only the answer your business already uses, currently encoded in the judgement of whoever prices orders. Getting that written down is the real work in any pricing migration, and it is worth doing before you evaluate software rather than during.
The exercise: take three accounts and five products, and write down what each account pays for each product and why. If two people in your business produce different answers, you have found the thing that will slow your implementation.
Eligibility is not the same as price
A distinction that catches people out: what a customer pays and what a customer may buy are separate questions. A price book decides the first. Deciding the second, which lines an account can see and order at all, is a different mechanism, and conflating them means either showing customers products you will not sell them or hiding products you would.
One resolver, everywhere
Whatever the layers, the same code should answer the question everywhere it is asked: on the product tile, in the cart, on the invoice, and when a rep quotes. If pricing is computed in more than one place, the places will disagree, and the disagreement will surface as an invoice query rather than as an error message.