Why B2B pricing is harder than it looks
Ask a sales manager how prices work and the answer is short: customers have a price list, and some have special deals. Ask the person who raises invoices and a different picture appears. There are four price lists, sixty contracts, quantity breaks on some lines, a discount for one buying group, a promotion that excludes contract customers and a handful of prices that exist only in an email. The logic lives partly in the ERP and partly in people's heads.
An online store has no head. Every rule must be explicit, and the store must show the same price the invoice will carry. A customer who orders at one price and is billed at another loses confidence in ordering online, and usually goes back to the phone.
List every kind of pricing rule
| Kind of rule | Example | Planning question |
|---|---|---|
| List price | The standard price before any agreement | Is it shown to anyone, or only used as a base? |
| Price list by group | Trade, reseller and key account lists | How is a customer assigned, and can they be on more than one? |
| Contract price | A fixed price for one customer on specific items, valid for a period | Start and end dates, and what applies when it expires |
| Discount by category | A percentage off a product family for a customer or group | Does it stack with other discounts? |
| Quantity break | A lower unit price above a threshold | Per line, per product family or per order? |
| Promotion | A temporary offer | Do contract customers receive it? |
| Surcharges | Cutting, small-order or special delivery charges | When they apply, and how they are shown |
| Currency and tax | Prices in the customer's currency, shown excluding tax | Fixed prices per currency, or converted? |
Collect these from the ERP configuration, from contracts and from the people who correct invoices. The last group knows the exceptions nobody else remembers.
Decide which rule wins
When a customer on the trade list also has a contract price for an item that is on promotion and is buying enough to reach a quantity break, what do they pay? There must be one answer, written down and agreed by sales and finance.
- 01
Choose the principle
The two common ones are most specific wins, where a contract price beats a group list, and lowest price wins, where the customer always receives the best available price. They give different results.
- 02
State what stacks
Does a quantity break apply on top of a contract price? Does a promotion apply on top of a group discount? Say yes or no for each pair.
- 03
Handle dates
Expired contracts, future-dated price changes and orders placed before a change but delivered after it.
- 04
Handle missing prices
An item with no price for this customer: fall back to list price, hide the item or show price on request.
- 05
Write test cases
A table of real customers and items with the expected price and the reason. This becomes the acceptance test.
If the ERP already calculates prices on invoices, its logic is the answer, whatever anyone believes the policy to be. Find out what it does before designing anything, since the store must match it.
Decide where the price is calculated
| Approach | How it works | Strength | Weakness |
|---|---|---|---|
| ERP calculates live | The store asks the ERP for the price when a page or basket is shown | Always matches the invoice | Depends on ERP speed and availability |
| Prices synced to the store | Price lists and contract prices are copied to the store on a schedule | Fast pages, works if the ERP is down | Rules must fit what the store can express. Risk of drift |
| Hybrid | Synced prices for browsing, confirmed live in the basket or at order | Fast, and correct where it counts | More to build, and a price can change between page and basket |
| Store is the authority | Prices are maintained in the store and sent to the ERP | Simple when there is no ERP pricing | Rare where an ERP invoices |
The choice depends on how complex your rules are and how quickly the ERP answers. A few group price lists sync easily. Hundreds of contracts with stacked breaks usually need the ERP to calculate, with caching so that pages stay quick. Whichever you choose, the price on the order confirmation must be the price on the invoice. Our comparison of real-time and scheduled data sync sets out the trade-off.
Plan who sees and can buy which products
- 01
Does every customer see the whole range?
Why it mattersSome agreements cover a defined assortment. Showing items a customer cannot buy generates calls.
- 02
Are some products restricted?
Why it mattersBy region, licence, certification or exclusive distribution. The restriction must hold in search and in direct links, not only in menus.
- 03
Do units and pack sizes differ?
Why it mattersEach, box, pallet. A customer may be allowed to buy singles where others must buy boxes.
- 04
Do customers use their own part numbers?
Why it mattersStoring a customer's codes against your products lets them search and order in their own terms.
- 05
Are there customer-specific products?
Why it mattersItems made or stocked for one customer should appear for that customer only.
- 06
What do signed-out visitors and search engines see?
Why it mattersThe public catalogue, without restricted items and without negotiated prices.
A worked example
Pricing rules for a packaging distributor
This example is invented to show precedence being settled. A packaging distributor is moving its trade customers to online ordering.
- Rules foundThree group price lists, 85 customer contracts, quantity breaks by pallet on cartons and a quarterly promotion. Finance also applies a small-order charge that sales had not mentioned.
- PrecedenceMost specific wins: a contract price beats the group list. Quantity breaks apply to list and group prices but not to contract prices. Promotions exclude contract items. The small-order charge applies to everyone.
- CalculationThe ERP calculates. The store shows synced group prices while browsing and asks the ERP for the confirmed price whenever the basket changes.
- CataloguePrinted packaging made for specific customers is visible only to those customers. Food-grade lines are restricted to accounts with the relevant approval on file.
- TestForty past invoices from twelve customers are re-entered as baskets. Thirty-seven match. The three that differ all involve a contract that expired mid-year and was still being honoured by hand.
The three mismatches lead to a decision that expired contracts fall back to the group list, with a warning to the account manager a month before expiry. A rule that existed only as a habit is now written and automated.
Keep it fast, and test with real invoices
Sound practice
- Prices cached per customer and refreshed when rules change
- Category pages that stay quick with customer prices shown
- A regression set of real invoices rerun after every pricing change
- Price shown with its basis, such as contract or quantity break
- Account managers can view the store exactly as their customer does
Sources of trouble
- A live ERP call for every product on a listing page
- Rules reimplemented in the store by guesswork
- Testing with one demonstration customer
- Prices that differ between listing, basket and confirmation
- No alert when the price sync fails
Before launch, have each account manager check the prices of their own customers. They will find errors that no test script anticipates, and their confidence in the store decides whether they recommend it.
Pricing and catalogue checklist
Account based pricing and catalogue checklist
0 of 11 checkedWhat to do next
Take ten recent invoices from different kinds of customer and, for each line, write down why the price is what it is. Where nobody can explain a price, you have found a rule that needs deciding before it can be put online.
Pricing is one part of the wider picture in our B2B ecommerce requirements checklist. Our B2B ecommerce development page explains how we build stores around ERP pricing, and you can send us your rules.
Common questions
Should prices be calculated by the store or the ERP?
Whichever system produces the invoice should be the authority, which is normally the ERP. Simple price lists can be copied to the store safely. Complex rules with contracts, breaks and stacking are best calculated by the ERP, live or with caching, so that the online price and the invoiced price cannot diverge.
How many price lists can a B2B store handle?
Platforms differ widely, and the number of lists is rarely the real limit. The harder questions are whether a customer can have individual contract prices on top of a list, whether quantity breaks and discounts combine the way yours do, and how quickly pages load with customer-specific prices. Test your most complex customer on a trial.
What happens when a contract price expires?
That must be decided, because a store will apply whatever rule it is given. Common choices are falling back to the customer's group list, keeping the old price until renewed, or blocking the item pending a new agreement. Whichever applies, warn the account manager before expiry and show the customer the new price before they order.
Can we hide certain products from certain customers?
Yes, and the restriction must be enforced everywhere: menus, search results, direct links, quick order forms and reorders of past purchases. It is easy to hide an item from navigation while leaving it reachable by its address. Ask for restricted visibility to be tested specifically, by trying to reach and order hidden products.
How do we test that online prices are correct?
Rebuild real past invoices as baskets for the same customers and compare line by line. Include customers of every type, items with breaks, expired and current contracts and active promotions. Keep the set and rerun it whenever pricing rules or the integration change. Then have account managers check their own customers before launch.
