eCommerce ERP Integration: Scope It and Fix Sync Failures

It is 8:40 on a Tuesday. The warehouse has no picks on its screens, the ERP shows no web orders since 7:58 yesterday morning, and the store says 312 orders came in between. Nothing threw an error. The order export simply stopped, and the first person to notice was the warehouse lead asking where the work went.

That morning is what a failing eCommerce ERP integration looks like, and it is the part most guides skip. This guide covers both halves: how to choose and scope the connection between your store and your ERP, and what to check when orders, stock, and prices stop syncing after go-live, including who should own the fix.

eCommerce ERP integration connects your online store to the system that holds inventory, pricing, orders, and financial records, so those four things stay accurate in both places without anyone retyping them. The work splits into a purchased connector, an iPaaS middleware layer, or a custom API build. Which one you need depends far less on your ERP brand than on how your catalog, warehouses, and pricing rules actually work.

Overview

• eCommerce ERP integration keeps products, prices, stock, orders, and customer records consistent between the store and the ERP, using a connector, an iPaaS layer, or a custom API build.
• Scope is set by four data flows and by how unusual your warehouse, pricing, and tax rules are, more than by the ERP brand.
• Live syncs usually fail for five reasons: stalled queues, mapping errors, API rate limits, expired credentials, and timing gaps. Each one needs monitoring and a named owner.

What is eCommerce ERP integration?

eCommerce ERP integration is a two-way data flow between a storefront and an ERP system. Orders and customer records move from the store to the ERP. Stock levels, pricing, product data, and fulfillment status move back. The integration runs either on a vendor connector, an iPaaS platform, or custom code against the ERP’s API, and the right choice depends on how complicated your data is rather than on the size of your business.

Most stores already have some version of this. A nightly CSV export is an integration. So is a member of the finance team checking two screens. The question is rarely whether to integrate, and more often how much of the manual layer you can remove before the cost of removing it exceeds the cost of living with it.

Our wider guide to Magento integrations covers the other systems a store connects to. This one stays on the ERP side. If you already know your platform pair, our integration directory has a page for each one, from Magento SAP integration to Magento NetSuite integration and Shopify SAP integration.

The four data flows that decide the scope

Four flows account for almost all the work in an eCommerce ERP integration, and the scope of a project is set by which of them you need and how complex each one is in your business. Products and pricing, inventory and availability, orders and fulfillment, customers and accounts. A store that needs one-directional product data is a different project from a store that needs real-time multi-warehouse availability, even when both run the same ERP.

Products and pricing. Product data flows from the ERP or a PIM into the store. The difficulty is rarely the transfer. It is the mapping, because ERPs store products the way finance and operations need them, and storefronts need them the way customers browse them.

Inventory and availability. Simple on a single warehouse and genuinely difficult across several. What the store shows is the output of an allocation rule, and those rules are often encoded in the old integration rather than in either system.

Orders and fulfillment. Orders go out, status comes back. Custom order statuses are where this breaks, because almost every store has statuses the ERP has never heard of. The carrier and warehouse side of the same flow is covered in our guide to shipping and fulfillment integration.

Customers and accounts. Straightforward for B2C. For B2B this carries account hierarchies, credit limits, negotiated pricing, and approval workflows, which is why B2B ERP integration is consistently the larger project.

Which ERP fits which platform

There is no single best ERP for eCommerce. The practical question is which ERP your business already runs or is committed to, and how mature its integration path to your platform is. SAP, Microsoft, and Oracle carry the deepest ecosystems. The Nordic and Israeli systems dominate their home markets and are frequently better fits for European mid-market operations, even though they appear in fewer international comparisons.

The pattern worth noticing is that the storefront work does not vary as much as the ERP brands suggest. The four data flows are the same. What changes is the API maturity, the authentication model, and how much of your business logic is already inside the ERP rather than in a layer somebody built years ago. The same ERP on a different platform is a different project, which is why Dynamics NAV alone has its own page for Shopify, BigCommerce, Salesforce, and commercetools stores. For the full list by platform, start from the Magento ERP integration or Shopify ERP integration directories.

What breaks during the build

Four failure modes account for most of the pain while an eCommerce ERP integration is being built, and none of them appear on a connector’s feature list. Multi-warehouse stock accuracy, tax code mapping, custom order status handling, and undocumented business logic in the old integration. Each is invisible in a demo environment and obvious in production, usually within the first two weeks, because they surface only at real order volume against real edge cases.

Multi-warehouse stock accuracy

If you fulfill from more than one location, the number your store displays is the output of an allocation rule. Rebuild that rule deliberately or you will oversell within days. This is the single most common reason an integration that passed testing fails in its first week.

Tax code mapping

