Your ERP Is the System of Record: Getting Customer-Specific Pricing Right in B2B eCommerce
Ask anyone who has delivered a B2B commerce project for a manufacturer what consumed the most engineering time, and the answer is rarely the storefront. It is pricing. Product data is hard, inventory is fiddly, but pricing is where projects genuinely stall — because in B2B, price is not an attribute of a product. It is a function of the product, the customer, the quantity, the currency, the date, and twenty years of negotiated agreements that live inside the ERP. Getting customer-specific pricing in B2B eCommerce right is, in our experience, the single hardest integration surface in the whole programme, and it is the one that decides whether your sales team trusts the web channel or spends the next three years apologising for it.
We have written before about the broader shape of connecting Elastic Path to your back office — products, stock, orders, customers. This article deliberately ignores all of that and goes deep on pricing alone: why it is different, the three integration patterns that actually work, the failure modes we see most often in manufacturing and industrial engineering businesses, and how the whole thing lands in a composable platform like Elastic Path. If you are an IT or digital lead at a manufacturer whose ERP owns pricing, this is the part of ERP eCommerce integration you need to get right first.
What a B2B Price Actually Is
Consumer commerce has trained everyone to think of price as a number on a product record. B2B pricing in a manufacturing business is nothing like that. When a customer logs in and asks “what does this part cost me, today, in this quantity?”, the honest answer is assembled from several layers:
- Contract prices. Negotiated per customer (or per buying group), often per SKU or per product family, usually date-effective with a start and end, and frequently the output of an annual negotiation nobody wants to repeat mid-year.
- Customer price lists and price groups. Most customers do not have a fully bespoke price on every item; they belong to a price group or tier, with a smaller set of genuinely customer-specific overrides layered on top.
- Quantity breaks. Buy 10 at one price, 100 at another, 1,000 at a third — sometimes on the line, sometimes across the order.
- Currency. A global manufacturer prices in multiple currencies, and the relationship between them is a commercial decision, not a spot-rate conversion.
- Surcharges and adders. Energy surcharges, raw material adjustments, minimum order charges, carriage rules. These come and go with market conditions and are often applied at order level rather than line level.
- Units of measure and pack quantities. Priced per hundred, sold in boxes of 25, quoted per metre. The conversion rules matter as much as the numbers.
The critical observation is that this logic already exists, and it lives in the ERP. SAP, Dynamics, Infor, Epicor, and every venerable AS/400 system we have ever integrated all contain a pricing engine — a set of conditions, procedures and hierarchies that resolve “this customer, this product, this quantity, this date” into a price. That engine is what the finance team trusts, and crucially, it is what generates the invoice.
The Principle: The ERP’s Pricing Engine Stays Authoritative
Every B2B commerce project faces the same temptation early on: the commerce platform has pricing features, so why not rebuild the pricing rules there? It looks faster. It avoids an integration. It is almost always a mistake, for one simple and commercial reason: the invoice comes from the ERP.
If the web store calculates a price using its own reimplementation of the rules, and the ERP calculates the invoice using the original rules, then any divergence between the two — a missed contract renewal, a rounding difference, a surcharge applied in one place and not the other — becomes a customer-facing pricing dispute. The customer saw £4.20 a unit at checkout and was invoiced £4.38. Multiply that by a few hundred orders a month and you have a credit-note factory, a finance team reconciling differences by hand, and a sales force telling customers to phone their order in “because the website gets prices wrong”.
So the principle underpinning everything that follows: the ERP is the system of record for price, and the integration’s job is to transport prices faithfully, never to recalculate them. The price the customer sees must be a price the ERP produced, or one the ERP will verifiably confirm before money changes hands. Hold that line and the rest is engineering. Lose it and no amount of engineering will save you.
That said, “the ERP is authoritative” does not answer the practical question of when the ERP gets asked. That is where the three patterns come in.
Pattern One: Bulk Price-List Synchronisation
The simplest pattern: on a schedule, export prices from the ERP — list prices, price group prices, customer-specific contract prices — and load them into the commerce platform’s own price containers. The storefront then serves every price locally, with no runtime dependency on the ERP at all.
The strengths are real. Browsing is fast, because pricing is a local lookup. The ERP is untouched by storefront traffic, which matters when the ERP was sized for a few hundred internal users rather than public web load. And the storefront keeps working when the ERP is down for month-end processing or maintenance.
The weaknesses are equally real. First, staleness. A synced price is correct as of the last sync. If contract prices change mid-cycle — a renegotiation, an emergency surcharge — the web channel lags until the next run. That window is a business decision: for many manufacturers a nightly sync is genuinely fine, because prices change annually, not hourly. For others it is not, and pretending otherwise is how disputes start.
Second, the matrix explosion. The naive export is every price for every customer: 10,000 customer accounts times 50,000 SKUs is 500 million potential price rows, most of which will never be looked at. Nobody should sync that. The workable approach mirrors how the ERP itself stores pricing: sync the price structure — list prices, price group tables, and only the genuinely customer-specific overrides, which are usually a tiny fraction of the theoretical matrix. Resolve “which group does this customer belong to” at request time. If your ERP’s pricing is so conditional that prices only exist once calculated (common with heavily configured SAP condition techniques), bulk sync of the full matrix is off the table anyway, and you are steered towards patterns two or three.
Third, operational discipline. Full nightly reloads are simple but heavy; delta syncs are efficient but demand reliable change detection in the ERP. Date-effective prices need to be loaded ahead of their start date, not on it. And every sync run needs monitoring with the same seriousness as a payment integration — a silently failed price sync is a store confidently serving yesterday’s prices.
Pattern Two: Real-Time Price Calls
The opposite pattern: the storefront holds no prices at all. Every time a price is needed — product page, search results, cart — the platform calls the ERP (directly, or through an integration layer) and asks the authoritative engine to calculate it live.
The appeal is obvious: the price is always right, by construction. Contract changes take effect instantly. There is no matrix to sync and no staleness window to argue about.
The costs are severe and are usually discovered in production. Latency first: a price call that takes 400 milliseconds is invisible on a single product page and catastrophic on a category page rendering 48 products, or a quick-order pad pricing 200 lines. Availability coupling second: your storefront is now precisely as available as your ERP, and ERPs have maintenance windows, month-end runs and batch jobs that were scheduled long before anyone imagined a web store depending on them at 2am. Load third: ERPs are licensed and sized for internal users. Letting anonymous browse traffic generate pricing calls into the ERP is a way to discover your ERP’s connection limits during your busiest trading week.
Real-time pricing has its place — but that place is narrow and deliberate: low-traffic, high-value interactions where accuracy is non-negotiable, such as pricing a quote or confirming a cart. As the default mechanism for all browsing, it is a pattern we have repeatedly been asked to rescue projects from.
Pattern Three: The Pragmatic Hybrid
Almost every production system we respect lands on a combination of the two, and the logic is simple: match the accuracy guarantee to the moment that needs it.
- Browsing runs on synced prices. Product pages, category listings and search show the customer’s contract or price-group price from the local store — fast, ERP-independent, and correct to within the sync window. Where the business wants belt and braces, these can be labelled as indicative.
- Commitment runs on the ERP. At the point where a number is about to become an order — cart review, quote generation, checkout — the integration makes one consolidated, real-time pricing call to the ERP for the whole basket, and the confirmed prices are what the customer accepts. One call per checkout is a load profile any ERP can sustain; one call per page view is not.
- Degradation is a decision, not an accident. When the ERP is unreachable at confirmation time, something must happen: block checkout with an honest message, or accept the order at synced prices flagged “subject to confirmation”. Both are defensible; which one your business wants is a commercial choice that should be made explicitly in a meeting, not implicitly by an unhandled timeout at 2am.
The hybrid also concentrates integration effort where it pays. The bulk pipe handles the undramatic 99% of price displays; the real-time call guards the moment that generates an invoice. And because the ERP confirmation uses the same engine that will invoice, price disputes are engineered out rather than reconciled after the fact.
This is the pattern that benefits most from a proper integration layer between the storefront and the ERP — somewhere for consolidation, caching, retries and monitoring to live, rather than scattering them through commerce-platform plugins. It is the same architectural instinct behind the Digital Edge Platform we built for IMI Precision Engineering, which plugs into IMI’s disparate best-of-breed systems and flows information between them to give staff a single, current view of the truth. Pricing integration is that idea applied to the most sensitive data a manufacturer publishes.
The Failure Modes We See Most Often
Patterns describe the happy path. These are the ways contract pricing integrations actually go wrong, drawn from projects we have built and projects we have been called in to repair.
Stale contract prices become invoice disputes
The sync ran, but the contract renewal loaded into the ERP on the 1st did not reach the web store until the 4th. The customer ordered at the old price and was invoiced at the new one — or worse, the reverse, and now finance wants to claw back the difference. Each individual case is small; the cumulative effect is corrosive, because the sales team stops trusting the channel. The defences are unglamorous: sync date-effective prices ahead of time, alert on sync failures loudly, and give customer service a way to see exactly which price version the customer was shown.
Nobody can tell you how the ERP prices things
In a business that has run the same ERP for twenty years, pricing logic accumulates like sediment: special conditions for accounts that lapsed a decade ago, a surcharge implemented as a negative discount, an override table only one semi-retired analyst understands. The integration team faithfully reproduces the documented rules and gets 95% of prices right — and the remaining 5% are, with grim reliability, your largest accounts, because big customers are exactly the ones with bespoke arrangements. The mitigation is to treat pricing discovery as a first-class workstream: before go-live, run automated parity tests comparing the web price against the ERP-calculated price across a representative sample of real customers, real SKUs and real quantities — and keep running them in production, because pricing logic keeps evolving after launch.
Performance collapses at the worst moment
The demo priced one product beautifully. Production met a quick-order pad with 300 lines, each line triggering its own pricing call — the classic N+1 problem wearing a hi-vis jacket. The ERP slows, the storefront times out, and it happens precisely when your biggest customer places their biggest order. Batch pricing calls at the basket level, cache aggressively where accuracy allows it, and load-test with realistic B2B order shapes: fifty to five hundred lines, not the three-item consumer basket the platform vendor’s demo used.
Units, currency and rounding
Priced per hundred, sold per box of 25, displayed each; a half-penny rounding difference multiplied across a 10,000-unit line; a currency conversion done in the storefront that the ERP does differently. Small mismatch classes that produce invoice deltas indistinguishable, from the customer’s side, from being overcharged. The rule from the principle section applies with full force: transport the ERP’s numbers, including its rounding, rather than deriving your own.
Where Quotes Fit
Not every price belongs on a product page. Every manufacturer has a threshold — order value, configuration complexity, special-length or engineered items — beyond which pricing is a conversation, and forcing it through webstore pricing either leaks margin or loses the deal. The mature pattern is quote-to-order: the customer assembles their requirement online, requests a quote, the quote is priced where quoting already lives (the ERP or CPQ, by the people who own the discretion), and it flows back into the customer’s account online for acceptance and one-click conversion into an order — at exactly the quoted prices, which the ERP already knows because it produced them.
The point is that quoting is not a failure of eCommerce; it is a pricing pattern in its own right, and designing the handoff deliberately beats pretending everything can be self-service. We have covered the account-portal side of this — quotes, order history, reordering — in our article on building B2B self-service buyer portals with Elastic Path.
How This Lands in Elastic Path
Everything above is platform-agnostic; you will face the same decisions on any commerce stack. But the reason we keep recommending composable platforms for manufacturers is that they are built to receive this integration rather than fight it. In Elastic Path, pricing is deliberately decoupled: price books are first-class objects separate from products, multiple price books support currencies and customer tiers, and catalogues can be assembled per account — which maps naturally onto ERP price groups plus customer-specific overrides, exactly the structure pattern one syncs and pattern three serves. And because the platform is API-first, the checkout-time confirmation call in the hybrid pattern is a supported extension point rather than a fight with a monolith’s assumptions. That is the practical meaning of Elastic Path ERP integration: the platform supplies the containers and the APIs; the integration supplies the truth.
That receptiveness matters at manufacturer scale. When we rebuilt the global web store for Norgren — a brand of IMI Precision Engineering whose previous bespoke store had generated hundreds of millions of dollars over its lifetime — the composable approach with Elastic Path was chosen precisely because assembling configurable off-the-shelf services lowered the cost of ownership and let development effort concentrate on the features that differentiate, while distributing the workload so that no single component could stall the order flow. That is the environment you want your pricing integration to live in: one where the hard problem gets the attention, because the platform is not consuming it.
How McKenna Consultants Can Help
Customer-specific pricing sits exactly at the junction of our two longest-standing disciplines: systems integration and B2B eCommerce. We have spent over 25 years connecting manufacturers’ back-office systems — ERP, dispatch, customer data — into platforms their staff and customers actually trust, from the Digital Edge Platform for IMI Precision Engineering to the composable Elastic Path store for Norgren, and pricing is the surface where that combined experience earns its keep.
If you are planning a B2B commerce programme and the pricing workstream is the part keeping you up at night — or you have a live store where web prices and invoices keep disagreeing — we can help you choose the right pattern, design the integration layer, and put the parity testing in place that keeps the ERP and the storefront telling the same story. Get in touch and we will talk it through.
