ERP and e-commerce integrations usually fail because of missing decisions, not missing code. The common pitfalls are undefined data ownership, assuming real-time sync is needed, unmapped order statuses, failures that nobody is alerted to, and tax data handled in the wrong system. Each is avoided by agreeing a written field-mapping specification before any development starts.
Why integration projects fail
Most ERP-to-e-commerce integration failures are governance failures, not technical failures. Connecting two APIs is well-documented work; the hard part is deciding, field by field, which system is allowed to change what, how often, and what happens when something goes wrong.
Projects that start without formal field-mapping documentation, agreed data ownership rules and defined error handling tend to produce integrations that pass a demo with clean test orders and then break on real ones: partial refunds, split shipments, offline payments, bundles and returns. The five pitfalls below are the ones we see most often in Namtech's integration work, and each maps to a decision that belongs in the specification.
Pitfall 1: Undefined data ownership
The most common failure point is letting two systems act as the source of truth for the same data. When stock levels, prices or customer records can be edited in both the ERP and the online store, the integration has no rule for which edit wins, and conflicts compound with every sync cycle.
The fix is to name one master system for each data type and make the other system read-only for that data. A typical split for a business running Odoo or a similar ERP alongside Shopify or WooCommerce looks like this:
| Data type | Usual master system | Direction of sync | Why |
|---|---|---|---|
| Product master (SKU, cost, weight, barcode) | ERP | ERP to store | Purchasing, costing and warehouse operations depend on it |
| Marketing content (descriptions, images, SEO fields) | Store | Not synced, or store to ERP | Edited by the marketing team, not needed for fulfilment |
| Stock on hand | ERP | ERP to store | Receipts, transfers and counts happen in the warehouse |
| Orders | Store (creation), ERP (fulfilment) | Store to ERP, then status back | The customer places the order online; the warehouse ships it |
| Invoices, credit notes and GST | ERP | ERP only | Accounting and tax reporting must come from one ledger |
| Price lists and promotions | Agree explicitly | One direction only | Often contested between finance and marketing; decide before build |
The exact split varies, but the rule does not: every field in the mapping has exactly one owner. Inventory deserves particular care because platforms model stock in more than one state. Shopify, for example, distinguishes available stock from committed stock, and its documentation explains that when an order is placed it decrements the available quantity and increments the committed quantity (Shopify inventory states). If the ERP pushes an on-hand figure into a field the store treats as available, unfulfilled orders get counted twice.
Pitfall 2: Real-time sync assumptions
Real-time bi-directional sync is rarely necessary, and assuming it is adds cost and failure points without a matching business benefit. Real-time sync multiplies API calls, increases the error surface and makes failures harder to diagnose, because problems appear as intermittent mismatches rather than a single failed batch.
In our experience, most SME operations are well served by scheduled sync at 15–60 minute intervals (Namtech guidance) with defined conflict-resolution rules, reserving near-real-time updates for the few flows where minutes matter, such as stock on fast-selling SKUs during a campaign.
Where event-driven updates are used, design for imperfect delivery. Shopify's documentation says it does not guarantee ordering within a webhook topic or across topics for the same resource, recommends using timestamps to organise events, and advises apps not to rely on receiving every webhook, using reconciliation jobs that periodically fetch data instead (Shopify webhooks overview). APIs are also rate-limited: Shopify enforces most limits with a leaky bucket algorithm, and if the bucket fills the app receives a throttle error and must wait (Shopify API limits). A large initial product or stock load therefore needs batching and retry logic, not a single loop.
| Approach | Best for | Main risk | Mitigation |
|---|---|---|---|
| Scheduled batch sync | Products, prices, stock on most SKUs, settled orders | Data is minutes old | Pick an interval the business can live with; show last-sync time |
| Event-driven (webhooks) | New orders, cancellations, refunds | Missed, duplicated or out-of-order events | Idempotent handlers, timestamp checks, periodic reconciliation |
| Hybrid (webhooks plus nightly reconciliation) | Most growing online retailers | Two mechanisms to maintain | Reconciliation report reviewed by a named owner |
Pitfall 3: Order status mapping gaps
E-commerce order statuses do not map one-to-one to ERP fulfilment and accounting steps, so the mapping has to be written down explicitly. Labels such as "processing" or "refunded" carry platform-specific meanings and side effects that an ERP will not infer.
WooCommerce is a good illustration. Its documentation defines Processing as payment received with stock already reduced, On hold as awaiting payment confirmation with stock reduced, and Failed as a declined payment, at which point previously reduced stock is returned to inventory (WooCommerce order statuses). If the ERP also deducts stock on order import, every order is deducted twice. Shopify, by contrast, exposes separate financial and fulfilment status fields on the order rather than one combined status (Shopify Order object), so a mapping has to consider both.
An example mapping for WooCommerce to an ERP sales flow (illustrative; adjust to your own fulfilment process):
| WooCommerce status | Platform meaning | Example ERP action |
|---|---|---|
| pending | Order received, no payment yet | Do not create a sales order, or create it as a draft quotation |
| on-hold | Awaiting payment confirmation; stock reduced | Create sales order but block delivery until payment is confirmed |
| processing | Paid; stock reduced; awaiting fulfilment | Confirm sales order and create the delivery; do not deduct stock a second time |
| completed | Fulfilled | Usually set by the ERP once the delivery is validated, then pushed back to the store |
| cancelled | Cancelled by admin or customer; stock returned | Cancel the sales order and any open delivery |
| refunded | Payment refunded | Issue a credit note; decide whether goods return to stock |
| failed | Payment declined; stock returned | No sales order, or cancel the draft |
The edge cases are where integrations break: partial refunds, partial shipments, orders edited after payment, and exchanges. Each needs a row in the specification, even if the agreed answer is "handled manually and flagged to the operations team".
Pitfall 4: Silent failures and missing alerts
An integration without monitoring fails silently, and the business usually discovers it from a customer complaint or a month-end reconciliation. Error handling is a requirement, not a later improvement.
Platform behaviour makes this concrete. WooCommerce automatically disables a webhook after more than five consecutive delivery failures, where 4xx or 5xx responses count as failures (WooCommerce webhooks). A short ERP outage can therefore stop order delivery entirely until someone re-enables the webhook. Shopify recommends verifying signatures and ignoring duplicate deliveries using the X-Shopify-Webhook-Id header (Shopify webhooks overview), which means handlers must be idempotent so a resent order does not create a second sales order.
A minimum error-handling design includes:
- a log of every inbound and outbound message with its status;
- automatic retries with a cap, then a queue of failed records for human review;
- an alert to a named person, by email or chat, when failures exceed an agreed threshold;
- a daily reconciliation report comparing order counts, totals and stock between systems; and
- a documented procedure for replaying failed records after an outage.
Pitfall 5: Tax and invoice data in the wrong system
Invoices, credit notes and GST should be produced by the ERP, not by the online store, because the ERP is where accounting and tax reporting live. When the store generates its own invoices and the ERP generates another set, the two rarely reconcile cleanly once refunds and discounts are involved.
For Singapore businesses this matters more each year. IRAS states that all GST-registered businesses must submit invoice data to IRAS using InvoiceNow-Ready Solutions, rolled out in phases: from 1 November 2025 for companies registering voluntarily within six months of incorporation, from 1 April 2026 for any business applying for voluntary GST registration, and from 1 April 2028 onwards for newly compulsory registrants and existing registrants by turnover band (IRAS GST InvoiceNow Requirement). An integration that keeps invoicing in the ERP puts the business in a better position to meet this from one system. Check whether your accounting software is on IMDA's accredited InvoiceNow-Ready Solutions list, which the IRAS page links to.
The correct approach to integration architecture
An ERP-to-e-commerce integration should begin with a formal data-mapping workshop whose output becomes the integration specification. Development, testing and acceptance are then measured against that document rather than against verbal expectations.
| Specification section | What it must define |
|---|---|
| Field map | Every synchronised field, its source and target field names, and any transformation |
| Ownership | The master system for each data type, and which system is read-only |
| Direction and frequency | Sync direction per field; batch interval or event trigger per flow |
| Status mapping | Every platform order status and edge case, mapped to an ERP action |
| Error handling | Retries, failure queue, alert recipients and thresholds, replay procedure |
| Reconciliation | Which totals are compared, how often, and who reviews the report |
| Tax and invoicing | Which system issues invoices and credit notes, and how GST is calculated |
| Test cases | Realistic scenarios: partial refund, split shipment, offline payment, bundle, return |
Two technical choices are worth settling in the same workshop. First, use the API the platform intends for new work: Shopify describes its REST Admin API as legacy and requires new public apps to use the GraphQL Admin API (Shopify REST Admin API reference). Second, confirm how the ERP side will be accessed; Odoo, for instance, documents external access to its models over XML-RPC (Odoo External API), and connector modules build on that layer.
Namtech Pte Ltd, a Singapore AI transformation consultancy, runs this workshop as the first step of its Odoo ERP implementations and e-commerce builds. If you are still choosing an ERP, our guide to ERP for Singapore SMEs covers the selection stage.
Integrations that work in testing and fail in production are almost always missing a written specification of who owns each field, when it moves and what happens when it fails.