Storefronts calculate tax at the cart. ERPs calculate it at the invoice. When the mappings drift, the difference shows up as a reconciliation problem in finance instead of an error in the store, which means nobody notices for a month.

Custom order statuses

Partially shipped, awaiting stock, on hold for credit check. These rarely map one to one, and the failure presents as a customer receiving the wrong email at the wrong moment, absorbed by your support team before anyone logs it as a bug.

Undocumented logic in the old integration

The most expensive item on this list. Rules that exist in neither system, encoded years ago in a connector or a middleware script by somebody who has since left. They are discovered during parallel running, which is the worst possible moment.

Connector, iPaaS, or custom build

Buy the connector when your setup is close to standard. Use iPaaS when you are connecting several systems and want one place to manage them. Build custom when your allocation rules, B2B pricing, or multi-market tax logic are the reason your business works the way it does. Most stores end up with a hybrid, using a connector for the standard flows and custom work in the two or three places the business genuinely differs.

Choose a connector if:

• You fulfill from a single warehouse or use straightforward allocation
• Your catalog uses standard product types without heavy attribute customization
• You operate in one country and one tax regime
• Your order statuses match the platform defaults
• Your ERP and platform are a common pairing with a maintained connector

Choose iPaaS if:

• You are connecting three or more systems, not only the ERP
• You want non-developers to maintain the mappings
• Your data volumes are moderate and latency of a few minutes is acceptable
• You expect the set of connected systems to keep changing

Choose a custom build if:

• You allocate stock across multiple warehouses or retail locations
• You run B2B pricing, customer-specific catalogs, or negotiated rates
• You sell across several tax jurisdictions with different rules per market
• Your current setup contains logic nobody has documented
• You need real-time rather than batched synchronization

That hybrid answer is rarely the one a vendor recommends, because vendors sell whole solutions. It is usually the correct one.

B2B changes the calculation

B2B eCommerce ERP integration is a materially larger project than B2C, because the ERP holds commercial logic the storefront has to reproduce faithfully. Customer-specific price lists, contract pricing, credit limits, account hierarchies, quote-to-order workflows, and approval chains are all held in the ERP and have to surface correctly for a logged-in buyer. Getting any of them wrong is visible to the customer immediately.

scandiweb built this at scale for Bechtle, unifying more than ten isolated internal platforms into a single CRM and eCommerce platform across 16 countries, with automated quote and contract generation running against ERP integrations. The platform now handles over 3 million quotes per month across 500+ admin users on 25+ microservices.

Read more: Tailor-made B2B CRM on top of microservices architecture

For multi-market retail the shape differs. Sportland runs a headless Adobe Commerce storefront across five markets integrated with both ERP and PIM, with 60+ store pick-up options and real-time multi-market analytics. That project saw 1,000+ orders in the first two days and an 80% higher conversion rate from AI merchandising.

Read more: CDP Case Study: Multi-Market Personalization for the Biggest Baltics Sportswear Retailer

How to scope it before you commit

Scoping runs in five stages, and the order matters more than the duration of any one of them. Audit what moves today, map the data model field by field, build against a sandbox with production-shaped data, run both systems in parallel, then cut over with monitoring in place. Teams that compress the audit to save time are the teams that discover undocumented allocation logic during parallel running.

1. Audit what moves today. Every field, in both directions, including the ones nobody remembers configuring. This stage produces the real scope, and it is the deliverable everything downstream is priced from.
2. Map the data model. Decide field by field what maps directly, what needs transformation, and what has no equivalent. The no-equivalent list is the actual work.
3. Build and test against a sandbox. Use production-shaped data, not sample records. Edge cases are the entire point of this stage.
4. Run both systems in parallel. Compare stock, tax, and order status under real volume. Silent failures surface here or they surface in front of customers.
5. Cut over and monitor. Keep field-level monitoring and a retry queue running for the first weeks, because the first genuine anomaly usually arrives during a promotion.

What to gather before the audit starts

You can shorten the first stage considerably by pulling four things together before anyone external looks at it. None of them require a developer.

• A list of every system that currently touches product, stock, order, or customer data, including the spreadsheets. The spreadsheets are usually where the undocumented rules are.
• Your warehouse and fulfillment setup, written out as rules. Which location serves which market, what happens when one runs out, and who decided that.
• Your full order status list as it appears to customers, alongside what each status means operationally.
• Your tax setup per market, including who currently owns the mapping and where it is maintained.

Teams that arrive with these four documented consistently get a tighter scope and fewer surprises during parallel running, because most of what an audit discovers is one of these four written down for the first time.

Why do orders, stock, and prices stop syncing?

A live eCommerce ERP integration usually stops syncing for one of five reasons: a stalled queue, a mapping error, an API rate limit, an expired credential or changed endpoint, or a timing gap between the two systems. In scandiweb’s support work, stalled queues and mapping errors are the two clients raise most, and none of the five shows an error to the shopper.

