Shopify inventory accuracy before you automate transfers

Every transfer recommendation is arithmetic on three inputs: how many units a location has, how fast it sells them, and how many are already on the way. The last two get all the attention — velocity windows, safety floors, approval caps. The first one is assumed. Then a Monday review proposes 36 units of a hero SKU to a retail store because the store shows −4 available, and the reason is not demand. Someone sold from that location with “continue selling when out of stock” on, a transfer was received on the shelf but never in the admin, and nobody has counted that shelf since spring.

This post owns one job: making each location’s Shopify count trustworthy enough to act on — which of Shopify’s five inventory quantities a transfer should read, where phantom deficits and phantom surpluses come from, and a location-by-location count plan to run before peak. It is not about how to score cover (inventory health score), which window to trust (velocity windows), or how big a move may be (thresholds and caps). Those all assume the count is right. This is the post for when it isn’t.

Five numbers, one identity

Shopify tracks inventory per variant per location in five quantities, and they are not interchangeable:

• On hand — physical units the system believes are at that location. On hand = available + committed + unavailable.
• Available — what can be sold right now. This is the storefront number, and the only one that goes negative.
• Committed — units on orders that are placed but not yet fulfilled from that location.
• Unavailable — units held back on purpose, in Shopify’s buckets: damaged, quality control, safety stock, other.
• Incoming — units on a transfer or purchase order headed to that location and not yet received.

Which one a transfer should read depends on which side of the move you are on:

• Source capacity: available − source floor. Not on hand. Committed units are promised to customers and unavailable units are damaged or reserved; neither can ship to another store.
• Destination need: (target days × velocity) − available − incoming. Forgetting incoming is how the same gap gets filled twice.
• Days of cover: available ÷ velocity. Cover computed on on hand flatters a location with 40 units on the shelf and 35 of them promised to unfulfilled orders.

Negative available is a data bug, not demand

Available drops below zero when a variant has “continue selling when out of stock” enabled and orders keep arriving, or when a POS sale rings at a location the admin thinks is empty. A naive recommender treats −4 as an urgent deficit — need = target − (−4) — and proposes four more units than the store can actually absorb, pulled from a location that was fine until the transfer left.

The rule that saves you: for cover math, clamp available at zero, and treat the negative itself as a ticket. Three usual causes, in order of how often we see them:

1. Stock received on the shelf, not in the admin. A transfer or PO physically arrived, staff started selling, nobody hit Receive. Fix: receive the transfer. The negative disappears without touching a count.
2. Sales from a location that was never stocked in the system. A new door opened, product was hand-carried over, and the first sale drove it negative. Fix: count and set on hand with a count reason — then find the origin location that is now too high.
3. Genuine oversell on a preorder or backordered SKU. The only case where the negative is real demand. Fix: leave the count alone and feed the recommender the incoming PO date instead of a transfer.

Stale committed inventory hides stock you could move

Committed lowers available without touching on hand, so a source location can look empty while the shelf is full. The usual culprits are orders that will never ship from there: payment pending past your cancellation window, orders on hold for fraud review, local-pickup orders the customer forgot about, and multi-location orders whose fulfillment was assigned to the wrong location and never re-routed.

Decision rule: before any count, and before any week in which automation is live, pull unfulfilled orders older than your normal fulfillment SLA, grouped by assigned location. Fulfil them, cancel them, or move fulfillment to the location that will actually ship — then read available. A 3PL holding 60 committed units against 12 real open orders is not a source you should skip; it is a source you cannot see.

Unavailable buckets are not the same as a safety floor rule

Shopify’s unavailable states exist so you do not hide stock in a fake “Quarantine” location or a spreadsheet tab. Use them deliberately:

• Quality control — returns awaiting inspection. Paired with the restock rule in bundle returns and partial refunds, it stops a returned unit from being proposed for transfer, or re-opening a pack, before anyone looked at it.
• Damaged — write-off pending. Never a transfer source.
• Safety stock — the contracted buffer a 3PL must hold, or the display unit a store must keep.
• Other — audit it monthly. If nobody can say why units are in it, they are lost stock wearing a label.

One trap: if your transfer rules already subtract a per-location safety floor (safety floors and daily caps) and you also park the same units in the safety-stock bucket, you have reserved them twice, and the source will look drier than it is. Pick one mechanism per location and write down which.

Incoming: count each unit at exactly one end

A transfer in flight is the easiest way to count the same units twice — on hand at the origin and incoming at the destination — or zero times, if the boxes left physically but nobody updated the transfer. Shopify moves units between those states as the transfer changes status; check in your own admin at which step origin on hand drops, because that is the moment the source’s real capacity changes, and your review should use the same moment.

• Update the transfer the day the boxes leave, not when the receiving team gets around to it.
• Receive partials as partials. Receiving 48 of 60 and closing the transfer as complete manufactures 12 phantom units at the destination.
• Any transfer open longer than transit time + 3 days is a count problem, not a logistics one. Resolve it before the weekly review runs.
• Destination need must subtract incoming, or the same gap gets both a transfer and a PO (PO vs transfer timing).

A pre-peak count plan, by location

Most teams run counts from an inventory CSV export and adjust in the admin, or use Stocky’s stocktakes if they are on POS Pro. Either works if you count the right things first. A wall-to-wall count before peak is worth it for small catalogs; for everyone else, count in this order at every location that will be a source or a destination:

1. Transfer candidates — every variant a recommendation (or your spreadsheet) wants to move this week, at both ends. Wrong counts here move real boxes.
2. Negative or zero available with sales in the last 30 days — the phantom-deficit list.
3. A-SKUs by velocity — the top 20% of units sold at that location. Weekly until peak, then monthly.
4. Everything in the “other” unavailable bucket.
5. B and C SKUs on a rolling monthly and quarterly schedule.

When you adjust, pick a count reason instead of the default correction. Inventory history then tells you which changes were audits and which were fixes, and you can compute one number per location: count accuracy, the share of counted variant-locations where the system matched the shelf.

Rules that let a count veto a move

• Negative available on a variant at the destination → no automated transfer of that variant into it; open a count task instead.
• Last count of the variant at the source older than 30 days and the proposed quantity above 50% of available → recommend, do not auto-approve.
• Committed above 40% of on hand at the source → clear stale orders before treating it as a source at all.
• An open transfer of the same variant to the destination older than transit + 3 days → hold new transfers until it is received.
• Variance above 5% on the variant’s last count → recount before shipping, whatever the cover math says.

Kits and packs inherit the count error

Pack availability is derived from component stock at the locations the pack counts (kit inventory sync). A phantom +12 on one component re-opens a kit you cannot ship complete; a phantom −4 hides a kit you could sell. If you run packs with Better Bundles, the same counts that feed transfers feed pack availability, and a component count fix recalculates the pack automatically (inventory sync docs) — one more reason to keep components on the A-list even when their solo velocity is low.

Run the count before you turn anything on

Automation does not fix counts; it acts on them faster. Before peak, run the count order above at every source and destination, clear stale committed orders, empty the “other” bucket, and close every transfer that has physically arrived. Only then let a recommender — spreadsheet or software — propose moves you will approve without recounting first.