---
title: "The Shopify ERP Sync Design Spec: Seven Decisions to Make Before Anyone Writes Code"
url: https://www.uncap.com/post/shopify-erp-inventory-sync-design
author: "Denis Dyli"
published: 2026-09-10
updated: 2026-09-10
---

# The Shopify ERP Sync Design Spec: Seven Decisions to Make Before Anyone Writes Code

> The inventory sync spec to write before code: field ownership, the number you promise, cadence by class, failure behavior, reconciliation, and cutover.

Most inventory syncs are never designed. They are configured: a connector installed, default mappings accepted, the demo data flows, and everyone moves on until the drift starts. The diagnosis of what happens next is written up in [the eight ways Shopify and your ERP drift apart](https://www.uncap.com/post/shopify-erp-inventory-sync-failing); this is the companion the fix deserves, the design spec, the seven decisions that, made deliberately before anyone writes code or installs anything, produce a sync that stays trusted instead of one that quietly becomes the reason for the safety buffers. Hand this to whoever is building or buying your integration and make them answer in writing.

**Quick answer:** A sync that stays honest is specified across seven decisions. The first four: an ownership map with one writer per field, written down; the number you sync, meaning which inventory figure the storefront promises and what happens at zero; cadence per data class, event-driven where velocity demands and batch where it does not; and identity plus units, the SKU join key and unit-of-measure conversions stated once. The last three: failure behavior, what the storefront does when the sync is down, decided by risk rather than accident; reconciliation and observability, the nightly audit and the two dashboard numbers; and cutover, how the first load is seeded, counted, and verified before go-live. None of these are technical exotica; all of them default to the wrong answer when nobody decides.

## Decision 1: The ownership map

For every field that crosses the boundary, name the single system allowed to write it. Inventory quantities: the ERP writes, Shopify displays. Orders: Shopify writes, the ERP consumes. Fulfillment and tracking: the ERP or WMS writes back, and account pricing the ERP writes. Product content: decide, because this is the one that splits teams, and an unowned field is a future discrepancy with a meeting attached.

The map should be a page, not a paragraph, and it extends beyond inventory: the stack-wide version of this exercise, deciding field by field which system holds the pen across ERP, PIM, and storefront, is laid out in [the distributor software stack guide](https://www.uncap.com/post/wholesale-distributor-software-erp-pim-ecommerce). The inventory rows are simply its most dangerous section, because they are the ones that oversell when two systems both believe they own them.

## Decision 2: The number you sync

An ERP holds several quantities per item; the storefront can display one. Decide which: available-to-promise, on-hand minus what existing orders have committed, is almost always the right promise in B2B, where a single account's order can claim half a warehouse. Then decide the zero policy per SKU class: hard stop at zero, sell into backorder with an honest date, or presell against inbound purchase orders. Each is legitimate; the failure is not choosing, because the default, raw on-hand with silent oversell, is the worst of the three.

## Decision 3: Cadence per data class

Not everything needs to be instant, and everything instant is expensive. Stock deltas on fast-moving SKUs earn event-driven updates, because oversell exposure equals sync lag times sales velocity. Slow movers tolerate scheduled batches indefinitely. Price changes sync on the event that changes them, since a stale price is a margin decision made by a clock, while product content can amble along on a slow batch, because nobody oversells a description. Writing the cadence down per class, instead of setting one interval for the whole integration, is the single cheapest performance decision in the spec.

## Decision 4: Identity and units

The SKU is the join key between systems, so treat it like one: renames and supersessions go through a process, not a spreadsheet edit, because a renamed SKU is an orphaned record in whichever system missed the memo. Beside identity sits arithmetic: every item with a pack hierarchy, each, inner, case, needs its unit-of-measure conversion stated once, owned by one system, and tested with a known quantity, because a missing or doubled conversion is how counts go wrong by exactly twelvefold and nobody spots it until the claim.

## Decision 5: Failure behavior

Syncs go down; the spec decides what the storefront does while they are. Fail-open, keep selling on the last known counts, suits deep-stocked items where a stale number is low-risk. Fail-closed, stop promising what cannot be verified, suits the last-units and allocation cases where an oversell is a fleet's truck on a lift. Deciding per class beats deciding once, and both beat the default, which is whatever the connector happens to do.

Two engineering words belong in the spec in plain language. Retries must be idempotent, meaning an update applied twice must land the system in the same state as applied once, or every retry after a timeout is a fresh way to corrupt a count. And queues need backpressure visibility, because a sync that is "working" four hours behind on the year's busiest day is the failure mode that costs the most and alarms the least.

## Decision 6: Reconciliation and observability

Propagation is not verification. The spec includes a scheduled reconciliation sweep, nightly is usually enough, comparing full counts between systems, flagging drift beyond tolerance, and correcting toward the owner or opening a ticket. Returns, exchanges, and cancellations are explicitly in scope, because restock paths wire themselves in one direction with remarkable consistency.

Observability is two numbers on a dashboard: sync lag in minutes, and SKUs out of tolerance. Alert on absence, not just on errors, since the deadliest failure is the webhook that silently never arrived. An integration with those two numbers visible gets fixed on Tuesday; one without them gets discovered during the busiest week of the year, by a customer.

## Decision 7: Cutover and seeding

The first load deserves its own plan: a counted starting position, a freeze window while it seeds, and a verification pass before go-live, because a sync born from an uncounted baseline spends its whole life propagating an original sin. Keep a golden set of test SKUs, one per awkward case: a fast mover, a pack-hierarchy item, a multi-location item, a supersession, and walk each through a sale, a return, and a count adjustment before the store opens. An afternoon of golden-SKU testing is the cheapest insurance in the project.

## Then run it like a practice, not a project

The spec's last section is operational: the drift dashboard reviewed weekly, mapping changes under change control, and the buffer sizes trending down as trust accrues, which is the visible KPI of the whole effort. Method choice sits underneath all seven decisions, native connector, integration platform, or custom build, and [the three Shopify B2B ERP integration methods](https://www.uncap.com/post/shopify-b2b-erp-integrations) covers that selection; the point of the spec is that every method still needs these answers, and the vendor who cannot answer them is telling you who will be writing the spec after go-live, in production, one incident at a time.

This spec is also, not coincidentally, a description of how [Uncap Connect](https://www.uncap.com/products/connect) is built: Shopify-embedded, two-way and real-time where velocity demands it, the ERP kept as the one writer, with reconciliation as a feature rather than an aspiration. Uncap has been a Shopify Platinum Partner since 2013, with more than 380 B2B commerce projects delivered for manufacturers, distributors, and wholesalers. Book a Demo and bring this spec, walking Connect through the seven decisions against your ERP is a better evaluation than any feature list.

## Frequently asked questions

### What should a Shopify ERP integration spec include?

Seven decisions: a field-by-field ownership map with one writer per field, the inventory number the storefront promises and its zero policy, sync cadence per data class, SKU identity and unit-of-measure rules, failure behavior when the sync is down, a reconciliation sweep with lag and drift on a dashboard, and a seeded, counted, verified cutover. Any integration method still needs all seven answered.

### What does idempotent mean in an inventory sync?

That an update applied twice leaves the system in the same state as applied once. It matters because syncs retry after timeouts, and without idempotency every retry is a chance to double-apply a stock movement and corrupt the count, which is how integrations that "recovered" from an outage end up wrong afterward.

### Should a sync fail open or fail closed when it goes down?

By risk class, not by default: fail-open (keep selling on last known counts) for deep-stocked items where staleness is cheap, fail-closed (stop promising) for last-units and allocated stock where an oversell costs an account's trust. The wrong answer is the one nobody chose, which is whatever the connector happens to do.

### How do you test an ERP sync before go-live?

With a golden set of SKUs covering the awkward cases, a fast mover, a pack-hierarchy item, a multi-location item, a supersession, each walked through a sale, a return, and a count adjustment, on top of a counted initial load seeded during a freeze window and verified before the store opens. Syncs born from uncounted baselines propagate the error forever.