Most e‑commerce problems are ERP problems in disguise
If online growth is stalling, it’s usually not the cart. It’s pricing, inventory, and order flows trapped in the ERP (or scattered in spreadsheets). Fix the operating model first; the site follows.
I’m going to lay this out in plain language. We’ll name the symptoms you’re seeing. We’ll show why the ERP is the bottleneck, not your website. Then we’ll give you a 90‑day fast path that gets results without a full rebuild. The focus is B2B ecommerce ERP integration and complex commerce, but the same thinking helps advanced B2C. This is how to make ecommerce operations work when your business is, well, complex.
The telltale symptoms
You don’t need a crystal ball. You need a short list.
Manual order entry is back. Reps retype web orders into the ERP “to fix pricing.” Or they type phone orders into the ERP because web pricing is wrong for contracts.
One‑off overrides everywhere. “For this customer, ship partials.” “For that one, hold until complete.” These choices live in emails and Rep Brain™, not in systems.
Data drift. The product master in the ERP doesn’t match PIM or the storefront. Attributes diverge. Someone changed a unit of measure last month and nobody told the site.
Rep resistance. Sales says the site “doesn’t work for our customers.” Which often means the site doesn’t reflect contract logic or inside‑sales workflows.
Laggy inventory. The site says “in stock.” The warehouse says “nope.” You refund. Confidence drops.
Returns are chaos. RMAs, credits, restocks, scrap — all handled five different ways by three teams.
Mismatched metrics. Google Analytics says one thing. The ERP says another. Leadership wonders who to trust.
“Why does GA say one thing and the ERP another?”
Because they measure different truths at different times.
GA tracks browser events and payment attempts. It often counts an order when the customer submits the checkout.
The ERP tracks the accounting truth. It counts orders when they post, or invoices when they bill, or shipments when they leave.
Reality lives across a timeline: authorization → order acceptance → allocation → pick/pack/ship → invoice → paid → return/credit. If your systems don’t agree on which moment defines “the order,” the numbers won’t match.
Fixing this starts with a data contract. Define the event when “an order counts.” Propagate a single order identifier from site to ERP to analytics. Reconcile partials and cancellations with explicit events. More on that below.
Why the ERP is the bottleneck (not the website)
Websites are fast to change. ERPs are slow, sticky, and full of rules. When growth stalls, leaders often assume, “We need a new site.” Sometimes you do. Usually you don’t. The real constraint is that your pricing truth, inventory truth, and order truth live in the ERP and are either hidden, inconsistent, or delayed.
Your storefront can’t sell what the ERP can’t express. If the ERP can’t answer, for this customer, at this location, right now, how much and how soon at what price?, then your online channel will stall. The site is only the surface. The operating model is the engine.
Let’s break down those three truths.
Pricing truth: contracts, tiers, overrides
B2B pricing is not “price = list − discount.” It’s a web of rules:
Contract price by customer and item, often with start/end dates.
Tiers by volume, customer class, or region.
Overrides by sales rep, quote, or project.
Freight rules, fuel surcharges, and minimums.
Promotions that stack (or don’t).
Taxes and exemptions by nexus and customer status.
If this logic lives in Excel or in a sales rep’s head, the site will never match it. If this logic only lives in the ERP but isn’t exposed through a clean API, the site still can’t use it. And if you copy parts of it into the storefront to “move fast,” you’ll drift out of sync within weeks.
What good looks like: The ERP (or a dedicated pricing engine tied to the ERP) is the single source of pricing truth. The storefront calls for a PriceResult that includes: base price, contract price, applied discounts, effective dates, terms impacting price, and any constraints. The response is cacheable for read speed, but the computation happens once, in one place. Reps and the site see the same numbers.
Inventory truth: ATP, multi‑warehouse, allocations
“In stock” is not a boolean. It’s Available‑to‑Promise (ATP) across time and place.
Multi‑warehouse. You might have DCs, branches, and third‑party stock.
Safety stock and allocations. You reserve for key customers or projects.
Work‑in‑process and lead times. Items are inbound or made‑to‑order.
Substitutions and kits. Sell A now, ship A or B later if needed.
If the ERP runs the allocation rules, the site must read those rules, not guess. Batch feeds every 24 hours are too slow. But you also don’t need real‑time for everything. Most teams win with a near‑real‑time mix: event‑driven updates for changes, plus frequent reconciliation batches to heal drift.
What good looks like: The ERP (or OMS tightly coupled to it) exposes a StockStatus contract: on‑hand, allocated, ATP by date bucket, location options, and substitution rules. The storefront shows ATP, offers choices, and respects holds and allocations. When inventory moves, a message fires; the site updates in minutes, not days.
Order truth: quotes → orders → invoices, returns, EDI/punchout
B2B orders are not a single click. They are a chain.
Quotes to orders. Quotes carry pricing approvals, expiration, and scope.
Orders to shipments. Splits by line, by warehouse, and by schedule.
Shipments to invoices. Partial billing, freight, surcharges, credits.
Returns. RMAs with reason codes and dispositions (restock, scrap, repair).
EDI and punchout. External systems submit orders that must look identical to ecommerce orders in the ERP.
If the ERP is the source of order truth, the site should treat it as such. Don’t let the storefront invent states the ERP doesn’t have. Don’t let the ERP create events the storefront can’t observe.
What good looks like: A clear OrderEvent contract: ORDER_ACCEPTED, ALLOCATED, PARTIAL_SHIPPED, BACKORDERED, INVOICED, REFUNDED, RMA_CREATED, RMA_CREDITED. Analytics listens to these events. Customer service sees the same timeline the customer sees. No more “GA says it’s an order, but accounting says it isn’t.”
ERP‑native commerce: the operating model comes first
Here’s the shift: stop treating ecommerce as a separate stack you bolt to the ERP. Treat ecommerce as a native channel of your ERP operating model. That doesn’t mean you run your storefront inside the ERP UI. It means the ERP owns the rules, and the storefront is a first‑class client of those rules.
Call it ERP‑native commerce. The idea is simple:
One source of truth for pricing, inventory, and order state.
Data contracts that define the shape of that truth.
Integration that is event‑driven for changes and batched for reconciliation.
A thin storefront that focuses on UX, not re‑implementing business logic.
This is how you scale complex commerce without endless rebuilds.
Define data contracts before UX
Most teams design wireframes first. Resist the urge. Decide your data contracts first. UX will be faster and cleaner when you know what the system can promise.
Start with three contracts:
PriceResult
Inputs: Customer ID, Item ID, Qty, Date, Channel, Ship‑To, Contract/Quote ID (optional).
Output: Effective unit price, price basis (contract/list/tier), discount components, freight rules, exceptions, expiry date, approver (if any).
Guarantees: Idempotent for the same inputs and time window. Versioned when rules change.
StockStatus
Inputs: Item ID, Location (optional), Date needed, Customer class (for allocations), Substitution policy.
Output: ATP now, ATP by date bucket, location options with lead times, reservation eligibility, backorder rules.
Guarantees: Emits change events when ATP crosses thresholds; reconciles nightly.
OrderEvent
Inputs: Order ID.
Output: Append‑only timeline of states with timestamps and actor/source.
Guarantees: States are finite and well‑named. No “custom” statuses that break reporting.
When you lock these down, you unlock speed. Checkout becomes simple. PDP and PLP logic becomes consistent. Customer service gains superpowers. And your analytics stops arguing with accounting.
Align Sales + Ops + IT on “one source of truth”
You can’t solve this with code alone. You need alignment.
Sales agrees to use the same pricing truth the site uses. If a rep can override, the override is done through the ERP or pricing engine, not in email.
Ops agrees to maintain inventory and allocations in one place. No shadow spreadsheets.
IT agrees to publish stable contracts and events. No breaking changes without notice.
Create a simple RACI for the three truths. Name the data owner for each. Add change management. When a rule changes, the owner updates the ERP, the message bus emits an event, and the site updates. End of story.
Fast path to results (without a rebuild)
You do not need to rip and replace your site to fix this. You need a short, focused push that stabilizes truth and removes workarounds. Here’s a 90‑day plan we run when ecommerce operations need a reset.
90 days: stabilize truth, remove workarounds, unlock quick wins
Weeks 1–2: Diagnose and decide
Inventory the current flows for pricing, inventory, orders, and returns.
Map every manual touch point. Count the touches.
Choose one source of truth for each domain. No split brain.
Draft the three data contracts (PriceResult, StockStatus, OrderEvent).
Decide batch vs near‑real‑time by domain:
Pricing: compute on demand; cache results; nightly reconciliation.
Inventory: event‑driven for changes; hourly batch to heal; daily guardrail checks.
Orders: event‑driven for state changes; daily invoice sync to finance data mart.
Pick KPIs (see “What to do next”). Baseline them now.
Weeks 3–6: Pricing
Publish the PriceResult API or stored procedure.
Migrate the site to call it at cart/checkout and for contract customers at PDP.
Remove price tables from the storefront.
Add a price‑mismatch alert: if the site and ERP disagree by >0.5%, flag it.
Roll training for reps: how to create quotes that feed the site and hold prices.
Weeks 7–10: Inventory
Publish StockStatus. Show ATP by date and location.
Turn on event‑driven updates when receipts, picks, or allocations change.
Implement simple backorder messaging with dates, not “out of stock.”
Add split‑shipment rules driven by ERP flags, not theme code.
Pilot substitutions on 10 SKUs with clear rules.
Weeks 11–13: Orders and returns
Emit OrderEvent states from the ERP or OMS. Pipe them into the storefront and analytics.
Align the “order success” moment across GA, ERP, and finance reporting.
Stand up a simple RMA flow that mirrors ERP reason codes and dispositions.
Publish a customer‑visible order timeline that reads the same events customer service sees.
Quick wins you’ll feel:
Fewer price escalations.
Fewer “where is my order?” calls, because the timeline is clear.
Higher conversion for contract customers because they trust the numbers.
Cleaner analytics that line up with finance.
Mini case notes (anonymized)
Industrial distributor, 12 DCs: Reduced manual entry 60% while online revenue grew 18%. Conversion for contract customers rose 24% after moving pricing to an ERP‑native API.
Building materials manufacturer: Cut “out‑of‑stock but actually in stock” tickets by 72% in six weeks by switching to event‑driven ATP and showing dates for backorders.
Medical supplier with EDI + web: Reconciled GA and ERP within 1.2% variance by standardizing the “order accepted” event and pushing OrderEvent states to analytics.
Diagram: where truth should live
Use this as a mental model. The storefront should not be a second ERP.
┌───────────────────────────────────────────┐
│ ERP / OMS │
│ • Pricing engine (contracts, tiers) │
│ • Inventory (ATP, allocations) │
│ • Order lifecycle (quotes→invoices→RMAs) │
└───────────────┬───────────────┬───────────┘
│ │
PriceResult API StockStatus API
│ │
┌────▼────┐ ┌────▼────┐
│Event Bus│◄────┤ CDC/ETL │ (recon)
└────┬────┘ └────┬────┘
│ │
┌────────────▼───────────────▼──────────┐
│ Integration Layer │
│ • Data contracts & validation │
│ • Idempotency & retries │
│ • Monitoring & alerts │
└────────────┬───────────────┬───────────┘
│ │
┌─────────▼────────┐ ┌───▼───────────┐
│ Storefront(s) │ │ Other Channels │
│ • Web/Mobile │ │ • EDI │
│ • CSR Portal │ │ • Marketplaces│
└─────────┬────────┘ └───────────────┘
│
┌───────▼────────┐
│ Analytics (GA, │
│ Finance, CS) │
│ listens to │
│ OrderEvent │
└────────────────┘
Key idea: Truth lives in the ERP. Contracts make that truth consumable. Events keep everything in sync. The storefront focuses on UX, not business rules.
Checklist: 7 signals your ERP is blocking growth
Score yourself quickly. If you check three or more, your ERP is your growth limiter.
Reps must “fix price” after the web order.
Inventory on the site lags by more than two hours or often lies.
GA and ERP revenue differ by >5% for the same period.
Quotes cannot be converted to web orders without retyping.
Returns don’t reuse ERP reason codes, so credit rules vary.
Price tables live in the storefront or in spreadsheets, not the ERP.
Order statuses are different in every system, and customer service can’t show a single timeline.
If that stung, good. Now you know where to focus.
Batch vs near‑real‑time: a practical way to decide
You don’t need real‑time for everything. You do need predictable freshness.
Use event‑driven for: inventory deltas, order state changes, and contract price approvals. These are small, frequent moments where speed matters to the customer.
Use scheduled batches for: nightly reconciliation of price lists, large catalog updates, and invoice data for finance. Here consistency beats speed.
Guardrails:
Make events idempotent (safe to replay).
Build backpressure handling so spikes don’t topple the site.
Monitor lag as a KPI. “Average inventory update lag < 5 minutes” is a real target.
This is how you get the feel of real time without the cost and risk of trying to make everything instant.
Define KPIs that prove operations are healthy
Tie your KPIs to truth, not vanity.
Manual‑touch rate per order (target: down by 50%+).
Price variance rate between site and ERP (target: <0.5%).
Inventory update lag (target: <5 minutes P95 for deltas).
Fill rate and backorder rate with promised dates.
Self‑serve share of contract revenue (target: up and to the right).
Quote‑to‑order conversion when quotes originate in ERP and finish online.
RMA cycle time from request to credit.
GA vs ERP variance on accepted orders (target: <2%).
When you pick these and baseline them in week two, your 90‑day effort can’t hide behind “feels better.” It shows better.
What this looks like in UX (after the plumbing is right)
When the contracts and events are in place, the site gets simpler and faster.
PDP and PLP show price the customer trusts. No “call for price” for contract items.
Cart shows freight and surcharges based on ERP rules.
Checkout uses quote IDs to lock price and terms.
Account pages show an order timeline that matches what a CSR sees.
Inventory shows “Ships today” or “Ships by Friday from Dallas,” not a scary red “Out of stock.”
Returns let customers pick the same reasons as your ERP. Credits apply the same rules.
Notice what’s missing? Endless “custom logic” in theme code. That logic moved to the system that owns it.
Common objections (and how to resolve them)
“Our ERP can’t do that.”
Often true in its default UI. Less true in its data model or API layer. If the ERP truly can’t, place a thin service beside it that reads the ERP tables and exposes clean contracts. Still treat the ERP as the authority.
“Sales won’t give up overrides.”
They don’t have to. They need to do overrides through the system that everyone can see. Put a fast quote workflow in front of them. Promise speed. Give them credit when they use it.
“Event‑driven is too complex.”
It’s also how your phone gets push notifications. Start small: a single topic for inventory deltas. Measure the win. Add order events next. You don’t need Kafka to get started; you do need a queue and discipline.
“We have to replatform.”
Maybe later. First, stabilize truth. Many teams find that once pricing, inventory, and orders align, the current site works fine for another 18–24 months. If you still want to replatform, you’ll do it faster with clean contracts already in place.
SEO note for the curious
If you found this while searching for B2B ecommerce ERP integration, ecommerce operations, complex commerce, or ERP‑native commerce, you’re in the right place. The themes here are how teams like yours stop fighting their tools and start shipping value.
What to do next
You don’t need a 6‑month study. You need clarity in two weeks and momentum in ninety days.
Start with a 2‑week diagnostic. We map pricing, inventory, and order flows. We document the current data contracts (or the lack of them). We baseline the KPIs that matter.
Decide batch vs near‑real‑time by domain. Price, inventory, and orders have different needs. We design for speed where customers feel it, and stability where finance needs it.
Pick your KPIs and publish them. Manual‑touch rate. Price variance. Inventory lag. GA vs ERP variance. Quote‑to‑order conversion. Self‑serve share. Everyone sees them.
Lock the data contracts. PriceResult, StockStatus, OrderEvent. Version them. Set change control.
Sequence the 90‑day plan. Pricing first, then inventory, then order/returns. Ship wins every two weeks.
Want help standing this up? These three services are built for this exact problem:
ERP‑Native Diagnostic — two weeks to get your score, a current‑state map, and a 90‑day plan.
Strategy Sprint — take the plan and lock scope, sequence, and KPIs with your team.
Executive Alignment Workshop — get Sales, Ops, and IT on one operating model and source of truth.
The bottom line
Most ecommerce problems are ERP problems wearing a mask. When pricing, inventory, and order flows live in one place and speak in clean contracts, the site accelerates. Reps trust it. Customers trust it. Finance trusts it. Growth returns.
CTA: Get a 2‑week ERP‑Native Diagnostic. Walk away with a score, a current‑state map, and a 90‑day plan. Then use that plan to cut manual work, align your numbers, and get growth moving again.
