Shopify Plus and ERP Integration: Getting Orders, Inventory, and Finance Right
Most Shopify ERP integrations fail on ownership ambiguity, not technology. Decide the system of record per field first.
Storefront and ERP integration is where e-commerce programmes lose their margin. The build looks straightforward — orders out, inventory in — and then production reveals partial refunds, exchanges, split shipments, pre-orders, bundles, and tax edge cases that nobody scoped.
The technology is rarely the constraint. Ownership decisions are.
Decide the system of record per field
| Data | Usual owner |
|---|---|
| Product master, SKU, cost | ERP |
| Merchandising content and imagery | Shopify / CMS or DAM |
| Price list and promotions | ERP for base price, Shopify for storefront promotions |
| Inventory availability | ERP or warehouse management system |
| Order capture | Shopify |
| Fulfilment status | Warehouse system, reflected into Shopify |
| Financial records and tax posting | ERP |
| Customer record | Shopify for storefront identity, ERP or CDP for the commercial entity |
Write this table down and have both the commerce and finance teams sign it. Nearly every recurring integration incident traces back to a field with two claimed owners.
Inventory: event-driven with reconciliation
Scheduled full syncs every fifteen minutes produce oversells on fast-moving lines and unnecessary load. Push availability on change instead, apply a small buffer on high-velocity items, and reconcile the full position once daily to catch anything missed.
For multi-location fulfilment, map warehouse locations to Shopify locations explicitly and let Shopify's own allocation logic route, rather than attempting to compute allocation upstream.
Orders: idempotent, queued, and reversible
Order flow is the highest-consequence path. Three requirements are non-negotiable:
- Idempotency. Every order transmission carries a stable key so retries cannot create duplicate ERP orders — the most common and most expensive integration defect.
- Durable queueing. Orders queue when the ERP is unavailable and drain automatically, never dropped.
- A visible error queue. Failures land somewhere a human monitors, with enough context to correct and replay.
Then handle the edge cases deliberately: partial refunds, exchanges that are simultaneously a return and a new order, cancellations after fulfilment has started, pre-orders and backorders, bundles that decompose into component SKUs, and gift cards.
Finance and tax need their own design
Post revenue, tax, discounts, shipping, and payment fees at the granularity finance requires for reconciliation, and reconcile payment gateway settlements against ERP receipts daily. Where you sell across jurisdictions, decide explicitly whether tax is calculated by Shopify, by a dedicated tax engine, or by the ERP — and ensure only one system is authoritative, because discrepancies here become audit findings rather than mere bugs.
Choose the integration architecture honestly
Prebuilt connectors are appropriate for standard flows on standard ERPs and become a constraint quickly if your processes are unusual. Middleware or an integration platform suits complex transformation and multi-system estates. Custom services offer maximum control at the cost of permanent ownership. Choose based on how unusual your processes genuinely are, not on how unusual the business believes them to be — the difference is often the cheapest thing to test in discovery.
Operate it with real observability
Instrument order-to-ERP latency, error and retry counts by flow, inventory drift measured at daily reconciliation, and unfulfilled order age. Alert the operations team, not only engineering — the people who notice a stuck order first are the ones who can act on it commercially while the fix is developed.
Frequently asked questions
What owns what?
ERP typically owns product master, cost, inventory, and finance; Shopify owns storefront presentation, promotions execution, and order capture. Every shared field needs one owner.
How should inventory sync?
Event-driven pushes on change with buffers on fast movers, plus a daily full reconciliation to catch drift.
What causes most failures?
Contested field ownership, missing idempotency causing duplicate orders, no monitored error queue, and unhandled returns, exchanges, and multi-warehouse cases.
Connector or custom build?
Connector for standard processes; middleware or custom where transformation and process complexity genuinely require it.