---
title: "Why Is Our Inventory Sync Failing? The Eight Ways Shopify and Your ERP Drift Apart"
url: https://www.uncap.com/post/shopify-erp-inventory-sync-failing
author: "Denis Dyli"
published: 2026-09-10
updated: 2026-09-10
---

# Why Is Our Inventory Sync Failing? The Eight Ways Shopify and Your ERP Drift Apart

> Eight reasons Shopify and ERP inventory drift apart: sync lag math, two writers, ATP semantics, unit-of-measure errors, dropped events, and the missing audit.

The symptom is always the same sentence: the website says twelve, the ERP says four, and somebody just sold eight units that do not exist. In a consumer store that is an apology email. In B2B it is a contractor's crew standing idle, a fleet's truck stuck on a lift, or a supply house calling to ask why the order it promised its own customer just got shorted, and the account remembers.

Inventory sync failure is the most common symptom B2B operators describe, and the frustrating part is that the sync is usually "working" in the narrow sense, running on schedule, throwing no errors, while the numbers drift apart anyway. That is because sync failures are rarely bugs. They are architecture, and they come in eight recognizable shapes.

**Quick answer:** Inventory sync fails for eight reasons, and they diagnose in order. The first four are cadence mismatch, where a batch sync's interval leaves an oversell window equal to sync lag times sales velocity; two writers, where both systems edit inventory and each overwrites the other's truth; location mismapping, where ERP warehouses and Shopify locations disagree about which stock is where; and semantics confusion, where on-hand, committed, and available-to-promise get treated as the same number. The second four are unit-of-measure drift, where a case of twelve syncs as one and every count is wrong by a multiple; silently dropped events, where a failed webhook or API call loses an update and nothing notices; unwired return paths, where cancellations and returns restock one system only; and missing reconciliation, the absence of a scheduled compare that would have caught all of the above. The fix is one writer, event-driven updates where velocity demands them, deliberate ATP mapping, and a reconciliation sweep that audits the sync instead of trusting it.

## First, the math that explains the mystery overselling

A sync can be healthy and still oversell, because a batch interval is an exposure window. If inventory pushes every thirty minutes and a SKU sells four units an hour across channels, every push leaves up to two units of phantom availability on the storefront at any moment, and a spike, a promotion, a fleet stocking order, multiplies it. That is the formula worth writing down: oversell exposure is sync lag times sales velocity, per SKU. Slow-moving items tolerate a nightly batch forever, which is why the problem hides for months and then erupts on the fastest sellers during the busiest week, exactly when the middleware queue is also running hours behind its schedule.

