Your admin says 14 in stock. The shelf has three. A customer just bought unit number five and you are drafting an apology email. When Shopify inventory is not syncing, the instinct is to blame the integration — but usually the integration is doing exactly what it was told. The wrong quantity comes from upstream: a location nobody stocks, an app pushing absolute counts on a timer, a bundle decrementing the wrong component, or a shelf nobody has counted since March. Here are the seven causes behind almost every case, how to confirm each, and the fix. Three of the seven are process, not software.
Key takeaways
- Shopify holds several numbers per SKU per location — available, committed, on hand, incoming. Many "wrong quantity" reports are the wrong one being read.
- Start at the variant's adjustment history. It names the app, person or import behind every change, with a timestamp.
- Exactly one system should own the stock number for a location. Two apps with write access will overwrite each other forever.
- Inventory CSVs set absolute quantities. An import built from yesterday's export silently rolls back everything you sold today.
- If the audit trail is clean and the count is still wrong, the problem is physical. No integration fixes an uncounted shelf.
Shopify inventory not syncing? Read the audit trail first
Skip the support tickets for ten minutes. Open the product, click the variant, and read its inventory history — Shopify logs every adjustment with a timestamp, the resulting quantity, and who or what made it: a staff name, an app, an order, or an import. Two questions end most investigations. Did the last change come from a human, an order, or an app? And is there a change nobody can explain — a jump back to a round number, or a correction posted at 2 a.m.? Then open Settings → Apps and sales channels and list every app that can write inventory. Most stores are surprised by how long that list is.
Wrong quantity? Symptom, cause, and where to look
| Symptom | Most likely cause | Where to check in Shopify admin |
|---|---|---|
| Storefront says sold out, but you have units on the shelf | Stock sits at a location the sales channel doesn't sell from | Settings → Locations, then the variant's per-location quantities |
| Available looks too low during a busy week | Unfulfilled orders holding units in committed | Variant inventory card: available vs committed vs on hand |
| Quantity resets overnight to an older number | Scheduled app push or CSV import writing absolute values | Inventory adjustment history — app name and timestamp |
| Two systems disagree and the winner keeps changing | Two apps with inventory write access on one location | Settings → Apps and sales channels; adjustment history |
| Component stock never moves when kits sell | Bundle app not decrementing components | Bundle app's component mapping; component variant history |
| Returned goods never reappear as sellable | Refund processed without a restock | Order timeline — look for the restock line |
| Audit trail is clean, count is still wrong | Physical drift — nobody counted the shelf | Nowhere in admin. Go count it. |
Cause 1: Several channels and locations writing to the same SKU
Shopify tracks inventory per location, and each sales channel sells only from the locations you allow. Add a 3PL warehouse, a pop-up, a POS drawer or a second studio and one SKU carries several independent counts. Oversells appear when two channels draw on the same physical pile through different location records; phantom stockouts appear when the stock is real but sitting where that channel cannot sell it.
How to confirm: read the variant's per-location breakdown, not the roll-up total. If the total looks right but one location shows zero and another everything, you have a routing problem, not a sync problem. Check location priority in Settings → Locations, and whether the product is published to the misbehaving channel.
The fix: keep stocked locations as few as your operation allows — each is another count to keep honest. Deactivate locations you no longer ship from rather than leaving them at zero, and decide explicitly which location each channel sells from.
Cause 2: You are reading available and thinking on hand
The cheapest fix here, because nothing is broken. Shopify splits inventory into states, and the storefront sells against available — not against what sits on the shelf.
| State | What it means | Can you sell it? |
|---|---|---|
| On hand | Every unit physically at that location | Not directly — it is the sum of the states below |
| Committed | Sold on orders not yet fulfilled | No, it belongs to a customer already |
| Unavailable | Set aside as damaged, quality control or reserve | No, until you move it back |
| Available | On hand minus committed minus unavailable | Yes — this is what the storefront uses |
| Incoming | On a purchase order or transfer, not yet received | No, and it is not on your shelf either |
Worked example — a jewellery brand's hoop earring at the studio location, the Monday after a campaign weekend:
The founder sees 108, counts 140 on the shelf, files a ticket saying Shopify inventory levels are incorrect. Nothing is wrong. Before debugging an integration, confirm which of these five numbers each side of your stack is comparing — a 3PL reporting on hand against a screen showing available will disagree every day, correctly.
Cause 3: Two apps with write access fighting over the same number
The most common genuine sync failure. A 3PL app pushes warehouse counts hourly, a POS syncs in real time, a subscription app decrements on renewal, a bundle app writes component counts. Each believes it holds the truth, and most write absolute quantities rather than deltas. When two writers overlap, the count you see is whichever ran last — which is why the number looks right in the morning and wrong by lunch.
How to confirm: look for alternating entries from two app names in the adjustment history within a short window, often oscillating between the same two values. That oscillation is the signature.
The fix: pick one owner per location; everything else reads. Write it down — "the 3PL owns Warehouse quantities; nothing else writes there" — because in six months someone will install another app and the question returns. A system that holds one authoritative stock count per variant and location makes that rule enforceable; four apps each nominating themselves makes it impossible.
Cause 4: Bundles and kits decrementing the wrong thing
Bundles break inventory in two directions. If the bundle is its own tracked SKU, selling it decrements the bundle and leaves components untouched — component stock stays optimistic until you run out mid-pack. If it does decrement components but the mapping is wrong, or one component sits in three bundles at different quantities, you get silent double-counting.
How to confirm: sell one bundle, then open each component's history. Each should show an adjustment for exactly the quantity in the kit. If nothing moved, or the number is off, you have found it.
The fix: track components, not kits, wherever a component is also sold alone. The bundle should hold no stock of its own — it is a recipe that draws down real inventory. That recipe is a bill of materials in all but name, and the same logic governs goods you manufacture.
Cause 5: A CSV import quietly overwrote live counts
Someone exports inventory on Tuesday morning, edits 40 rows, imports the file Wednesday afternoon. The import sets absolute quantities, so everything sold in between is erased — the file carries Tuesday's numbers and Shopify obediently applies them.
How to confirm: the history shows a batch of changes sharing one timestamp across many variants. That is a bulk write; no order caused it.
The fix: re-export immediately before you edit, edit fast, import while nothing is selling — or leave the quantity column out entirely when you are only changing titles, prices or tags. Better: stop routing stock changes through spreadsheets. Every export-edit-import cycle is a window where two versions of the truth exist at once, one of the clearest signals in the spreadsheets versus inventory software decision.
Cause 6: Returns and restocks that never post back
A customer returns two units. Support refunds the order to close the ticket, the parcel arrives, someone puts the items back on the shelf, and nobody ticks the restock box. Shopify's count stays two low, permanently — repeat across a season and you are reordering against a number that has understated your stock for months. The opposite error is just as common: restocking a return that arrived damaged and will never sell.
How to confirm: open a handful of recent refunded orders and read the timeline — a restock is logged there. Frequent refunds and rare restock lines is your answer.
The fix: process, not software. Refund when the goods are inspected, not when the email arrives. One person decides sellable or write-off and records it then — restock to the sellable location, or mark it damaged so it leaves available stock honestly. A return sitting undecided in a bin for three weeks is worse than either outcome, because your data says one thing and your shelf another.
Cause 7: The count is right in Shopify and wrong in reality
Nobody wants this one to be true, and in brands that manufacture it is the most common of all. Every system agrees, the integration is clean, and the shelf still has three when the software says fourteen. Units get miscounted at receiving, broken in the stockroom, given away as samples, or picked against the wrong barcode. None of that generates a webhook.
The only fix is counting, and the practical version is cycle counting: count a slice of the catalogue continuously instead of shutting down twice a year. Rank SKUs by revenue, then count A items monthly, B quarterly, C twice a year — ten minutes a day covers a small catalogue. Score it, or it will not stick:
The net gap is only 44 units but the absolute variance is 96 — errors in both directions cancel out, which is why a net figure flatters you. Target 98% or better on A items. Below that, your demand forecast and reorder points inherit the error. Log a reason code for every correction — damage, miscount, sample, receiving error — because after two months the reasons tell you which part of the process to fix.
Why one-way sync tools cause drift
Most cheap connectors are one-way: System A pushes quantities to Shopify on a schedule, nothing flows back. Three failure modes follow, and all three look like an integration bug from outside.
- Stale windows. Between pushes, Shopify sells units System A does not know about. The next push overwrites Shopify's correct, order-adjusted number with an older one.
- Silent failures. A push dies on a rate limit or timeout and nobody watches the log. Yesterday's numbers stay live for days.
- No feedback. Corrections, restocks and POS sales made in Shopify never travel upstream, so the systems diverge a little more each day until someone reconciles by hand.
Two-way sync means each side owns something specific and both stay current. Orders and sales history flow from Shopify into the inventory system; authoritative stock counts flow back out. Because the directions carry different data, updates never collide — the store owns what sold, the inventory system owns what exists. That is how Honey Shelf's two-way Shopify sync works: sales in, finished goods out, per variant, with a sync log you can read when a number looks odd.
Be clear-eyed about what that buys you. Two-way sync eliminates causes 1, 3 and 5 almost entirely and makes 4 and 6 visible fast. It does nothing for cause 7 — no connector knows six units were dropped in the stockroom.
A 30-minute reconciliation you can run this week
Take your ten highest-revenue SKUs. For each: count the physical units, record Shopify's on-hand number for that location, read 30 days of adjustment history. Classify every gap — order-related, app-related, import-related, return-related, or unexplained. The distribution tells you where to spend effort: mostly app-related means fix ownership today; mostly unexplained means the integration was never your problem and counting is the whole answer. If you manufacture, run the same check on materials and part-finished goods — finished-goods accuracy sitting on top of untracked work in progress only looks solid.
Then write the rules down. Which system owns each location's count. Who may import a CSV. When refunds get restocked, and by whom. How often each ABC class gets counted. Integrations break loudly and get fixed in an afternoon; undocumented conventions break silently and cost you a season.