Shopify inventory and multi-location: setting stock up so it stays right

Shopify's inventory model is simple: each variant has a quantity at each location, and locations are ranked so the platform knows where an order should be fulfilled from. That simplicity works well until you have more than one place stock lives, at which point most of the problems a growing store has with inventory become visible at once.

Turn tracking on properly

Inventory tracking is per-variant, and a catalogue imported in a hurry frequently has it off for a subset of products. Those products then sell indefinitely regardless of stock, which is discovered by a customer rather than by you.

Audit it: filter the products list by tracking status before launch, and again after any bulk import. It's a five-minute check that prevents the most annoying category of oversell.

Decide separately what happens when stock reaches zero. Continue selling when out of stock is right for made-to-order and pre-orders, and a liability everywhere else.

Locations

Locations also feed shipping rates and fulfilment, so set them up before you configure either.

A location is anywhere stock sits: a warehouse, a shop, a third-party fulfilment centre. Set them up before you import stock, because moving quantities between locations afterwards is manual.

Two settings do most of the work:

• Fulfilment priority. The order Shopify tries locations in. Set it to match reality — usually the warehouse that ships most orders, not the one that was created first.
• Which locations are available for online orders. A shop with display stock you can't ship should not be feeding the online availability number.

Where inventory actually drifts

Stock is accurate on day one and wrong by month three, always for the same handful of reasons:

• Manual adjustments nobody records. Somebody takes a unit for a photoshoot. It never comes back in the numbers.
• Two systems both writing. Shopify and a warehouse system each think they own the quantity, and they diverge. There must be exactly one source of truth per field — the single most important principle in any integration.
• Returns not restocked. A refund without a restock leaves the unit invisible.
• Bundles and kits. Selling a bundle should decrement its components. Native Shopify doesn't model this; if you sell kits, you need an app or custom logic, and stores that skip it oversell constantly.
• Imports that overwrite. A CSV import with a stock column applied to the wrong location.

Preventing oversell

Beyond correct tracking, three practical controls:

1. A buffer on fast-moving lines. Hold back a unit or two on products that sell in bursts, so a simultaneous checkout race doesn't oversell.
2. Sync frequency matched to velocity. If stock lives in another system, syncing hourly on a product that sells six an hour is a guaranteed oversell. Fast movers need near-real-time updates; the long tail is fine on a slower schedule. Matching method to data type is what keeps an integration affordable.
3. An exception report. A daily list of products where Shopify and the source system disagree, sent to someone who will act on it. This catches drift in days rather than quarters.

If the shop itself is a location with a till, Shopify POS shares this same inventory pool. If your own warehouse software owns the numbers, see WMS integration.

When stock should not live in Shopify

If you have a warehouse management system or an ERP, that system owns stock and Shopify reflects it. Trying to run both as sources of truth produces a permanent reconciliation problem. The integration then pushes quantities one way and pulls order and fulfilment data back — with retries and error handling, because a silently failed stock update is an oversell nobody sees until the customer emails.

Reporting worth watching

Two numbers tell you whether inventory is healthy: the oversell rate — orders you couldn't fulfil as placed — and the disagreement count between Shopify and your source system. Both should trend toward zero. If either is stable and non-zero, something structural is wrong, and it will not fix itself.

Every inventory problem is the same problem wearing a different hat: two systems, both convinced they own the number.