How to Connect Your Ecommerce Store to Your ERP: A Practical Guide (2026)

The hidden cost of disconnected systems

It’s 9 a.m. on a Monday. Your Shopify dashboard shows 47 new orders from the weekend. Your warehouse team is waiting. Your finance lead needs to close last month’s books. And your ERP — SAP, NetSuite, PEAK, Odoo, pick your poison — knows nothing about any of it.

So someone opens a spreadsheet.

They copy order numbers, customer names, SKUs, quantities, and shipping addresses from one system into another. Line by line. For an hour, maybe two. And somewhere in that process, a product code gets transposed, a decimal point shifts, or a duplicate entry sneaks in. By Wednesday, your inventory count is wrong. By Friday, a customer is asking where their order is. By end of month, your accountant is reconciling figures that don’t match, and nobody can explain why.

This is the integration trap — and it quietly costs growing ecommerce businesses thousands of hours and tens of thousands of dollars every year in lost productivity, fulfillment errors, and delayed financial visibility.

The good news: connecting your ecommerce platform to your ERP is a solved problem. It just requires understanding your options clearly before you pick one.

The three integration approaches — and when each makes sense

There is no universal right answer here. The best integration approach depends on your transaction volume, your ERP’s openness to external connections, your team’s technical capacity, and how much customization your business logic requires. Here are the three main paths.

1. Native connectors

Most major ecommerce platforms and ERPs now ship with pre-built connectors or app-store integrations. Shopify has connectors for NetSuite and SAP. WooCommerce has plugins for Odoo. PEAK (popular in Thailand) has integrations with several local ecommerce platforms.

Best for: Small to mid-sized businesses with standard workflows, low order complexity, and no heavy customization requirements.

Pros: Fast to set up (days, not weeks). Low upfront cost. Maintained by the vendor.

Cons: You get what you’re given. Field mapping is often rigid. When your business logic diverges from the connector’s assumptions — and it will — you hit walls fast. Multi-warehouse, multi-currency, multi-tax-jurisdiction scenarios almost always break native connectors.

Bottom line: Start here if you’re under ~500 orders/month and your data is clean. Plan to outgrow it.

2. Middleware platforms

Tools like Make (formerly Integromat), Zapier, and n8n sit between your systems and act as workflow automation layers. You define triggers ("when an order is placed in Shopify") and actions ("create a sales order in NetSuite") and the middleware handles the data ferry.

Best for: Teams that want flexibility without writing full custom code. Good for businesses with moderate complexity and a non-developer operator who can manage workflows.

Pros: Faster than custom development. Visual workflow builders are accessible to non-engineers. Good for prototyping your integration logic before committing to a full build.

Cons: Costs scale with volume (most middleware charges per operation). Real-time sync is limited — most middleware tools poll on a schedule (every 5–15 minutes), which can cause inventory discrepancies during flash sales or high-traffic periods. Error handling and retry logic is often shallow.

Bottom line: A solid middle ground for businesses processing 500–5,000 orders/month. Watch your per-operation costs as you scale.

3. Custom API integration

You build the integration yourself (or hire someone to build it). Your ecommerce platform exposes a REST or GraphQL API. Your ERP exposes an API or accepts data via file import or direct database connection. You write the middleware layer that translates, transforms, and routes data between the two.

Best for: Businesses with complex requirements — multi-warehouse inventory, custom pricing rules, tax compliance across jurisdictions, high-volume flash sales, or tight financial reporting timelines.

Pros: Full control over field mapping, business logic, error handling, and retry strategies. Can handle real-time event-driven sync. Scales cleanly with volume.

Cons: Requires engineering investment upfront. You own the maintenance. If either system’s API changes (and they do), you need to update your integration.

Bottom line: The right choice for businesses processing 5,000+ orders/month, or any business with compliance requirements (VAT, multi-currency, multi-entity) that native connectors can’t handle.

What data actually needs to sync — and what doesn’t

One of the most common mistakes we see is teams trying to sync everything. Every field. Every record. Every event. This creates conflicts, overloads your ERP with noise, and makes debugging a nightmare.

Here is what actually needs to flow between systems in most ecommerce/ERP integrations:

