Inventory synchronization failures are rarely solved by pressing “sync again.” The useful question is which system owns each number, which inventory state is being compared, and what happens when an update arrives twice, late, or not at all?
For a store using Shopify alongside a fulfillment partner, warehouse management system (WMS), ERP, or automation tool, stock problems can show up as overselling, unavailable products that physically exist, orders routed to the wrong location, or inconsistent numbers in reports.
This guide is for operators and developers trying to diagnose those problems before buying yet another app.
Start with the right quantity
Shopify distinguishes inventory states at each location. On hand is the stock recorded at a location; available is sellable stock; committed is allocated to orders and cannot be sold again; unavailable covers units set aside for other reasons; and incoming represents stock not yet received.
If your warehouse sends “physical units on shelf” but an integration writes that number into Shopify’s sellable available quantity, you can introduce a mismatch even when both systems are reporting correctly.
Before touching the integration, compare the same SKU or inventory item, same location, same point in time, and same inventory state. Use Shopify’s inventory state reference to align definitions.
Six common causes of inventory drift
1. The wrong location is being updated
A merchant may have a physical warehouse, a showroom, an office, and a fulfillment partner represented as different Shopify locations. An integration can successfully update inventory at one location while the storefront sells from another.
Check: for a sample of variants, list the Shopify inventory item ID, all active location IDs, fulfillment configuration, and the warehouse’s location identifier. Verify which location is allowed to fulfill online orders. Do not assume an item’s total across locations equals the amount available for checkout.
2. SKU matching is ambiguous
SKU values are useful operational identifiers but are not guaranteed unique or populated. A variant may be missing its SKU, share one with a bundle or duplicate, or be renamed after import.
Check: define a stable mapping from each external warehouse item to the corresponding Shopify inventory item and location. Detect duplicates and unmatched products explicitly. Never “guess the closest SKU” to keep a synchronization job green.
3. An order changes the state before fulfillment
Placed orders can move units into committed, while warehouse workflows may still show them as awaiting picking. “Printed,” “in packing,” and “fulfilled” are different operational facts. A warehouse count and Shopify available count can legitimately differ during this period.
Check: examine a few real order journeys: placed → routed → picked → shipped → fulfilled. Ask which system changes stock, and at what stage. Do not treat a warehouse packing status as proof that inventory reconciliation completed.
4. Retries run the same adjustment twice
Networks fail. Webhook deliveries can be retried, and an automation may replay after a timeout. A duplicate incremental adjustment can subtract the same units twice.
Check: keep a stable event or transaction identifier, log processing outcomes, and use idempotent operations. Shopify’s GraphQL inventory mutations include idempotency requirements that depend on the API version: read the current inventory mutation reference and Shopify developer changelog before implementation. Idempotency reduces duplicate writes; it does not replace reconciliation.
5. Both systems think they are the source of truth
One flow imports warehouse quantities into Shopify; another Shopify app sends modified quantities back to the warehouse. Without ownership rules, the last write wins—possibly overwriting legitimate reservations or cycle-count adjustments.
Check: document ownership by inventory state, location, and operation. For example, physical count adjustments may originate in the WMS while sales reservations originate in Shopify. Exact ownership depends on your contracts and fulfillment setup.
6. Failures are silent, and no one reconciles them
Even a robust webhook pipeline can miss a downstream write during a provider outage or permissions change. A “successful” automation run might mean a request was accepted, not that the warehouse applied the intended operation.
Check: monitor failed messages, retry exhaustion, permission failures, and stale stock. Schedule a controlled comparison of representative inventory items. Give exceptions an owner; maintain a replay/recovery procedure instead of editing random quantities manually.
A 30-minute diagnosis worksheet
| Question | Evidence to collect | Why it matters |
|---|---|---|
| Which item? | Variant ID, inventory item ID, SKU | Avoids accidental joins |
| Which location? | Shopify location ID, warehouse location | Prevents location-level confusion |
| Which state? | Available, committed, unavailable, on hand | Prevents comparing different quantities |
| When did it diverge? | Last known matched timestamp | Narrows the change window |
| What changed? | Orders, returns, receipts, transfers, manual adjustments | Identifies legitimate stock movement |
| Did delivery complete? | Webhook ID, automation run, API response, downstream acknowledgment | Distinguishes accepted from applied |
| Can it be replayed safely? | Stable idempotency key and reconciliation record | Prevents creating another mismatch |
Start with five representative variants: one common seller, one low-stock item, one with several locations, one bundle or product with variants, and one that recently had a return or cancellation. Compare actual states at each location. Do not perform a bulk correction until the mismatch pattern is understood.
Should you use an app, Make, or custom code?
Use supported native Shopify features when they cover the operating need. Use a well-maintained integration app when the external system is supported, its data model fits, and it exposes failure status clearly. Use a tool such as Make for bounded workflows where you can tolerate and recover from delays and inspect failed operations. Consider custom integration code when reconciliation, complex mapping, order routing, or reliability requirements justify the ongoing ownership.
A small workflow is not automatically production-safe just because it is automated. Count the operational cost of monitoring, exceptions, API limits, and support—not merely the subscription price.
What a reliable solution looks like
A dependable stock integration should have identifiable inputs, a documented source of truth, exact item/location mapping, repeat-safe processing, a clear error queue, audit logs, reconciliation, and a straightforward human recovery path.
If the store already has stock discrepancies, request a focused expert store review to identify the first investigation steps. For architecture or implementation needs, see our Shopify B2B and integrations service. We begin with the existing system and its constraints, rather than assuming you need a new app or a full rebuild.
Technical references: Shopify inventory states, viewing inventory by location, and GraphQL inventory adjustments. Verify API version and permissions for your own shop before changing production stock.