Work through them in this order. The first four explain most missing orders and prices, and the fifth explains most stock disagreements.

1. A stalled queue or consumer

Most integrations do not send an order the moment it is placed. The store writes it to a queue, and a separate consumer process picks it up and calls the ERP. If that process stops, orders keep arriving and keep waiting. On Adobe Commerce, cron is the default mechanism that restarts consumers, and each consumer processes a set number of messages before it ends, according to Adobe’s message queue documentation. Disable cron during a deployment, or let a server restart leave the consumer down, and the queue grows without a single visible error.

This is the usual answer to “why didn’t yesterday’s orders reach the ERP?” Check three things first: how many messages are waiting, when the last one was processed, and whether the consumer process is running. Then restart it and replay the queue in order, so the ERP receives orders in the sequence customers placed them.

2. Mapping errors

A mapping error happens when the store sends a value the ERP has no match for. A new SKU created in the store before it exists in the ERP, a new tax code, a new payment method, a customer group, a unit of measure, or an order status the ERP has never seen. The ERP rejects the record, and depending on how the integration handles rejections, either that one order waits or every order behind it waits too.

The fix has two parts. Validate records before they leave the store, and move rejected records to a quarantine list so the rest of the queue keeps flowing. The second part matters more, because an integration that stops on one bad SKU holds back every order placed after it.

3. API rate limits

Every ERP and every platform limits how many API calls an integration can make. Microsoft Dynamics 365 Business Central returns HTTP 429 when request limits are exceeded and aborts any request that runs longer than 10 minutes with a 504, according to Microsoft’s API limits documentation. Shopify’s GraphQL Admin API throttles requests by calculated query cost and points large data pulls to bulk operations (Shopify developer docs). NetSuite caps concurrent requests per account, and integrations without their own allocation share what is left, which its governanceLimits endpoint reports.

Rate limits rarely fail on a quiet day. They fail when a full price sync, a stock update, and a promotion’s order volume hit the same API in the same hour. Use delta syncs instead of full reloads, webhooks instead of frequent polling, batched requests, and retries with a growing wait between attempts. Schedule heavy jobs away from trading peaks, and test them under peak load before your Black Friday code freeze.

4. Expired credentials and changed endpoints

When everything stops at the same minute, look at authentication first. OAuth client secrets expire, IT rotates an API user’s password, an ERP update changes an API version, or a platform patch replaces the module the connector depends on. The symptom is a clean break: every flow fails at once, at a timestamp someone can usually match to a change.

Keep a calendar of every credential expiry date, and add an integration test to every platform and ERP update. Store patches are frequent, especially on older Magento versions, which is one more reason to know your release’s support dates on the Magento end of life schedule.

5. Timing gaps between the store and the ERP

“Stock shows available but the ERP says zero” is usually a timing or definition problem, and the connection itself is fine. The ERP may have allocated the last units to a B2B order or a store transfer minutes after the last stock export. Or the two systems count different things: on hand, available, reserved, and allocated are four different numbers, and the integration sends only one of them.

Agree in writing which ERP number the store displays. Then shorten the update interval for fast-moving and low-stock SKUs, or send stock changes as events instead of on a schedule, and hold a small safety buffer on items that oversell.

How do you monitor an ERP integration?

Monitor each data flow on three signals: time since the last successful sync, the number of messages waiting, and the number of records that failed. Set an alert threshold for each during trading hours, and send every alert to a named person rather than a shared inbox that everyone assumes someone else reads.

An integration log records what went wrong after someone goes looking. Monitoring raises the alarm first, so the integration owner hears about a stopped consumer at 8:15 the same morning instead of from the warehouse a day later. Track these for every flow:

• Last successful sync, with an alert when orders wait longer than your threshold during trading hours, for example 15 minutes.
• Queue depth and the age of the oldest message, because a short queue of very old orders is worse than a long queue that is moving.
• Failed and quarantined records, grouped by reason, so a new unmapped tax code shows up as one issue instead of 40 separate errors.
• API responses per hour, counting 429 and 5xx codes, so you see a rate limit approaching before it stops a flow.
• A daily reconciliation, comparing yesterday’s order count and order value in the store against the ERP, plus a stock spot check on your top-selling SKUs.

Reconcile the store against the ERP, not against your analytics, which counts orders differently for its own reasons.

Who owns the integration when it breaks?

One named person should own the integration end to end, even when the fix is in someone else’s system. Without that owner, the platform team shows the store sent the order, the ERP partner shows the ERP never received a valid one, the connector vendor shows its logs are clean, and the orders stay stuck while everyone is right about their own part.

