Your buyer logs into the portal, adds 200 units to the cart, and sees $14.80 each. Their contract says $12.40. They email sales. Sales emails finance. Someone issues a credit note three days after the order ships.
That sequence costs real money, and it happens more often than most ops teams want to admit. The Nordic Digital Commerce in B2B 2026 report identifies customer-specific pricing as the single biggest reason B2B companies abandon B2C-built eCommerce platforms. Not UX, not catalog depth: pricing.
The instinct is to fix the storefront. Rebuild the price list upload, add a pricing module, hire someone to audit the CSV every quarter. But the storefront is not where the problem lives. Contract prices are negotiated, stored, and maintained in the ERP. The moment a copy of that data moves anywhere else, the clock starts ticking on drift.
“Pricing drift is a workflow problem, not a storefront problem. Fix where the price lives and how it moves — not where it is displayed.”
This post walks through why pricing drift happens, three sync architectures that actually prevent it, and how to validate price accuracy at order time — not just at sync time.
Key takeaways
Contract and customer-specific prices should be mastered in the ERP; every copy that moves elsewhere is a source of drift.
Most pricing errors trace back to the "four copies problem" — the same price copied into a portal export, a sales spreadsheet, a finance exception log, and sometimes a separate PIM.
There are three sync models — real-time lookup, scheduled sync, and hybrid — and the right one depends on how often prices change and how much load the ERP can absorb.
For most mid-market distributors, a nightly scheduled sync with real-time fallback on cart pricing is the practical sweet spot.
Sync alone is never enough: validate price at order time by re-deriving the ERP price and holding orders whose variance exceeds a 1-3% threshold.
Why B2B Pricing Is Harder Than B2C
In B2C, one product has one price. Maybe two if there is a sale. Every customer sees the same number.
B2B pricing is a stack of overrides layered on top of each other, and each layer can apply to a different customer, order size, or time window:
- List price: the published catalog price, the starting point no serious buyer actually pays.
- Contract price: the negotiated rate for a specific customer or customer group, stored in the ERP against that account.
- Volume tiers: price breaks that activate at quantity thresholds, often defined per product or product family.
- Campaign prices: time-limited promotional rates that sit on top of contract prices and expire on a set date.
The critical detail is where these prices live. List prices might exist in a spreadsheet or a PIM. Volume tiers might be configured in the storefront. But contract prices almost always live exclusively in the ERP, because that is where the customer account, the credit terms, the currency, and the legal agreement are managed.
When a buyer logs in and expects to see their negotiated rate, the system has to go back to the ERP to get the right number. Any architecture that does not do that is working from a copy, and copies go stale.
Where Pricing Drift Comes From
Most pricing problems trace back to what you could call the four copies problem. By the time a contract price reaches a buyer’s screen, it has typically been copied at least four times: from the ERP into a portal CSV export, from there into a sales spreadsheet used for quoting, from there into a finance exception log for credits and adjustments, and sometimes into a fourth system if the company runs a separate PIM or product catalog.
Each copy is a point of failure. Each one drifts independently. None of them automatically know when the others change.
1. Price lists expire in the ERP but not in the portal
Contract prices in SAP Business One, Business Central, and NetSuite all carry validity dates. When a price list expires, the ERP stops applying it. But if the portal loaded that price list via a CSV upload six months ago, it has no idea the validity window closed. The old price keeps showing.
2. Unit-of-measure mismatches
A buyer orders by the case. The ERP stores the contract price per unit. The portal converts using a static ratio that was correct when it was set up but has not been updated since the supplier changed pack sizes. The displayed price is mathematically wrong before any sync failure even occurs.
3. Currency and multi-entity pricing
Distributors with entities in multiple countries often maintain separate price lists per currency or legal entity in the ERP. The portal may only pull from one entity’s price list, showing USD rates to a buyer whose account is billed in EUR, or applying the wrong exchange rate entirely.
4. Customer group mapping gaps
ERPs group customers into pricing tiers: key accounts, standard accounts, distributor partners. The portal maps those groups to its own customer segments. When a sales rep moves a customer to a new pricing tier in the ERP, that mapping update has to propagate to the portal. If it does not, the buyer gets the old tier’s prices.
5. Manual overrides that never sync back
A sales rep grants a one-time discount directly in the ERP for a specific order. Finance records a price adjustment. Neither event triggers a sync event to the portal. The portal keeps showing the standard contract price, and the buyer expects the adjusted rate on their next order because "that is what we paid last time."
The common thread
Every one of these causes involves a price change that happened in the ERP and did not reach the portal. The fix is not a better CSV upload schedule. It is an integration that treats the ERP as the authoritative source and keeps the portal synchronized in real time or near-real time.
The storefront-first approach
Three Sync Models and When to Use Each
There is no single right architecture for B2B price list sync. The right model depends on how frequently prices change, how much load the ERP can absorb, and how much complexity the team can maintain. Here are the three patterns that cover most real-world scenarios.
Real-Time Lookup
The portal does not store prices at all. Every time a buyer views a product or adds it to the cart, the portal calls the ERP API and fetches the current contract price for that customer in real time.
This is the most accurate model possible. There is no copy to drift. The buyer always sees what the ERP would charge. It works well for businesses where prices change daily or weekly, driven by commodity costs, currency fluctuations, or supplier adjustments.
The tradeoff is ERP load. Every page view becomes an API call. For high-traffic portals or ERPs with limited API throughput, this can create performance bottlenecks. It also requires the ERP to expose a reliable, low-latency pricing endpoint.
Scheduled Sync
Prices are pulled from the ERP on a defined schedule, typically nightly or weekly, and written to the portal’s own database. The portal serves prices from its local cache.
This works well when prices are stable and change on a predictable cycle, such as quarterly contract renewals. It is lighter on ERP resources and keeps portal performance fast. The risk is the gap between sync runs: a price updated on Tuesday morning will not appear in the portal until the next scheduled sync.
For most distributors and manufacturers with quarterly or annual contract pricing, a nightly sync is an acceptable tradeoff. The key is making the sync window explicit and monitoring it for failures.
Hybrid: ERP Base Price with Portal Overlay
The ERP pushes base contract prices to the portal on a schedule. The portal is then allowed to apply a controlled overlay for promotions, bundle pricing, or channel-specific discounts, within defined guardrails.
This is the most flexible model and the most operationally complex. It works well when the marketing or eCommerce team needs to run promotions without involving ERP configuration, but the business still needs contract prices to anchor every transaction.
The guardrails matter. Without them, the portal overlay becomes another source of drift.
Which Model Fits Your Setup
Comparing the three price-sync models
| Model | Price Latency | ERP Load | Accuracy | Complexity |
|---|---|---|---|---|
| Real-time lookup | Seconds | High | Highest | Medium |
| Scheduled sync | Hours to days | Low | Good (within sync window) | Low |
| Hybrid | Minutes to hours | Medium | High (with guardrails) | High |
For most mid-market distributors on SAP Business One or Business Central, a nightly scheduled sync with real-time fallback on cart pricing is the practical sweet spot: low ERP load for catalog browsing, accurate price at the moment of commitment.
Who Owns What: A Pricing Ownership Model
Sync architecture solves the technical problem. Ownership solves the organizational one. Most pricing disputes inside a business happen not because the integration failed, but because two teams both thought they owned the same number.
A clear ownership model answers three questions: who can change a price, where does that change live, and what triggers a downstream update?
Sample pricing ownership matrix
| Layer | Owner | System of Record | Change Trigger |
|---|---|---|---|
| Contract price and terms | Sales / Finance | ERP | Contract renewal or amendment |
| Volume tier thresholds | Sales Operations | ERP | Quarterly review |
| Campaign and promotional pricing | eCommerce / Marketing | Portal overlay (with ERP floor) | Campaign launch |
| MOQ and pack size rules | Operations | ERP | Supplier or product change |
| Approval for price variances | Sales Manager | Order workflow | Variance exceeds threshold |
The principle behind this matrix: the ERP owns anything that affects revenue recognition or customer contract terms. The portal owns the buyer experience layer — how prices are displayed, what promotional banners appear, and whether an MOQ warning fires. The order workflow owns the approval gate that sits between a submitted order and a posted transaction.
When a change happens outside the designated system of record, it should either be rejected or immediately written back to the correct system. A sales rep who adjusts a price in the portal’s admin panel without updating the ERP has created a new copy. That copy will drift.
Copy this matrix, adapt the owner column to your org chart, and share it with every team that touches pricing. The conversation it forces is worth more than the document itself.
Validate at Order Time, Not Just at Sync Time
Even a well-designed sync will occasionally produce a mismatch. Price lists update between sync runs. A customer moves to a new tier the morning they place an order. A campaign ends at midnight and the portal cache has not refreshed yet.
This is why sync alone is not enough. The order import process itself needs to validate price.
When an order arrives from the portal into the ERP, the ERP should re-derive the correct price for that customer, that product, and that quantity, using its own pricing logic, and compare it against the price submitted with the order. If the two numbers match within an acceptable tolerance, the order posts automatically. If they diverge beyond the threshold, the order should be held and routed to a sales rep for review before it posts.
This pattern does several things at once:
- It catches sync failures before they become credit notes.
- It creates an audit trail of every price variance, which is useful for contract renegotiations.
- It removes the need for the sync to be perfect, because the ERP acts as the final check.
What to configure:
Define an auto-post variance threshold
Set a variance threshold — typically 1-3% — below which the order posts automatically with the ERP price applied. Inside the tolerance band the buyer never notices and no one has to touch the order.
The goal is not to block orders. It is to catch errors before they ship and before the customer notices. A buyer who never sees a wrong price on their invoice does not know the sync had a bad night. That is the experience worth building toward.
See How AI Automation Works along with SAP Business One
Book a 20-minute demo and we'll walk through your specific process.
Book a Demo