The design consequence is not "sync everything instantly," which is expensive and unnecessary. It is matching cadence to velocity: event-driven updates for the SKUs and moments where the exposure math bites, scheduled batches where it does not, which is an architecture decision covered across [the three Shopify B2B ERP integration methods](https://www.uncap.com/post/shopify-b2b-erp-integrations) this diagnosis assumes.

## The two-writer problem: drift by good intentions

Ask who is allowed to edit inventory, and if the answer includes both systems, the drift is explained. A warehouse count adjusts the ERP; someone fixes an oversell by editing Shopify directly; a returns clerk restocks in one place; an app adjusts availability for a promotion. Each edit is locally sensible, and together they guarantee the two systems describe different worlds, because sync is built to propagate changes, not to arbitrate custody battles.

The rule that ends it is one writer: the ERP owns inventory truth, Shopify displays it, and every adjustment, counts, corrections, restocks, happens in the owner and flows down. Storefront-side edits become read-only territory, and the one legitimate exception, an emergency zero-out during an incident, gets reconciled back the same day. This is less a technical control than a discipline, which is why it is the failure mode that returns after every new hire.

## Mapping and meaning: where the numbers stop meaning the same thing

**Location mismapping** is the quiet classic: three ERP warehouses, two Shopify locations, and a default rule quietly summing or dropping one of them. Stock allocated to a branch appears available to the wrong region, or a warehouse's inventory vanishes from the storefront entirely. Multi-location operations should treat the warehouse-to-location map as configuration under change control, and the deeper design questions, which locations promise to which buyers, how routing commits stock, belong to [the multi-warehouse visibility and order routing architecture](https://www.uncap.com/post/multi-warehouse-inventory-visibility-order-routing) rather than to the sync alone.

**Semantics confusion** is subtler and more expensive. An ERP holds several numbers per item: on-hand, allocated or committed, and available-to-promise, the on-hand minus what is already spoken for. Sync the wrong one and the storefront confidently sells stock that a fleet order committed yesterday, or hides stock that is merely reserved on a stale order nobody closed. The decision of which number Shopify displays is not a mapping detail; it is the promise the storefront makes to buyers, and in B2B, where a single account's order can commit half a warehouse, ATP is almost always the right answer and on-hand almost never is.

**Unit-of-measure drift** is the B2B special. The ERP stocks cases; the storefront sells eaches, or the reverse, and somewhere a conversion factor is missing or applied twice. A case of twelve synced as one unit understates availability twelvefold; the opposite error oversells by the same multiple, and the wrong-by-a-factor signature, counts off by exactly 6x, 12x, 24x on specific SKUs, is the tell. Every SKU with a pack hierarchy needs its conversion stated once, in one system, and tested with a known quantity.

## The silent failures: dropped events and missing reconciliation

Event-driven syncs fail differently: a webhook times out, an API call hits a rate limit, a retry lands out of order, and one update simply never happens. Nothing errors visibly, because the failure is an absence. The affected SKU is now permanently wrong until something corrects it, and nothing will, because most integrations are built to propagate changes and never to check totals.

That is why the reconciliation sweep is the difference between a sync and a sync you can trust: a scheduled job, nightly is usually enough, that compares full counts between systems, flags mismatches beyond tolerance, and either corrects toward the owner or opens a ticket. Returns, exchanges, and cancellations belong in the same audit, because the restock path is wired in one direction far more often than anyone admits, and a busy returns week without it becomes a week of inventory leaking out of one system's view. Operations that add the sweep usually discover their drift was chronic, not occasional; the mystery was never why it broke this week, but why nobody had been measuring.

## The buffer confession

Most operations that have lived with sync drift run safety buffers, showing two fewer than the count, or capping availability, and the honest thing to say is that a buffer is a painkiller, not a cure. It trades overselling risk for guaranteed under-selling: inventory you own, paid for, and decline to sell, every day, on every buffered SKU. Sized briefly during a diagnosed incident, buffers are sensible. Left permanent, they are a tax paid to avoid fixing the architecture, and their size is a measurement of exactly how much the sync is not trusted.

## What the fixed version looks like

One writer, with the ERP as owner. Event-driven updates on velocity where the exposure math demands it, scheduled elsewhere. ATP mapped deliberately, per the promise the storefront should make.

UoM conversions stated once and tested. A reconciliation sweep auditing totals nightly, with returns in scope. And buffers shrinking toward zero as trust returns, which is the visible sign the fix took.

That architecture is precisely what [Uncap Connect](https://www.uncap.com/products/connect) is built to run: a Shopify-embedded sync between the storefront and the ERP, both directions in real time, with the ERP kept as the system of record, as part of [the ERP integration practice](https://www.uncap.com/integrations) behind more than 380 B2B commerce projects Uncap has delivered as a Shopify Platinum Partner since 2013. Book a Demo if your website and your warehouse are currently telling different stories, the eight-mode diagnosis above is the first working session, and most operations find their drift in the first three.

## Frequently asked questions

### Why is my Shopify inventory not matching my ERP?

One of eight causes, in likely order: batch sync lag on fast-moving SKUs, both systems editing inventory, warehouse-to-location mismapping, syncing on-hand instead of available-to-promise, a missing or doubled unit-of-measure conversion, silently dropped webhook or API events, returns restocking only one system, or the absence of a reconciliation job that would have caught any of these. Check the timestamp lag and the mapping first; they explain most cases.

### How do I stop overselling on Shopify with an ERP?

Match sync cadence to sales velocity, since oversell exposure equals sync lag times sales rate per SKU: event-driven updates for fast movers, batches for the rest. Then sync available-to-promise rather than on-hand, so stock committed to existing orders is never resold, and add a reconciliation sweep so dropped events cannot leave phantom availability standing.

### What is available-to-promise and why does it matter for sync?

Available-to-promise is on-hand inventory minus what is already allocated to orders, the number that represents what can actually still be sold. Syncing raw on-hand to the storefront resells stock that existing orders have committed, which in B2B, where one account's order can claim a large share of a warehouse, is the single most expensive semantics mistake in the integration.

### Are inventory buffers a good way to prevent overselling?

As a temporary measure during a diagnosed incident, yes. As a permanent setting, a buffer is unsold inventory you pay to hold: it trades oversell risk for guaranteed under-selling and hides the architectural fault that made it feel necessary. The buffer's size is a running measurement of how little the sync is trusted, and it should shrink as the real causes are fixed.