Write this down before go-live, with names, response times, and how to reach each person out of hours. The decisions column matters as much as the fixes, because a new tax code or order status is a business decision, and the integration owner cannot map it until finance or operations makes it.

If no one inside the business can own it, make ownership part of a support contract. Our breakdown of eCommerce website maintenance cost covers what a support retainer should include, and integrations belong on that list, with monitoring and response times stated. For Magento and Adobe Commerce stores, 24/7 Magento support covers the store side of the flow around the clock.

Frequently asked questions about eCommerce ERP integration

What is an ERP system for eCommerce?

An ERP system for eCommerce is the software that holds your inventory, pricing, orders, purchasing, and financial records in one place. The storefront sells, and the ERP is the system of record behind it. Common examples include SAP, Oracle NetSuite, Microsoft Dynamics 365 Business Central, Oracle ERP, Infor, Priority, Visma, and Uniconta. The ERP itself is not customer-facing, which is why the integration between the two matters.

Can you give me an example of ERP integration?

A customer places an order on your store. The order passes to the ERP, which reserves stock, generates the invoice, and queues the shipment. When the warehouse dispatches, the ERP sends the fulfillment status and tracking number back to the store, which emails the customer. Meanwhile stock levels update in both directions continuously, so the storefront never sells something that is no longer available.

Which ERP system is best for eCommerce?

There is no single best one. The right ERP is the one that matches how your finance and operations teams work, and which your business is already committed to. SAP, Microsoft Dynamics 365 Business Central, and Oracle carry the broadest ecosystems. Priority, Visma, and Uniconta are frequently better fits for European mid-market operations. The storefront integration is a consequence of that choice rather than a reason for it.

How long does an eCommerce ERP integration take?

Timelines depend on how complicated the setup is rather than on the ERP brand. A single-warehouse, single-market store on a maintained connector is a short project. A multi-warehouse B2B store with negotiated pricing and several tax jurisdictions is a substantially longer one. The audit stage is what tells you which of those you are, which is why it comes first.

Do we need a connector or a custom integration?

Buy the connector when your fulfillment, catalog, and tax setup are close to standard. Build custom when your allocation rules, B2B pricing, or multi-market logic are the reason your business works as it does. Most stores land on a hybrid, using a connector for standard flows and custom work only where the business genuinely differs.

Why didn’t yesterday’s orders reach the ERP?

Usually because the queue that sends them stopped. The orders are saved in the store and waiting for a consumer process that crashed, was not restarted after a deployment, or stopped when cron was disabled. Check the queue depth and the last processed message, restart the consumer, and replay the waiting orders in sequence. Then add an alert on queue age.

Why does the store show stock the ERP says is zero?

The two systems are reporting at different moments or counting different things. The ERP may have allocated the last units after the most recent stock export, or the store may display on-hand stock while the ERP reports available stock after reservations. Agree which ERP figure the store shows, and sync low-stock items more often.

Who should own an ERP integration?

One named owner should be accountable for the whole flow, from the store’s queue to the ERP’s API, even when fixes happen in other teams’ systems. Platform, ERP, and connector teams each fix their own part, and finance or operations decide new mappings. Write the owners, response times, and out-of-hours contacts down before go-live.

Will ERP be replaced by AI?

No. AI is changing how people interact with ERP data through natural-language querying, forecasting, and anomaly detection, and most major vendors now bundle some version of this. The underlying job of an ERP, holding an auditable system of record for inventory, orders, and finances, is a system-of-record problem rather than a prediction problem. For integration planning, treat AI features as an additional data consumer to account for, not as a reason to delay.

What breaks most often in an ERP integration?

During the build, multi-warehouse stock accuracy, tax code mapping, custom order statuses, and undocumented logic inherited from a previous integration. After go-live, stalled queues, mapping errors, rate limits, expired credentials, and stock timing gaps. None of these produce error messages for the shopper, which is why they typically reach finance, the warehouse, or customer support before engineering.

Getting an eCommerce ERP integration right

An eCommerce ERP integration is a storefront project as much as a finance one, and the parts that overrun are on the storefront side. The four data flows tell you the shape. The failure modes give you a test plan. Monitoring and a named owner keep it working after launch.

When the same flow fails every few weeks, the question changes from how to fix it to whether to keep fixing it. Patch the connector when the failures trace back to one cause, such as a missing mapping or a schedule clash. Rebuild the integration layer when the failures keep moving, because the logic is spread across a connector, scripts, and spreadsheets nobody fully understands. Our introduction to OperaLayer describes one way to build that layer without replacing the systems on either side, and our Magento integration services cover the store-side build.

Patching the connector again or rebuilding the integration layer is a call worth making with the queue logs, mapping tables, and API limits in front of you. Tell us about your stack, and we will help you work out which one your failures point to.

Share on: