Price models in B2B
A B2B company runs four or five pricing models at once, layered over each other, usually with different histories. This article names them, says what each is good for, and shows how each maps onto price lists and entries.
The five models
| Model | The commercial question it answers | Typical lifetime |
|---|---|---|
| List price | What does this cost anyone who has not negotiated? | Reviewed yearly |
| Contract price | What did we agree with this specific customer? | 12–36 months |
| Scale price | How much cheaper is it per piece if you take more? | Follows the list price |
| Project price | What did we quote for this one job? | Weeks to months |
| On request | Why can we not publish a number at all? | Permanent, per article |
Most Mittelstand suppliers run all five. The trouble starts when they are all implemented the same way: as a number typed onto an order line by whoever is handling it.
List price
The published price. It is the reference point for everything else: discounts are expressed against it, sales conversations start from it, and it is what a new customer sees before any relationship exists.
Here: entries on your default price list, one per SKU, at quantity 1.
A list price should be a decision. If your "list price" is in fact the price of your largest customer plus a margin, every discount conversation you have starts from the wrong anchor.
Contract price
The negotiated price for one account, usually part of a framework agreement (Rahmenvertrag) covering an agreed assortment for an agreed term. The buyer's procurement department has this price in their ERP and expects your shop to match it exactly. It is checked.
Here: a separate price list bound to that organization, holding entries only for the articles the agreement covers. Everything not in the agreement falls through to the list price automatically. That is the behaviour you want, and the reason you do not copy your whole catalogue into a customer list.
Scale price (Staffelpreis)
Price breaks by quantity: €19.90 from 1, €17.50 from 10, €14.00 from 50. It does two jobs. It rewards larger orders, and it prices the fact that picking, packing and invoicing one line of 50 costs you far less than fifty lines of one.
Here: several entries for the same item in the same list, differing only in From quantity. The highest rung at or below the ordered quantity wins.
Scale prices are one of the highest-return things you can put in a B2B shop, because they work without a salesperson. A buyer who sees "from 50: €14.00" on the product page frequently changes their own order quantity. See Scale and volume prices.
Project price
A price quoted for a specific job, valid for a specific window, often for a bundle of articles bought together once. It is not a contract price, because it does not survive the project, and treating it as one is how a one-off concession becomes permanent.
Here: a price list bound to the account with a hard Valid until date, or entries with their own validity window. The point is that it expires by itself.
If the negotiation is still live and no price exists yet, that is a quote rather than a price list; see Quotes and negotiation.
On request
Some articles cannot carry a published number: made-to-order assemblies, spare parts whose price depends on the machine and its age, articles priced from a daily raw-material index, and anything where the answer is genuinely "it depends".
Here: an entry with the type On request. It is a state of its own, distinct from a missing price: the price call answers "on request" rather than an amount, so your storefront can show an enquiry action in place of a price while the article stays findable in the catalogue.
Hiding the article instead is worse. Buyers search for what they need; an article they cannot find is an article they order elsewhere.
Net pricing versus discounts
One more distinction matters more than it looks: whether your customer-specific prices are stored as net prices or as discounts off list.
| Net price per customer | Discount percentage off list | |
|---|---|---|
| What is stored | The final amount, e.g. €16.20 | "22 % off list" |
| A list price rise | Does not move the customer's price | Moves the customer's price automatically |
| What the buyer sees | The exact agreed number | A calculated number |
| Auditability | Trivial: the number is the agreement | Requires the list price of that day |
| Effort at renegotiation | Re-import the agreed articles | Change one percentage |
The Revenue Cloud stores net prices. A customer price list holds the agreed amounts, and a change to your list prices does not move them.
That is the right default for B2B contracts, where the agreement is usually a price rather than a percentage, but it has a consequence to plan for. When you raise list prices, contract customers do not move with you. Their prices stay where they are until you deliberately update them, which is a commercial decision you now have to make consciously rather than one that happens by arithmetic. Put it in the annual price round; see Adjust a whole price list.
Choosing between them
A rough decision guide for a new pricing requirement:
| The requirement sounds like… | Use |
|---|---|
| "Everyone pays this" | Entries on the default list |
| "Müller pays this for these 300 articles" | A list bound to the organization |
| "Cheaper from 25 pieces" | Extra tiers on the entries you already have |
| "Only until the end of March" | Validity window on the entries or the list |
| "Only for people who are logged in" | Logged-in buyers only on the list |
| "Only in Switzerland" | A CHF list, assigned to the Swiss market |
| "Only in the punchout catalogue" | A list bound to that channel |
| "We cannot publish a price for this" | An On request entry |
| "One buyer at the customer gets a better price" | A list bound to the contact |
If a requirement does not fit any row of that table, it is usually a checkout discount, a payment-terms question or a shipping cost rather than a pricing rule. Do not bend the price model to hold it.
What not to model as a price
Three things that regularly get pushed into pricing and belong elsewhere:
- Payment discounts (Skonto) are payment terms, not prices. They belong on the account; see Payment terms.
- Freight, minimum-quantity and small-order surcharges are order-level costs. A per-SKU surcharge entry that exists to model a €7.50 small-order fee will be wrong the first time somebody orders two lines.
- Credit limits and delivery blocks are account states. They decide whether an order may happen, not what it costs. See Organizations.
Next
- Where your prices come from — ERP as the system of record, and where margin leaks.
- Design your price lists — the structure that carries all five models.