B2B Ecommerce Pricing Rules That Break Standard Platforms
Standard e-commerce platforms are built around a single price per SKU. B2B doesn't work that way. Here's what breaks, why it breaks, and what you actually need to build instead.
Why Standard Platforms Fall Apart for B2B Pricing
Most SaaS e-commerce platforms — Shopify, WooCommerce, even Magento's out-of-the-box config — are designed around a consumer mental model: one product, one price, maybe a sale percentage. B2B pricing is a completely different data model.
In B2B, a single SKU might have a dozen valid prices at any moment. A distributor gets a contract rate. A reseller gets a tiered volume discount. A new account gets list price. A key account gets a bespoke rate negotiated annually. None of those are "discount codes." They are contractual obligations stored in your ERP and enforced at checkout.
The moment you try to bolt that onto a platform that wasn't designed for it, you're writing custom middleware to patch over a fundamental mismatch in the data model. That's not a configuration problem. That's an architecture problem.
What Does a Real B2B Pricing Model Actually Look Like?
The structure has several distinct layers that need to coexist and resolve cleanly.
Contract Pricing
A buyer has a signed agreement that says: for SKU X, they pay £14.20 per unit, regardless of what anyone else pays or what the catalogue says. That price lives in your ERP — SAP, Oracle, or a custom pricing engine — and needs to be fetched in real time at the point of cart pricing, not cached from a nightly sync.
Latency matters here. If your pricing API takes 800ms per line item and a buyer has a 60-item order, you've added 48 seconds to checkout. You need a read-optimised pricing cache with a TTL short enough to catch mid-day contract changes, typically under 15 minutes, with a write-through invalidation strategy when contracts update.
Volume Tiers
Tiered pricing is not the same as a bulk discount. A tier table might look like this:
| Quantity | Unit Price |
|---|---|
| 1–49 | £22.00 |
| 50–199 | £19.50 |
| 200–499 | £17.00 |
| 500+ | £14.80 |
The complexity kicks in when tiers are cumulative (the first 49 units cost £22 each, the next 150 cost £19.50 each) versus non-cumulative (buying 50 units drops all of them to £19.50). Both are common. They produce different invoice amounts and different buyer expectations. If your platform doesn't distinguish between them in its data model, you'll generate incorrect line totals.
Customer-Specific Price Lists
Some buyers aren't on a per-SKU contract. They're on a price list: a named set of prices that applies to their account and overrides catalogue pricing across hundreds of SKUs. ERP systems like SAP SD model this as a condition type hierarchy. When you replicate that to a web front end, you need to mirror the resolution order, not just pull a flat price.
Dynamic Pricing Rules
Promotional pricing, minimum order quantity surcharges, currency-dependent pricing for cross-border accounts, and freight-inclusive pricing for specific regions all sit on top of the above. Each rule needs a priority, a scope (account, account group, product category, or individual SKU), and an effective date range.
This is where most custom builds accumulate debt. Teams add rules as one-offs. After 18 months, nobody can confidently say which rule applies in which scenario. You need a rules engine with an audit log, not a series of conditional statements in application code.
/// Not sure where to start?
Get the architecture before you commit
Tell us what you're building and we'll map the technical approach, stack, and rough timeline. No cost, no obligation, no sales call required.
How Should You Model the Pricing Resolution Logic?
The cleanest approach we've seen in production is a deterministic waterfall with explicit fallback ordering. Each request passes through the layers in a defined sequence and returns the first match.
A typical order:
- Active contract price for this account and SKU
- Customer-specific price list
- Account group price list
- Volume tier from catalogue pricing
- Catalogue list price
You log which layer returned the result. That log entry is what your sales team uses when a buyer queries why they paid £17.00 instead of £19.50. Without it, you're reconstructing pricing logic from memory.
The resolution engine should be a standalone service, not embedded in your front-end application or your order management system. Both need to call it. If you embed it in one, you'll eventually have two implementations that drift apart.
What About Real-Time vs. Batch Pricing?
For catalogue browsing, batch-computed prices are fine. Pre-compute the applicable price for each account segment, cache it, serve it fast. Accuracy requirements at browse time are lower.
At cart and checkout, you need real-time resolution. The price displayed in the cart needs to match the price on the invoice. Any delta between those two numbers creates a support ticket, and in regulated industries, a compliance issue.
A hybrid architecture works well: a Redis cache of segment-level prices for browse, a synchronous call to the pricing service at cart lock, and an ERP confirmation call before invoice generation.
The Currency and Tax Layer Everyone Underestimates
Multi-currency B2B adds another dimension. It's not just converting a GBP price to EUR at today's rate. Contract prices are often denominated in a specific currency. A German buyer's contract might specify €16.40 per unit, independent of the GBP catalogue price. Your system needs to store and resolve currency-native contract prices, not convert on the fly.
Tax is similarly mishandled. B2B transactions frequently involve VAT reverse charge, tax-exempt certificates, and jurisdiction-specific rules that consumer platforms never handle. Avalara and Vertex both have APIs for this, but they need to receive the correct buyer tax classification and ship-to jurisdiction to return the right result. That data has to flow from your account management system, not be guessed at checkout.
Should You Build This or Buy a B2B-Specific Platform?
Platforms like OroCommerce, Insite Commerce, and Sana Commerce exist specifically for this problem. If your pricing model is complex but not unusual — tiers, price lists, contract pricing — evaluate them seriously before building. They have the data model right. The integration work to connect them to your ERP is still significant, typically 3 to 6 months, but you're not solving a solved problem from scratch.
Build custom when your pricing logic is genuinely unusual. If you operate a marketplace where sellers set prices with buyer-specific visibility rules, or if your pricing engine feeds both a web front end and an EDI channel and a field sales tool simultaneously, a purpose-built service will be cleaner than adapting an existing platform.
The honest trade-off: a custom pricing service gives you full control and no licensing cost, but you own the maintenance, the edge cases, and the performance tuning. A B2B platform gives you a working baseline but constrains your data model to theirs.
Conclusion
If you're hitting the ceiling of what your current platform can express in pricing rules, the next step is to map out your pricing waterfall on paper before writing any code. Document every rule type, every input variable, every edge case your sales team has handled manually. That map will tell you whether you're looking at a configuration project, a platform migration, or a custom pricing service. Get that clarity first.
FAQ
Why can't I just use discount codes and customer tags for B2B pricing? Discount codes are stateless and single-use by design. B2B contract pricing is persistent, account-bound, and often SKU-specific across hundreds of products. Customer tags can group accounts, but they don't carry price list associations or tier structures natively. You end up writing code that the platform was never designed to support.
What's the biggest technical mistake teams make when building B2B pricing? Embedding pricing logic in the front-end application. Once it's there, your mobile app, your EDI integration, and your internal order tool all need their own copy. They will drift. Centralise pricing resolution in a dedicated service that every channel calls.
How do you handle mid-order contract changes? Lock the price at cart creation and store the resolved price with the order record. If a contract changes between cart creation and checkout, flag it for review rather than silently updating. Buyers expect the price they saw in the cart to be the price on their invoice.
Do B2B platforms like OroCommerce handle ERP pricing integration out of the box? They provide the connectors and the data model, but the integration work is still yours. You need to map your ERP's condition types and customer hierarchies to the platform's equivalents. For SAP SD specifically, that mapping exercise alone takes weeks to do correctly.
When does a custom pricing microservice make more sense than a platform? When you have more than one channel that needs to resolve prices using the same logic — a web storefront, an EDI feed, a field sales tool, an API for wholesale partners. A shared service prevents logic duplication. If you only have a single web channel, a platform is almost always faster to production.
Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.
/// Work with us
Talk to the engineers who'd build it
You'll get a technical scope, timeline and cost estimate from the people doing the work, not an account manager. In-house team, no subcontracting, since 2016.