Shopify and NetSuite integration: a practical guide

The shape of the problem

Shopify is where customers buy. NetSuite is where the business keeps its books, its inventory truth, its purchasing and its fulfillment record. Between them sit six data flows, a set of timing decisions and a long tail of edge cases that only appear in production.

An integration project that starts with connector selection is starting in the wrong place. Start with ownership.

Integration is not a data pipe. It's an agreement about who is right when two systems disagree.

System of record decisions

The six core data flows

1. 01

   Item sync

   Which items publish, how variants map to matrix items, what happens on discontinuation. Usually the flow with the most exceptions.

2. 02

   Inventory sync

   Location mapping, buffers, frequency and how to behave during a flash sale. Oversells cost more than a slightly conservative buffer.

3. 03

   Order sync

   Sales order creation with correct taxes, discounts, shipping and payment references. Must be idempotent — duplicate orders are the classic failure.

4. 04

   Customer sync

   Match rules, deduplication and how wholesale accounts differ from DTC shoppers.

5. 05

   Fulfillment sync

   Partial shipments, multiple tracking numbers and the notification the customer actually receives.

6. 06

   Refunds and returns

   Full, partial, restock, exchange and store credit — the flow most often deferred, and most often the source of finance disputes.

Designing the sync

• Choose timing per flow. Inventory may want near real-time. Item data rarely does. Orders should be event-driven with a retry queue.
• Make everything idempotent. Every message needs a stable key so a replay can't create a second sales order.
• Queue, don't fire-and-forget. If NetSuite is unavailable, orders must wait and replay — not vanish into a log.
• Alert on business conditions. "Order failed to sync for 30 minutes" is useful; a stack trace in a mailbox nobody reads is not.
• Reconcile daily. A scheduled count of orders, refunds and inventory variance catches drift before finance does.

Edge cases that break integrations

• Pre-orders and backorders that shouldn't decrement available inventory.
• Bundles and kits that exist in one system and not the other.
• Gift cards, store credit and partial payments.
• Multi-currency, multi-entity and cross-border tax.
• Subscription orders created outside the normal checkout path.
• Exchanges, which are a return and an order pretending to be one transaction.
• Peak-period volume, when a queue that was fine at 200 orders a day meets 4,000.

How we deliver this work

1. 01

   Map before building

   Every object, every direction, every owner, written down and agreed with finance and operations — not just IT.

2. 02

   Prototype the hardest flow first

   Usually orders with discounts and taxes, or returns. Never the easy one.

3. 03

   Test with real data

   Historic orders, awkward SKUs, partial refunds. Clean test data hides the problems you're paying to find.

4. 04

   Run in parallel before cutting over

   Compare both systems for a full cycle, including a month-end close.

5. 05

   Hand over with runbooks

   What alerts mean, how to replay a failed message, who to call. Integrations fail from neglect more often than from design.