B2C commerce has one price per product. B2B has a price per product per customer, sometimes per quantity, sometimes per contract period, and frequently a set of exceptions that exist only as an agreement between a sales manager and a specific buyer.
Platforms are built for the first case and extended into the second. That extension is where B2B stores become unmaintainable, and the cause is almost never the platform itself.
How it actually breaks
The pattern is consistent across the stores we are called into.
- Base prices come from the ERP on a nightly sync.
- Customer discounts are configured in a pricing plugin, because the ERP export did not include them.
- Three large accounts have exceptions maintained by hand, because the plugin cannot express them.
- One account has a spreadsheet that the sales team applies manually to quotes.
- Nobody can say, for a given customer and product, where the number on the screen came from.
The last point is the real failure. Once no single person can trace a price to its source, the store cannot be changed safely, and every replatform proposal starts with months of archaeology.
Write down who owns each number
Before choosing a platform, before writing an integration, produce a table. Every price-affecting value, and the one system that owns it.
Base price, cost, currency, tax class, customer discount percentage, product-specific overrides, quantity breaks, contract prices, promotional prices, shipping rules, credit terms. For each: which system is authoritative, which systems receive it, and what happens when two disagree.
This document takes a day and it decides the architecture. Most integration disasters are two systems both believing they own the same value, and the disagreement only surfaces when a customer is quoted two different prices in the same week.
What a B2B model usually needs
Once ownership is settled, the requirements list is fairly standard. What varies is which of these you actually have, and platforms differ enormously in how many they express natively rather than through extensions.
- Account hierarchies. A parent company, its subsidiaries, and buyers within each, with visibility scoped correctly at every level.
- Customer-specific price lists, assigned per account or per account group.
- Quantity breaks, which interact with customer pricing and need a defined precedence.
- Quote and approval flows, where a buyer requests, someone approves, and the quote converts to an order without re-entry.
- Purchase orders and credit terms, meaning an order can complete without a card payment.
- Restricted catalogues, where an account only sees what it is contracted to buy.
- Re-ordering, because B2B buying is mostly repeat buying and this single feature moves more revenue than most redesigns.
Precedence is a business decision, not a technical one
When a customer has a contract price, a quantity break applies, and a site-wide promotion is running, which wins?
There is no correct answer in the abstract, and the platform will have a default that nobody chose. Get the rule decided by whoever owns margin, write it down, and implement it explicitly rather than inheriting whatever the plugin does.
We have seen a promotion apply on top of contract pricing for eleven months before anyone noticed. The code was working exactly as configured.
You may not need to replatform
The instinct when pricing is a mess is to move platform. Frequently the platform can express what you need, and the mess is in the integration and the ownership model.
Fix the ownership table first. Move the discounts out of plugin configuration and into the source of truth. Add reconciliation that compares both sides nightly and reports divergence rather than assuming agreement. In a good proportion of cases that is the whole project, and it costs a fraction of a replatform.
If after that the platform genuinely cannot express the selling model – layered account hierarchies, configurable products, unusual fulfilment – then replatforming is justified, and now you have the document that makes it estimable.