A wholesaler can carry the same item at three hundred different prices. One customer gets a price from a contract negotiated five years ago. Another gets a price based on the volume they pick up each month. A third gets a time-limited campaign that sits on top of everything else. All of it has to be shown correctly, for the right customer, at every page view.
According to Litium's Nordic Digital Commerce in B2B 2026 report, customer-specific pricing is the single biggest reason B2B companies abandon platforms built for B2C. It is not the product features that are missing. It is the pricing and contract logic that does not hold up.
This guide walks through how customer-specific pricing actually works in B2B e-commerce: which pricing models are common, where the price is calculated, what real time means in practice, and what you need to demand when evaluating platforms.
1. The five pricing models in B2B e-commerce
A B2B business rarely relies on a single pricing model. Most wholesalers and manufacturers run several in parallel, and the platform has to be able to determine which one applies to which customer at any given moment.
List price is the starting point. The published price for a product, often visible to logged-in customers without a specific contract or to new customers without negotiated terms.
Customer group price is based on segmentation. Resellers, distributors, key accounts and end customers can each have their own price level that applies to the full assortment or parts of it. It is a pragmatic way of handling customers with similar terms without writing individual contracts.
Contract price is the individual price negotiated with a specific customer. It almost always lives in the ERP and is pulled into the e-commerce platform when the price needs to be shown. For many wholesalers, this is the majority of pricing in practice.
Volume discount and tier pricing give a lower unit price the more units the customer adds to the cart. It can be linear with a percentage scale or threshold-based with concrete steps.
Campaign price is layered on top of other pricing rules for a limited time. Here, prioritisation becomes critical. Should the campaign override the contract price, or only the list price? This is a rule that has to be explicitly defined in the system, not assumed.
Bevent Rasch doubled their order intake after connecting their e-commerce directly to the ERP pricing logic. Correct price for the right customer, from the first page view, with no manual handling. It is not a separate add-on feature but the foundation of how B2B e-commerce works at all.
2. Where the price is calculated: three architectures
A central question is where the price is actually calculated. There are three common setups, each with its own trade-off.
In the first, all logic lives in the ERP, for example Monitor, Jeeves, Business Central or SAP. The e-commerce platform makes an API call every time a price needs to be shown and gets a number back. It gives maximum control and ensures the same price applies in the webshop, in the rep's order entry and on the customer's invoice. It also places high demands on the ERP's API performance and on smart caching strategies in e-commerce.
In the second, prices are handled in the e-commerce platform with rules and price lists synchronised from the ERP. Faster response times for the customer, but it assumes the pricing logic is correctly mirrored in both systems and that synchronisation actually captures every change.
In the third, a separate pricing engine is used as part of a headless architecture. Both the ERP and the e-commerce platform query the same pricing engine, which makes it easier to scale into other channels like a sales app, customer portal and partner integration without duplicating the pricing logic. This model becomes more common when companies expand into multiple markets and sales channels.
The important thing is to know which model you have, who owns each layer and what happens when a rule changes. Not having that answer is the most common source of pricing conflicts between web and invoice.
3. Real time or batch: the difference your customer feels
The single biggest architectural question in customer-specific pricing is whether prices are pulled in real time or via scheduled exports.
Batch synchronisation, where prices are exported from the ERP once per night or per hour, was an acceptable solution ten years ago. Today it creates concrete business problems for B2B:
- A customer negotiates a new price with the sales rep at 09:30. The webshop shows the old price until the next batch runs at 03:00, even if the customer logs in the same afternoon.
- A campaign ends at 16:00. The webshop keeps offering the campaign price through the night.
- A change in credit limit or customer group takes hours to take effect, which means the wrong customers see the wrong price list.
Real-time integration means that every page view for a logged-in customer pulls the current price via API directly from the ERP or pricing engine. It is a higher technical bar to meet, but it is also what makes contract customers trust the numbers they see.
Apex Stainless Fasteners has 63 percent of their B2B customers logged in daily to check prices and stock status on their own. That number depends on customers trusting the data. If they do not trust the price, they do not log in. They call the rep instead, and the whole point of having a digital channel disappears.
Ask the platform vendor and the ERP vendor directly: is it real time via API calls, or scheduled exports? That answer tells you more about the system's B2B maturity than feature lists do.
4. Performance and caching of customer-unique prices
There is a trap here that rarely comes up in the evaluation phase. Customer-specific prices cannot be cached the same way as ordinary product data.
For a public product page, it is enough to calculate the price once and serve it to all visitors. For a logged-in B2B customer, the price is a function of that specific customer's contract, customer group, currency and any active campaigns. Every page load can, in the worst case, require an external price call per product, and a category page with a hundred items can trigger a hundred separate calls.
This is one of the most common reasons B2B sites become noticeably slower after login. The solution lies in a combination of techniques:
- Cache per customer and price configuration with clear invalidation on contract change
- Bulk calls that retrieve prices for multiple products in a single API call instead of one per product
- Asynchronous updates where the price is shown directly from cache and updated in the background on change
- Pre-warming of price lists for customers with high recurring traffic patterns
The platform needs to be built for this. It can be bolted on afterwards, but that becomes expensive and brittle. Litium's B2B e-commerce platform supports customer-unique pricing through price lists linked to organisations as a core capability. How caching, bulk calls and asynchronous updates are implemented in your case is decided together with the implementation partner, based on your traffic patterns and call volumes to the ERP.
5. Multiple markets, currencies and tax rules
As soon as a B2B business expands beyond its home market, the complexity of pricing multiplies. The same customer can have different prices depending on which country the delivery goes to, which sales entity invoices, and which currency the contract was written in.
The platform needs to handle:
- Separate price lists per market and currency without duplicating the entire product registry
- Automatic currency handling with the option to lock contract prices in a specific currency regardless of the exchange rate
- Tax rules per country, including EU OSS rules for cross-border B2B trade
- Multiple legal entities in the same platform instance, so a group can sell from different sales entities without separate installations
- Customers who buy from several markets with different pricing structures per market
TMHI chose Litium specifically for their globalisation. When a forklift order has to flow through several markets, currencies and sales entities, the pricing logic has to hang together every step of the way. It is the kind of complexity that does not show up in a demo but determines whether a platform holds for five years.
For wholesalers like BE Group, where every contract customer has their own terms and several markets run in parallel, internationalisation becomes as important to pricing as the pricing logic itself.
6. Price updates and ownership
A pricing model is never static. Contracts are renegotiated, campaigns start and end, raw-material prices push through to purchase prices that have to be reflected in sales. What determines whether the system holds over time is how changes are made and who owns them.
The questions you need to be able to answer:
- Who owns the update of a contract price? Is it the sales rep in the ERP, finance through a separate import, or someone in the marketing or e-commerce team?
- How quickly does a change propagate to the webshop after it is registered in the ERP?
- How are mass updates handled, for example an annual general price adjustment that has to hit thousands of contracts at once?
- Which rule applies to active carts and quotes when the price changes before the order is completed?
Varsego cut their manual work by 80 percent after connecting their e-commerce directly to the ERP pricing logic without middleware. That means a contract change that previously required manual handling in several systems now happens in one place and propagates everywhere automatically. It is the difference between an e-commerce channel that scales with the number of customers and one that needs more headcount for every new customer.
7. ERP integration that actually holds
All the customer-specific pricing described above stands or falls with the connection between the e-commerce platform and the ERP. It does not matter how smart the platform is if the integration is not in place, or if it has to be rebuilt at every version update.
The difference between a possible integration and a finished integration is significant. A possible integration means the ERP has an API and that it is technically feasible to build a connection. It can take many months to finish and then needs to be maintained by someone in your organisation or by a consultant. A finished integration is documented, tested and maintained by the platform vendor or a certified partner, and works from day one.
Litium's ERP integrations for Monitor, Jeeves, Business Central and SAP are built and maintained by Litium or certified partners. That means the pricing logic has a clear owner and that version updates in both systems are tested before they hit your production.
Always ask three things: who owns the integration, how often is it tested at version updates, and what happens if the integration goes down during business hours. The answers reveal how far the platform has thought about the day-to-day reality of B2B operations.
Summary: seven things to go through before choosing a platform
Customer-specific pricing is not a feature on a requirements list. It is an area that runs through the entire B2B business online and determines whether the platform holds long term or becomes a bottleneck.
The seven points to go through:
- Which pricing models does the platform handle: list price, customer group, contract, volume discount and campaign?
- Where is the price calculated, and who owns the logic: the ERP, the platform or a separate pricing engine?
- Is price retrieval real time via API, or scheduled batch export?
- How are performance and caching of customer-unique prices handled in list views?
- Does the platform handle multiple markets, currencies, tax rules and sales entities in the same instance?
- How quickly does a price change take effect after it is registered in the ERP?
- Is there a finished, documented and maintained ERP integration to your business system?
Vendors sell on feature lists. You should buy on architecture, performance and who owns the maintenance over time. Those three factors decide whether customer-specific pricing works in production or only in the demo.