Most B2B commerce projects do not fail because of the storefront. They fail because of what is connected to it. Disconnected ERPs, inconsistent pricing data, inventory that updates hours after a transaction, and order workflows that require manual intervention at every step — these are the real reasons digital commerce initiatives underdeliver. We have written about why most B2B commerce integrations fail. This article goes deeper into the specific layer where the failures concentrate: the ERP.
If you are running SAP, Oracle, NetSuite, Microsoft Dynamics, or Infor — and selling to other businesses online — your ERP is the source of truth for almost everything that matters. Pricing. Inventory. Customer accounts. Credit terms. Tax. Order status. The commerce platform is the storefront. The ERP is the business. And the integration between them is the substrate on which every AI, personalization, and self-service ambition will eventually rest or collapse.
Here is what actually has to connect, and how.
The six data domains
Every enterprise B2B commerce integration has to address six core data domains. They are not optional, and the failure modes are different in each.
1. Product data. Master records originate in PIM or ERP, depending on architecture. The integration has to handle creation, updates, deletes, and image and asset references. Cadence: near real-time for new SKUs, hourly or event-driven for changes. Direction: typically PIM/ERP to commerce, with occasional enrichment back from commerce.
2. Pricing. This is where B2B integrations get hardest. List pricing is straightforward. Customer-specific contract pricing, volume breaks, promotion stacking, and entitlement-aware quotes are not. The integration has to support real-time price retrieval at the cart and PDP level, scoped to the authenticated buyer. Cadence: real-time. Direction: ERP to commerce on demand, often via API call rather than data sync.
3. Inventory. The commerce platform needs accurate availability — and "accurate" in 2026 means sub-minute, not nightly. For multi-warehouse operations, the integration also has to handle location-aware inventory, allocation rules, and ATP (available-to-promise) logic. Cadence: real-time or event-driven. Direction: ERP/OMS to commerce.
4. Customer and account records. B2B accounts are hierarchical. A parent company has multiple buying entities. Each entity has multiple users with different permissions, approval thresholds, and shipping addresses. The integration has to maintain those relationships across systems and update them bidirectionally as users self-serve in the portal. Cadence: real-time on changes. Direction: bidirectional, ERP and commerce.
5. Orders. When a buyer places an order, it has to flow into the ERP for fulfillment, billing, and revenue recognition — with all the right account, contract, and tax context. This is rarely a clean handoff. The integration has to validate, transform, and enrich the order, then handle status updates flowing back to the commerce platform. Cadence: event-driven on submission and status changes. Direction: bidirectional.
6. Returns and credits. The most underbuilt domain in most B2B integrations, and the one buyers complain about loudest. Returns require ERP-side processing, credit memo issuance, inventory restock logic, and status visibility back to the buyer. Cadence: event-driven. Direction: bidirectional.
Direction and cadence matter more than format
We have seen integration scopes that catalog every field and every transformation but fail to define direction and cadence rigorously. That is the most common cause of integrations that pass UAT and fail in production.
Direction defines who owns the truth. If both the ERP and the commerce platform can edit a customer record, and you have not defined which wins on conflict, you have built a data drift machine. Pick a system of record per domain. Document it. Enforce it.
Cadence defines what experience the buyer gets. If inventory syncs nightly, you cannot promise real-time availability. If you have promised real-time availability, you have to architect inventory differently. Cadence is not a technical detail — it is a customer-experience commitment.
Point-to-point vs. iPaaS-mediated architecture
We have rebuilt many ERP-to-commerce integrations that were originally built point-to-point. The pattern is familiar: one connector for products, one for pricing, one for inventory, one for orders. Each was reasonable in isolation. Together, they became unmaintainable.
The alternative is an iPaaS-mediated architecture, where an integration platform sits between systems and orchestrates the flows. We use Boomi for the majority of our enterprise integrations, and we have written about why Boomi earns its place for this profile of work. The case is simple: when something breaks — and it will — you have one place to look, one place to fix, one audit trail to follow. How Echidna uses Boomi walks through the patterns in real client environments.
For organizations not yet on an iPaaS, the migration path is straightforward but rarely fast. Plan it as a 6–12 month modernization effort, not a quarter. The benefit is durable: a foundation that supports AI-ready operations, real-time experiences, and the kind of agility your roadmap requires.
Where ERP integrations break
The failure modes we see most often:
- Batch flows masquerading as real-time. A "real-time" inventory sync that fires every five minutes is not real-time when an order is placed in second three.
- Untested error handling. The integration works in the happy path. The first time an order fails ERP validation in production, the team learns there was no retry logic, no alerting, no fallback.
- Implicit assumptions about data quality. The integration assumes ERP customer records are clean. They are not. The integration breaks. Everyone is surprised.
- No audit trail. When something goes wrong — and the buyer is on the phone — there is no way to reconstruct what happened.
- Fragile transformations. A single field change in the ERP schema breaks the integration silently. Nobody notices for two weeks.
These are not exotic failures. They are the standard failures, and they are preventable with the right architecture and partner. Our piece on why enterprise eCommerce integrations fail catalogs them in more depth, and our framework for choosing an integration partner covers what to ask before you sign.
What good looks like
A well-architected ERP-to-eCommerce integration looks like this in production:
- One iPaaS layer mediating all flows between ERP and commerce
- Event-driven where latency matters; batch where it does not
- Defined system of record per data domain
- Transformation logic in transit, not in custom code on either endpoint
- Comprehensive observability: every transaction logged, every failure alerted, every retry tracked
- A clear, documented runbook for the most common failure scenarios
- Regression-tested against ERP and commerce platform updates before each release
You will know it is working when your operations team stops fielding "where is my order" calls and starts proposing new features. That is the signal that the substrate is healthy enough to support what comes next — agentic commerce, predictive reordering, self-service expansion — without buckling.
If your current ERP integration is the bottleneck holding back your commerce roadmap, our team can help. We start with an eCommerce technology assessment that diagnoses where the integration layer is creating drag and what to fix first. Most enterprise teams discover the work is more tractable than they assumed — and the payoff faster than they expected.
FAQ on ERP to eCommerce Integration
Q: How long does an ERP-to-eCommerce integration take?
For an enterprise B2B integration covering the six core data domains — products, pricing, inventory, customers, orders, returns — typical timelines are four to nine months from kickoff to production. The variance is driven less by the commerce platform and more by ERP complexity, data quality at the source, and whether an iPaaS layer already exists. Greenfield integrations move faster than ones replacing fragile point-to-point code.
Q: Do we need an iPaaS like Boomi, or can we integrate point-to-point?
You can integrate point-to-point. We've also rebuilt many of those integrations after they became unmaintainable. For two or three connections, direct integration may be acceptable. For an enterprise B2B environment with ERP, OMS, PIM, CRM, and commerce all needing to talk, an iPaaS pays for itself within the first major schema change you have to absorb without breaking production.
Q: How do we know if our current ERP integration is holding our commerce platform back?A few diagnostic signals: inventory disputes show up in customer service tickets, pricing exceptions require manual ERP lookups, order status lags by hours instead of minutes, releases require freezing data flows, and your ops team can't answer "where did this number come from" without escalation. If two or more apply, the integration layer is constraining what the commerce platform can deliver.