Pricebooks Explained: Customer-Specific Pricing at Scale
Ask a wholesaler what a product costs, and you will not get a number. You will get a question back: for whom?
That answer is the whole of B2B pricing. The pallet that leaves the warehouse at one price for a national account leaves at another for a regional independent who has been buying for fifteen years, another again for a new customer on introductory terms, and another still if the order crosses a volume threshold that triggers a contracted discount. Every one of those prices is right. Every one of them was agreed upon by a person, recorded somewhere, and is expected to appear correctly, the moment the buyer logs in.
This is where customer-specific pricing in eCommerce either works or quietly fails. And it is the single most common reason a B2B portal launches, underperforms, and gets abandoned by the customers it was built for.
Key takeaways
- In B2B, price is not a property of the product. It is a property of the relationship. For example, the same stock can carry five different prices across five accounts, all of which are correct.
- A Pricebook is the structure that holds those agreements: a set of rules defining what a specific customer or group of customers pays for a specific product under specific conditions.
- Most ecommerce platforms were built for one public price per product. Bolting on customer-specific pricing afterwards is where portals leak
What Is a Pricebook?
A Pricebook is a defined set of pricing rules that determines what a specific customer, or group of customers, pays for specific products.
Think of it as the digital version of the pricing agreement your commercial team already negotiates. Instead of that agreement living in a signed PDF, a spreadsheet on a sales director’s laptop, and the memory of the rep who negotiated it, the Pricebook makes it a live, enforceable structure that your storefront reads in real time.
A single Pricebook can hold:
- A base list price for each product.
- Contract pricing for a named account, agreed and fixed for a term.
- Tiered pricing, where the unit price steps down as quantity rises (buy 10, pay one rate; buy 20, pay another).
- Group pricing is applied to a segment, such as a buying group, franchise network, or customer category.
- Promotional overlays, time-boxed and applied on top of the underlying agreement.
- Currency and region rules for cross-border buyers.
These are not alternatives. They stack. A buyer’s final price is the resolved output of several rules applied in order, and resolving that correctly, instantly, for every buyer on every page, is the actual technical problem.
Why Does Customer-Specific Pricing Break Most eCommerce Platforms?
Consumer ecommerce platforms were built on a clean assumption: a product has a price, that price is public, and everyone sees the same one. Everything downstream, the catalogue, the search index, the caching layer, the cart, was designed around that assumption.
B2B violates it on the first customer.
When a platform built for one public price is asked to serve thousands of account-specific prices, three things tend to go wrong.
Price resolves too late. Many platforms show a list price while browsing and only calculate the buyer’s real price at the cart or checkout. The buyer sees a number that is not theirs, does the mental arithmetic, and stops trusting the channel. Trust, once lost on price, does not come back easily.
Price resolves inconsistently. Tiered discounts apply in the cart but not on the product page. A promotion overrides a contract rate that it should have respected. An account with a custom agreement sees no price at all. Each inconsistency generates a call to a rep, which is precisely the cost the portal was meant to remove.
Price does not resolve at all under load. Pricing logic that lives in the ERP (Enterprise Resource Planning, the back-office system that owns stock, pricing, and financial data) and is queried live on every page view will slow the storefront as concurrent buyers rise. Performance and pricing accuracy end up in direct competition.
The result is a portal that technically exists and commercially does not. Buyers revert to phone and email, and the sales desk absorbs the work again.
What Does Correct Pricing Actually Require?
For customer-specific pricing to work at scale, four things have to be true at once.
The buyer’s price appears before the cart.
Their contracted price, including their tier and any active promotion, must be visible while browsing, on the product listing, on the product page, and in search results. Not at checkout. A buyer who cannot see their own price while browsing is not really shopping; they are guessing.
Pricing respects the account structure, not just the login.
In B2B, the person clicking is rarely the entity that holds the agreement. A purchasing assistant at a subsidiary branch buys under the terms negotiated by the parent group. This requires an Account Hierarchy, the structure mapping parent companies, subsidiaries, branches, and individual buyers, so pricing inherits down the tree while permissions and approvals route back up it. Get the hierarchy wrong, and the right person sees the wrong price. Apex B2B handles this through company roles and account hierarchies, so an end user buyer sees group-contracted rates without a rep intervening.
Rules resolve in a defined, auditable order.
When a contract rate, a volume tier, and a promotion all apply to the same line, something must decide which wins, or how they combine. That order needs to be explicit, consistent, and inspectable. Finance teams should be able to answer “why did this order price at this figure?” without a forensic exercise.
The commerce layer resolves it, not the ERP under load.
The ERP remains the system of record for pricing agreements. But the resolution of a buyer’s price on a page view should happen at the commerce layer, synced from the ERP, so that performance stays fast and the back office is not fielding thousands of read requests. This is the practical difference between a storefront that stays open at 9 am on a Monday and one that does not.
Why It Matters Commercially: Two Views
Customer-specific pricing is usually specified by IT, but its consequences land on two other desks.
For sales: fewer price calls, faster orders
Every “what’s my price?” call is a rep interrupted, an order delayed, and a buyer reminded that the digital channel does not work. When Pricebooks resolve correctly, reps stop being a lookup service and go back to selling. Buyers, meanwhile, increasingly expect to complete purchases without a rep at all: in a Gartner survey of 646 B2B buyers fielded August to September 2025, 67% said they prefer a rep-free experience. Pricing that only a rep can confirm makes a rep-free experience impossible.
Correct pricing also removes an underrated friction: the buyer who does trust the price places bigger, more frequent orders, because reordering stops requiring a conversation.
For finance: margin protection and predictability
Every pricing error has a cost, and the cost is rarely just the discount. An order that goes through at the wrong price generates a credit note, a reconciliation, a conversation, and a small deposit of doubt in the customer relationship. Multiply that by order volume, and it stops being an operational annoyance and becomes margin leakage.
Structured Pricebooks give finance and operations leaders something spreadsheets and rep memory cannot: enforcement. The agreed price is the price that transacts. Discount authority is bounded by rules rather than by whoever is closing the deal. And because the rules are explicit, the answer to “what are we actually selling this at, across all accounts?” is a report rather than an investigation.
Pricing Approaches Compared
Approach | How the price is set | Where it breaks |
Single public price | One price per product, visible to all | Cannot express contracts, tiers, or negotiated terms. Unusable for real B2B. |
Spreadsheets and rep memory | Agreements held offline, applied manually | No enforcement, no auditability, no self-service. Every order needs a person. |
ERP-only, queried live | ERP resolves the price on each page request | Accurate but slow under load. Storefront speed becomes hostage to the back office. |
Bolt-on pricing app | Third-party layer patched onto a consumer platform | Resolves late, applies inconsistently, and adds recurring cost and integration fragility. |
Native Pricebooks (Apex B2B) | Structured rules synced from the ERP, resolved at the commerce layer | Buyer sees their price while browsing; rules are auditable; performance stays fast. |
How Apex B2B Handles Pricebooks
Apex B2B treats customer-specific pricing as core architecture, not an add-on. Pricebooks are native to the platform, which means:
- Contract, tiered, group, and promotional pricing are all expressible in one structure, with a defined resolution order.
- Prices resolve at the point of browsing, so a buyer sees their own price on the listing page, not a placeholder they have to correct at checkout.
- Pricing is inherited through the Account Hierarchy, so subsidiaries, branches/depots, and individual buyers transact on the terms their parent group agreed to.
- Rules sync from your ERP through pre-built connectors, so the agreement lives where finance expects it to live, while resolution happens fast at the commerce layer.
- Nothing is bolted on. No third-party pricing app, no middleware, no recurring per-rule licence creeping onto the invoice.
The practical effect is unremarkable, which is the point: a buyer logs in, sees their price, and orders. No call. No correction. No credit note next month.
Want to see your own pricing structure modelled in Apex B2B? Book a demo.
Getting Your Pricing Ready to Move Online
Before a Pricebook can be built, most distributors discover their pricing is less structured than they believed. That discovery is normal and worth doing early.
- Find every agreement. Contracts in PDFs, tiers in spreadsheets, informal discounts held in a rep’s head. All of it has to become explicit.
- Decide the resolution order. When a contract rate, a volume break, and a promotion collide, what wins? Answer it once, deliberately, rather than case by case.
- Map the account structure. Which entities hold agreements, and which buyers inherit them? This is where most surprises surface.
- Set discount boundaries. What can a rep approve alone, and what needs sign-off? Encode it rather than trusting it.
- Audit what you are actually charging. Compare agreed rates against transacted rates for the last quarter. The gap is usually instructive.
None of this requires replacing your ERP or pausing trading. It requires making explicit what the business already knows implicitly.
The Bottom Line
In B2B, pricing is not a number on a product. It is the accumulated record of every relationship the business has built, and buyers expect to see their side of that record the moment they log in.
Platforms that treat customer-specific pricing as an afterthought push that expectation back onto your sales desk. Platforms that treat it as core architecture let the desk get on with selling.
Apex B2B handles contract pricing, tiered pricing, group rates, promotions, and account hierarchies natively, synced from your ERP and resolved where your buyers actually shop. Book a demo, and we will model your pricing structure against it.
Frequently Asked Questions
1. What is a Pricebook in B2B ecommerce?
A Pricebook is a structured set of pricing rules defining what a specific customer, or group of customers, pays for specific products. It can hold contract pricing, tiered (volume-based) pricing, group pricing, promotional overlays, and currency rules. It is the digital form of the pricing agreements a commercial team already negotiates, made live and enforceable on the storefront.
2. What is the difference between tiered pricing and contract pricing?
Tiered pricing sets the unit price according to quantity: the more a buyer orders, the lower the unit rate. Contract pricing fixes agreed rates for a named account for a defined term, regardless of quantity. Most B2B relationships use both at once, with the contract setting the baseline and tiers applying on top.
3. Why does my B2B portal show the wrong price to customers?
Usually, because the platform resolves the price too late or inconsistently. Many systems display a public list price while browsing and only apply the buyer’s contract and tier at the cart or checkout. Others fail to inherit pricing through the account hierarchy, so a subsidiary buyer does not receive the parent group’s terms. Both cause buyers to stop trusting the channel and call a rep instead.
4. Can customer-specific pricing work without slowing the storefront?
Yes, provided the price is resolved at the commerce layer rather than queried live from the ERP on every page view. The ERP stays the system of record for agreements; the commerce platform syncs those rules and resolves each buyer’s price quickly at the point of browsing.
5. How does pricing work for a customer with multiple branches/depots or subsidiaries?
Through an Account Hierarchy, the structure maps parent companies, subsidiaries, branches/depots, and individual buyers. Pricing agreed at the parent level is inherited down to the buyers beneath it, while ordering permissions and approvals route back up. This lets an end-user purchaser transact on group-negotiated terms without involving a sales rep.
