Short answer: Ecommerce ERP integration keeps your storefront and ERP agreeing about inventory, products, pricing, orders, and customers. The work that determines success is not the code, it is assigning one source of truth per data object and one sync direction per object. Skip that and you get inventory drift, duplicate orders, and a person reconciling both systems every morning.
01. What Ecommerce ERP Integration Actually Is
Strip away the vendor language and an ERP integration is a set of agreements about data. Which system is allowed to change a given field. Which direction that field travels. What happens when the two disagree. The software that moves the records is the easy part; the agreements are what most projects never write down.
The symptom of a missing agreement is familiar to anyone who has run a distribution business: the website says four in stock, the warehouse has one, and the customer service team has learned not to trust either number. No amount of sync frequency fixes that, because the problem is that two systems both believe they own the field.
So the useful way to scope an integration is not to ask which platform connects to which. It is to walk the objects one at a time and decide who owns each one. Section 03 is that table.
02. Do You Actually Need One Yet?
Not every store needs an ERP integration, and agencies that tell you otherwise are selling. The honest trigger is not order volume; it is re-keying. If any of these describe your week, the integration is already happening, just performed by a person:
- Someone copies orders from the store into the ERP by hand, or exports a CSV to do it in batches
- Inventory shown online is corrected manually, or padded with a safety buffer to avoid overselling
- Finance reconciles storefront revenue against ERP records as a recurring monthly task
- Customer service checks two systems to answer where is my order
- B2B pricing lives in the ERP but gets re-entered into the store whenever it changes
Price the integration against that labor plus its error rate, not against an abstract efficiency claim. And if none of it applies yet, a scheduled export is a legitimate answer for a while. Integrations bought before the pain is real tend to be maintained by nobody.
03. Source of Truth: The Decision Table
This is the artifact to produce first. One owner per object, one direction per object, written down and agreed by operations and finance before any tooling is chosen.
| Object | Owner | Direction | Notes |
|---|---|---|---|
| Products and catalog | Usually ERP | ERP to store | ERP owns the item master; the store enriches with merchandising fields it alone should write, such as images, descriptions, and SEO copy |
| Inventory | ERP or WMS | ERP to store | Never two-way. Decide per location, and decide whether the store sees on-hand or available-to-promise; those are different numbers |
| Pricing | ERP for B2B, store for D2C | Depends | Contract and tier pricing belongs to the ERP; promotional pricing usually belongs to the store. Splitting them by type prevents overwrites |
| Orders | Store | Store to ERP | The store creates the order; the ERP receives it as the transaction to fulfill and invoice. Needs idempotency so retries cannot duplicate |
| Fulfillments and tracking | ERP or 3PL | ERP to store | Shipment confirmation and tracking flow back so the customer-facing status is accurate without anyone updating it manually |
| Customers and accounts | Split | Two-way, carefully | D2C customers originate in the store; B2B accounts and credit terms originate in the ERP. Match on a stable key, never on email alone |
| Returns and credits | ERP | Two-way | Most often deferred to phase two, and most often the reason phase two happens sooner than planned |
Two rows deserve extra attention. Inventory should almost never be two-way: the ERP or WMS owns it because that is where receiving and adjustments happen. And pricing usually needs splitting by type rather than by system, with contract pricing owned by the ERP and promotional pricing owned by the store, so neither overwrites the other.
04. Sync Frequency: Real Time Is Not Always the Answer
Teams ask for real-time everything, then discover that real-time everything means constant API traffic, rate limiting, and a system that is less predictable than a scheduled one. Frequency should follow the cost of being wrong.
- Thin-stock fast movers: near real time, because the cost of overselling is a cancelled order, a refund, and a customer who does not return
- Deep-stock or made-to-order items: scheduled batches measured in minutes or hours are entirely sufficient
- Orders: event-driven, pushed as they happen, because the warehouse cannot pick what it has not received
- Product and pricing data: scheduled, with an on-demand trigger for urgent changes
- Fulfillment and tracking: event-driven back to the store so customer-facing status is never stale
One more distinction worth settling early: does the store display on-hand quantity or available-to-promise? They are different numbers once you have allocated stock, open transfers, or B2B reservations, and showing the wrong one is a quiet source of overselling.
05. The Five Ways Integrations Break
These are the recurring causes behind integration work that gets rebuilt rather than extended.
No defined source of truth.
Both systems can write the same field, so the last writer wins and the value flips depending on timing. This is not a bug you can fix in code; it is a data model decision that was never made. Assign one owner per object before anyone writes an integration flow.
SKU mismatch between systems.
The store calls it BLU-LRG-01, the ERP calls it 100234. Without a clean key mapping, records silently fail to match and updates land nowhere. Reconciling identifiers is unglamorous prerequisite work, and skipping it is the most common reason a technically finished integration does not work.
No idempotency on order creation.
A timeout on the ERP side triggers a retry, the retry creates a second order, and now finance has a duplicate to unwind. Every write operation needs an idempotency key so the same event processed twice produces one record, not two.
API rate limits treated as an edge case.
Both Shopify and ERP APIs throttle. An integration that ignores limits works in testing with 50 records and falls over on a full catalog sync or a Black Friday order spike. Design for queueing, backoff, and batch windows from day one rather than patching after the first incident.
Silent failure.
The sync stops and nothing alerts. Nobody notices until a customer orders something that is out of stock or an order never reaches the warehouse. Alerting on sync failures, and on the absence of expected syncs, is the cheapest insurance in the entire project.
When orders specifically stop arriving where they should, the diagnosis path is narrower than it looks; we covered it in seven reasons orders fail to reach your sales pipeline.
06. Connector, iPaaS, or Custom Build
Three viable paths, and the right one depends on how standard your data model is rather than on how large your business is.
Prebuilt connector or ERP-vendor native
Fastest path when your flows are standard and your ERP has a mature Shopify connector. Cheapest to license and quickest to launch; the constraint is that you can only do what the vendor exposes, so unusual logic becomes a workaround.
iPaaS platform
The common middle ground: prebuilt flows for the standard objects plus the ability to customize and add systems (3PL, WMS, marketplaces) later. You pay an ongoing platform cost, and you inherit a mapping layer somebody has to own internally.
Custom build on the APIs
Right when your business logic is the differentiator: contract pricing per account, allocation rules, kitting that exists in one system only, or multi-entity ERPs. Highest control, and you own reliability engineering: retries, queueing, monitoring, and rate limit handling.
A practical test: inventory your actual flows, then count what percentage a prebuilt option covers. High coverage means buy and extend. Low coverage on the flows that matter most to revenue means build. We publish how we approach each ERP on the Shopify ERP integration hub, including NetSuite, Dynamics 365 Business Central, SYSPRO, and Acumatica.
07. Scoping It: Six Steps Before Anyone Writes Code
Write down the source of truth per object
One line each: who owns products, inventory, pricing, orders, fulfillments, customers, returns. This single document prevents more integration defects than any amount of code review, and it is the artifact most projects skip.
Clean the identifiers on both sides
SKUs, customer keys, and location codes must reconcile before anything syncs. Expect to find duplicates, retired items still active, and products that exist in one system only. Doing this first is what separates an integration that works from one that technically runs.
Define sync frequency by risk tier
Segment the catalog: thin-stock fast movers get near-real-time inventory, deep-stock items get scheduled batches. Orders should be event-driven. Applying one frequency to everything is how teams hit rate limits and pay for capacity they do not need.
Decide connector, iPaaS, or custom
Test the prebuilt options against your actual flows and count the percentage covered. Buy and extend when coverage is high; build when your differentiating business logic is the part the connector cannot express. This decision is cheaper to make with a flow inventory in hand.
Build the error path before the happy path
What happens when the ERP is down, a record fails validation, or a webhook is missed? Retry logic, a dead letter queue, and alerting are not phase two. They are the difference between an integration you trust and one you check manually every morning.
Run parallel before you cut over
Let the integration run alongside the existing manual process for a defined period and reconcile the two daily. Discrepancies found in parallel are cheap; the same discrepancies found after cutover are customer-facing.
08. Where the CRM Fits
ERP integration projects tend to treat the CRM as out of scope, which is a missed opportunity, because the same order data being mapped for the ERP is what makes a CRM useful for a commerce business. The clean division of responsibility looks like this: the ERP owns the transaction, the store owns the buying experience, and the CRM owns the relationship.
For B2B distributors that split matters more than it sounds. Account managers need order history, reorder frequency, and account-level spend where they already work, not in an ERP screen they need a license and training to open. That is the case for syncing order data to the CRM alongside the ERP flow; our Shopify HubSpot integration guide covers exactly what moves and what does not.
If you are replatforming and integrating at the same time, sequence matters: design the integration before cutover rather than after, because order flow gaps between the storefront and the ERP are the most expensive class of post-migration bug. Both the Magento and WooCommerce guides cover where that fits in the project plan.
09. Frequently Asked Questions
What is ecommerce ERP integration?+
When does a business actually need an ERP integration?+
Which system should own inventory, the store or the ERP?+
How often should inventory sync between ecommerce and ERP?+
Should we use an iPaaS platform or build a custom integration?+
What are the most common ERP integration failures?+
How long does an ecommerce ERP integration take to implement?+
Still reconciling your store against your ERP by hand?
eSolve builds Shopify to ERP integrations for distributors and manufacturers: NetSuite, Business Central, SYSPRO, Acumatica, and custom builds where the logic demands it. Book a 30-minute assessment and we will map your source-of-truth table with you.