ERP and eCommerce Integration: What Actually Breaks

A 60-SKU apparel brand running Shopify Plus alongside NetSuite discovered, three weeks after launch, that returns processed through Shopify weren't decrementing inventory in NetSuite. Customer service kept promising refunds for items the warehouse had already restocked, while the ERP still showed them as sold. The integration worked fine for orders flowing one direction; it just never accounted for the reverse flow. That's a common failure mode, and it points at the real question worth asking before connecting an ERP to an online store: not "can these two systems talk to each other," but "which specific transactions need to sync, in which direction, and how fast."

What syncing an ERP to an online store actually involves

Four data flows typically need to move between the two systems:

• Inventory levels, ERP to storefront, so the site doesn't sell what isn't in stock.
• Orders, storefront to ERP, so fulfillment, invoicing, and revenue recognition happen in one place.
• Product and pricing data, usually ERP to storefront, though some businesses manage merchandising content (photos, descriptions) directly on the storefront side and only push SKU, price, and tax code from the ERP.
• Returns and refunds, storefront to ERP, and this is the flow most integrations get wrong, as the apparel brand above found out.

Each of those flows can run on a different sync frequency. Inventory usually needs to be close to real time, especially for anything selling close to zero stock. Product data can safely batch-sync overnight. Orders typically sync within minutes so fulfillment isn't delayed.

The three integration approaches, and when each makes sense

Native connectors

Most major platforms, Shopify, BigCommerce, WooCommerce, have a pre-built connector for the larger ERPs (NetSuite, Business Central, Acumatica). These cover the four flows above out of the box and are the right starting point for a single-storefront business with fewer than a few thousand SKUs. The tradeoff is limited flexibility: if your return workflow or tax logic doesn't match the connector's assumptions, you're stuck waiting on the vendor's roadmap or paying for custom development anyway. Most native connectors also lag a step behind each platform's own release cycle, so a new Shopify checkout feature or a NetSuite bundle update can sit unsupported for weeks before the connector vendor catches up.

Integration platforms (iPaaS)

Tools like Celigo, Boomi, or Workato sit between the ERP and the storefront and let you build custom field mappings and conditional logic. For example, routing B2B wholesale orders differently from D2C retail orders even though both come through the same Shopify instance. This is the right layer once you're running multiple sales channels (a storefront plus Amazon plus a wholesale portal) into one ERP, because building and maintaining three point-to-point connectors gets expensive fast.

Custom API integration

Building directly against both systems' REST APIs makes sense only when the business logic is genuinely unusual: subscription billing with prorated mid-cycle changes, or a marketplace model where the storefront needs to see multi-warehouse inventory in real time. Custom integration is also the most expensive to maintain, since every API version bump on either side is now your team's problem instead of a vendor's.

Where these integrations actually fail

Beyond the returns-sync gap above, three failure patterns show up repeatedly:

1. Tax code mismatches. The storefront calculates sales tax one way (often through a service like Avalara built into the platform), and the ERP posts revenue using a different tax jurisdiction table. Reconciling the two after the fact at month-end is a known source of late closes.
2. Partial shipments and split orders. An order for three items that ships in two boxes from two warehouses needs the ERP and storefront to agree on how to represent that as one order with two fulfillment records, not two separate orders. Native connectors handle this inconsistently.
3. Bundle and kit SKUs. A storefront selling a "starter kit" as one SKU has to decompose that into its component items for ERP inventory to decrement correctly. If the mapping isn't built explicitly, kit sales silently overstate inventory on the individual components.

Budgeting for the integration itself

The integration layer is routinely underestimated in ERP implementation budgets, because it gets treated as a checkbox ("do they have a Shopify connector? yes") rather than a project with its own scope. For a mid-sized D2C brand, a native connector implementation with standard field mapping typically runs somewhere in the $8,000 to $20,000 range in setup services. Adding an iPaaS layer for multi-channel routing can push that to $30,000 to $60,000 depending on how many custom flows are needed. Those figures sit on top of the ERP license itself, so it's worth running the combined number through an ERP TCO calculator before committing to a go-live date, since integration overruns are one of the more common reasons launches slip.

A practical sequencing checklist

• Map all four data flows (inventory, orders, product/pricing, returns) before selecting a connector, and confirm the connector actually covers returns. Many vendor demos skip this flow entirely.
• Run a parallel test period of at least two full weeks with real order volume before cutting over the storefront's live inventory feed.
• Assign one system as the source of truth for each data type in writing, so when the two disagree, there's no ambiguity about which number is correct.
• Test the return flow specifically, including partial returns and exchanges, since that's where the apparel brand above got burned.
• Confirm how each system represents a canceled or edited order after the sync has already fired once, since order edits are a common second failure point right behind returns.

Staging environment testing

The apparel brand's returns-sync gap would likely have surfaced in a proper staging test, but many small integration projects skip this step to save time and budget. A staging or sandbox environment, most ERPs and most storefront platforms offer one, lets you run a full order lifecycle (order placed, partially shipped, returned, refunded) against test data without touching live inventory or live customer records. Running at least 20 to 30 varied test transactions through a staging environment, covering standard orders, partial shipments, bundle SKUs, and returns specifically, catches the majority of mapping errors before they reach a real customer.

Who owns the integration after launch

An integration that works at launch doesn't stay working on its own. Platform updates on either side, a Shopify API version deprecation, a NetSuite bundle update, can silently break field mappings that were fine the day before. Most teams underestimate this and treat integration as a one-time project rather than an ongoing responsibility. Before go-live, it's worth deciding explicitly who monitors the integration (an internal admin, the implementation partner on a support retainer, or the iPaaS vendor's monitoring dashboard) and what the escalation path looks like when inventory sync silently stops. A silent failure here is worse than an outright error message: orders keep coming in through a storefront showing stock that's actually gone.

ERP and eCommerce integration is not a yes-or-no proposition. The technology to connect the two has existed for over a decade. What fails is scoping the integration as a single generic task instead of four separate data flows, each with its own direction, frequency, and edge cases.