Ecommerce → ERP (outbound from store)

Orders: Order ID, line items (SKU, quantity, price), discounts, shipping method and cost, customer billing/shipping address, payment status, channel (web, marketplace, POS).
Customer records: For B2B ecommerce, customer account data, credit terms, and pricing tier belong in the ERP. For B2C, a lightweight customer reference (ID + email) is usually sufficient.
Returns/refunds: Return merchandise authorization (RMA) events, refund amounts, and restocking instructions.

ERP → Ecommerce (inbound to store)

Inventory levels: Stock on hand per SKU per warehouse. This is the most critical sync and the most time-sensitive — stale inventory data causes overselling.
Product/pricing updates: If your ERP is the system of record for pricing (common in B2B and wholesale), price changes need to flow downstream.
Fulfillment status: Shipping confirmation, tracking numbers, and partial fulfillment events.

What you usually do not need to sync

Raw accounting journal entries (your ERP generates these from the order data)
Customer service notes and CRM history (these live in your helpdesk/CRM, not your ERP)
Marketing data — email opens, campaign attribution, and segmentation belong in your marketing stack

A clean integration syncs the minimum necessary data, at the right frequency, with clear ownership defined for each field in each system.

A practical integration architecture

The most robust ecommerce/ERP integrations follow an event-driven pattern rather than scheduled polling. Here is how it works in practice.

flowchart TD
    EC["🛒 Ecommerce Platform\nShopify / WooCommerce / Lazada / Custom Storefront"]
    MQ["📨 Message Queue / Bus\nRabbitMQ · AWS SQS · Google Pub/Sub\n\n• Decouples producer from consumer\n• Buffers spikes (flash sales, bulk imports)\n• Enables retry on failure without data loss"]
    WO["⚙️ Integration Worker\nOrder Sync\n\nTransforms order payload → ERP schema\nCreates Sales Order in ERP via API"]
    WI["⚙️ Integration Worker\nInventory Sync\n\nPolls ERP every N minutes\nor subscribes to ERP inventory events\n→ pushes updated stock to ecom API"]
    ERP["🗄️ ERP\nSAP · NetSuite · PEAK · Odoo · 弥生 · freee"]

    EC -->|"Webhooks\norder.created / order.updated / refund.created"| MQ
    MQ --> WO
    MQ --> WI
    WO -->|"Create Sales Order via API"| ERP
    WI -->|"Fetch inventory levels"| ERP
    ERP -->|"Stock updates"| WI
    WI -->|"Push stock levels to store API"| EC

Why a message queue matters

When an order is placed in your store, a webhook fires immediately. Without a queue, your integration worker receives that webhook and tries to write to your ERP right now. If the ERP is slow, down for maintenance, or throttling API requests, you lose that event — or your integration crashes.

A message queue decouples the two systems. The webhook payload lands in the queue. Your worker processes it when the ERP is ready. If the write fails, the message stays in the queue and gets retried with exponential backoff. During a flash sale that generates 300 orders in 10 minutes, the queue absorbs the spike rather than hammering your ERP’s API rate limit.

Event-driven vs. polling for inventory

Inventory sync is the hardest part of this architecture to get right. You have two options:

Polling: Your integration worker calls the ERP’s inventory API on a schedule (every 5 minutes, every 15 minutes) and pushes updated stock levels to your ecommerce platform. Simple to implement. The downside is a synchronization gap — if you sell out of a product 3 minutes after the last poll, you will oversell for up to 15 minutes.

Event-driven (webhook/push from ERP): Your ERP fires an event when inventory changes, and your integration worker processes it immediately. Much tighter sync. Requires your ERP to support outbound webhooks or change-data-capture — not all ERPs do, especially on-premise deployments.

In practice: Most businesses combine both. Event-driven for critical inventory changes (out-of-stock events, warehouse receipt confirmations), polling as a safety net to catch anything missed.

Things that go wrong — and how to prevent them

Even well-designed integrations fail in predictable ways. Here are the ones we see most often.

Duplicate records

Cause: A webhook fires, your worker creates a sales order in the ERP, and then the webhook fires again (retried due to a timeout). Your ERP now has two identical orders.

