Ecommerce ERP Integration: How to Connect Your Store With Your ERP
How ecommerce ERP integration works: which data flows where, field ownership, sync patterns, middleware, webhooks, error handling, reconciliation and testing.
Quick answer
Ecommerce ERP integration connects the store and the ERP so products, prices and stock flow to the store, and orders, customers and payments flow to the ERP, with fulfilment status, tracking and invoices returning. Define which system owns each field, choose timing per data type (events for orders and stock, schedules for catalogs and prices), use middleware for mapping, queues, retries and logging, treat webhooks as unreliable and reconcile regularly, respect API limits and test failure scenarios, not just the happy path.
What an ERP Does for Ecommerce
The ERP is usually the operational and financial system of record: items, costs, stock across locations, purchasing, orders from all channels, invoicing and accounting. The store is where customers browse and buy. Without integration, staff re-key orders, stock drifts out of sync and finance reconciles by hand. The diagram above shows the data flows and the integration layer between the systems. For B2B-specific data such as contract pricing and credit, see B2B ERP integration.
Data Flows
| Data | Direction | Typical timing |
|---|---|---|
| Products and SKUs | ERP / PIM → store | Scheduled, on change |
| Prices | ERP → store | Scheduled |
| Inventory | ERP / WMS → store | Frequent or event-driven |
| Orders | Store → ERP | Near real time |
| Customers | Store → ERP | With orders |
| Payments and refunds | Store → ERP | With orders / on event |
| Fulfilment and tracking | ERP / WMS → store | On event |
| Invoices | ERP → customer / store | On event or scheduled |
Field Ownership
Most integration problems come from two systems editing the same field. Write down, for every field, which system owns it and which direction it syncs. Product titles might be owned by the store (for merchandising) while SKUs, costs and stock are owned by the ERP. Once agreed, prevent edits in the non-owning system where possible.
Pro tip
A one-page field ownership matrix (field, owner, direction, timing, transformation) prevents more integration bugs than any amount of code review.
Integration Patterns
| Pattern | How it works | Good for |
|---|---|---|
| Native connector / app | Prebuilt integration between platform and ERP | Standard needs, faster setup |
| Integration platform (iPaaS) | Configurable flows, mapping, monitoring | Several systems, moderate customization |
| Custom middleware | Your own service with queues and logic | Complex rules, high volume |
| File-based (CSV/SFTP) | Scheduled file exchange | Legacy ERPs without APIs |
Events, Webhooks and Reliability
Platforms notify integrations of changes through webhooks. Treat them as signals, not guarantees. Shopify's documentation, for example, recommends verifying webhook HMAC signatures, using the webhook ID header to detect duplicates, not relying on delivery order (using timestamps or the resource's updated time instead) and running reconciliation jobs because delivery isn't guaranteed (Shopify developer docs). Respond quickly and process asynchronously through a queue.
on webhook(request):
verify signature(request.rawBody, header) or reject
if seen(request.webhookId): return 200
enqueue(topic, payload, triggeredAt)
return 200
worker:
event = dequeue()
if event.updatedAt <= lastProcessed(event.resourceId): skip
map and send to ERP with retries
on permanent failure: dead-letter + alert
nightly:
reconcile orders and stock between store and ERPPlanning an ERP integration?
ZSpace designs ecommerce ERP integrations with clear ownership, reliable sync and monitoring.
API Limits and Bulk Operations
Both the platform and the ERP limit how fast you can call their APIs. Shopify's GraphQL Admin API uses cost-based rate limits that vary by plan, and the REST Admin API uses a leaky-bucket model (Shopify developer docs). Use bulk operations for large catalog updates, batch writes, back off on throttling and spread scheduled jobs.
Orders Into the ERP
Map orders carefully: customer, addresses, lines, SKUs, taxes, discounts, shipping, payment method, gateway references and channel. Decide how edits, cancellations, partial refunds and exchanges flow. Use idempotency (for example, the store order ID as an external reference) so retries never create duplicate ERP orders.
Mapping an Order: Field-Level Detail
Order mapping is where most ERP projects spend their time. Platforms and ERPs model orders differently: discounts may be order-level in one and line-level in the other, taxes may be per line or per jurisdiction, and shipping may be a line item or a header field. Decide each mapping explicitly and test it with real orders.
| Store field | ERP field | Watch for |
|---|---|---|
| Order ID | External reference | Use for idempotency |
| Customer / email | Customer account or cash-sale customer | Guest orders, duplicates |
| Line SKU and quantity | Item and quantity | Bundles exploding into components |
| Line discounts / order discounts | Line price or discount lines | Allocation of order-level discounts |
| Tax lines | Tax codes and amounts | Rounding differences |
| Shipping | Freight line or header charge | Tax on shipping |
| Payment gateway and reference | Payment method, receipt | Partial captures and refunds |
Worked Example: A Retailer Connecting Shopify to Its ERP
An illustrative scenario, not a client case: a homeware retailer sells on Shopify and in five stores, with an ERP managing stock and finance. The integration runs through middleware. Products and stock flow from the ERP: product changes hourly, stock on every movement via change events plus a full sync each night. Orders flow to the ERP within a minute of payment via order webhooks, queued and processed asynchronously with the Shopify order ID as the external reference. Fulfilments and tracking flow back from the ERP. Refunds created in Shopify post credit notes to the ERP.
A nightly job compares order counts and totals between Shopify and the ERP for the previous day and reports differences. Failures alert the ecommerce operations lead, who owns a runbook for common errors (unknown SKU, closed accounting period, tax mismatch).
Common ERP Integration Mistakes
- No written field ownership, so both systems edit the same data
- Processing webhooks synchronously and timing out
- Retries that create duplicate ERP orders
- Relying on webhook order instead of timestamps
- Ignoring rate limits during bulk updates
- Discovering sync failures from customer complaints
Monitoring and Reconciliation
- Log every message with status and payload reference
- Alert on failures and growing queues with a named owner
- Dead-letter queue for messages that repeatedly fail
- Daily reconciliation of order counts and totals
- Periodic stock reconciliation
- Dashboard of sync lag per data type
Testing
- Orders with discounts, multiple taxes and shipping methods
- Partial refunds, cancellations and exchanges
- Duplicate and out-of-order webhook delivery
- ERP downtime and recovery
- API throttling under bulk updates
- Reconciliation catching deliberately dropped events
Ready to connect your store and ERP?
Talk to ZSpace about ERP integration, Shopify integrations and operations automation.
Conclusion
ERP integration succeeds on discipline: clear ownership, the right timing per data type, reliable event handling, idempotent writes, monitoring and reconciliation. For how ERP fits among other integrations, see ecommerce API integration and Shopify business systems integration.
Related: inventory integration, payment integration and tax integration.
For related guides, see order management integration.
Common questions
Connecting an online store with an enterprise resource planning system so products, prices, inventory, orders, customers, fulfilment and financial data flow between them automatically instead of being re-keyed.