Fix: Make your integration idempotent. Every order event should carry a unique external ID (your ecommerce platform’s order ID). Before creating a record in the ERP, check whether a record with that external ID already exists. If it does, skip or update — never create a duplicate.

Currency and tax mismatches

Cause: Your ecommerce platform stores prices inclusive of VAT (common in Thailand and Europe). Your ERP expects prices exclusive of tax. You pass the wrong figure downstream and your financial reports are off by the tax rate percentage on every single order.

Fix: Establish a canonical data contract before you write a line of integration code. Document exactly which system owns each field, what format it expects, and how taxes are represented. Build the transformation logic explicitly — do not rely on either system to "figure it out."

API rate limits

Cause: A bulk import of 2,000 products triggers 2,000 API calls to your ERP in rapid succession. The ERP throttles you after request 500. The remaining 1,500 fail silently.

Fix: Implement request batching (send 50 records per call instead of 1), add a rate-limiting layer in your integration worker that respects the ERP’s published limits, and use exponential backoff with jitter for retries.

ERP field mapping changes

Cause: Your ERP administrator adds a new required field (say, a cost center code) to the sales order form. Existing orders already have it populated from the UI. But your integration worker doesn’t know about it, so every API-created order fails validation.

Fix: Treat your ERP schema like an external API — monitor it for changes as part of your change management process. Set up alerts when integration writes start failing. Build your field mapping in a configuration layer (not hardcoded) so you can update it without a full deployment.

Timezone and date format collisions

Cause: Your ecommerce platform stores order timestamps in UTC. Your ERP (especially on-premise ERPs common in Japan and Thailand) stores dates in local time without timezone offset. A 10:00 p.m. order on March 24 (UTC) becomes a March 25 order in your ERP, throwing off daily sales reports.

Fix: Normalize all timestamps to UTC at the integration layer. Convert to local time only when displaying to end users.

How Simplico approaches this for clients

At Simplico, we have built ecommerce/ERP integrations across a range of stacks — Shopify to NetSuite, WooCommerce to PEAK, custom storefronts to SAP — for clients across Thailand, Japan, and Southeast Asia.

Our process has a few consistent principles:

Start with a data contract. Before any code is written, we map every field that needs to move between systems: where it comes from, what it’s called in each system, what transformation (if any) is required, and which system wins in a conflict. This document becomes the integration’s source of truth and saves weeks of debugging later.

Build for failure, not just success. The happy path is easy. The hard work is in the error handling — dead-letter queues for messages that fail repeatedly, alerting when error rates spike, dashboards that give your ops team visibility into what’s syncing and what isn’t.

Phase the rollout. We rarely flip the switch from zero to full production sync in one go. We start with read-only sync (pulling data out, not pushing it in), validate the data in a staging ERP environment, then enable writes incrementally — one order type, one warehouse, one currency at a time.

Plan for the ERP you have, not the ERP you wish you had. Legacy ERPs on-premise are a reality for many businesses in our markets. Not every ERP has a clean REST API. Some require flat file imports, SFTP drops, or database-level integration. We work with what’s there rather than requiring a full ERP replacement as a prerequisite.

If your team is evaluating whether to build, buy, or customize an ecommerce/ERP integration, we are happy to talk through your specific stack and requirements. Get in touch with Simplico →

Wrapping up

Connecting your ecommerce platform to your ERP is not glamorous work. There are no viral demos, no AI magic, no "deploy in 5 minutes" promises that hold up in production. But it is some of the highest-leverage engineering investment a growing ecommerce business can make — because every hour your team spends on manual data transfer is an hour not spent on the work that actually grows your business.

The key decisions are straightforward:

If you are small and your workflows are standard, start with a native connector.
If you need flexibility without full custom development, middleware platforms are a reasonable stepping stone.
If you have complex business logic, high volume, or compliance requirements, invest in a proper custom integration built on event-driven architecture with a message queue and idempotent writes.

Whichever path you choose, get your data contract right before you write any code. Everything downstream will be easier for it.

Simplico is a software engineering and product studio based in Bangkok, specializing in AI/RAG applications, ecommerce integrations, ERP connectivity, and mobile development across Thai, Japanese, and English-speaking markets. Learn more at simplico.net.