Guides

Multi-store inventory management, as a routine

Keeping inventory honest across several Shopify stores is not a tool choice, it is an operating routine: where stock gets received, how returns flow, when drift gets checked, and who is allowed to touch the number. The daily, weekly and monthly version of that routine.

Most writing about multi-store inventory is about picking a tool. Fair enough — but the tool is maybe a fifth of it. The rest is a routine: a handful of habits that decide whether the numbers your stores publish stay connected to the shelf. This is that routine, organised by how often each part runs.

It assumes the hub-and-spoke model: one main store that owns the number, connected stores that follow it. If you have not made that decision yet, make it first — no routine repairs an architecture where two stores can both be right.

Three questions sit next to each other here and get answered on three different pages, so it is worth saying which is which:

• Which architecture? — one shared inventory across stores: mesh versus hub and spoke, and the five rules that hold it together.
• Which method? — syncing inventory between two stores: CSV, a custom build, or an app, and what each costs.
• Which routine? — this page: what happens daily, weekly, monthly, and who is allowed to touch the number.

All three apply unchanged on Shopify Plus, where the second store is an expansion store — same separate inventory, same routine.

The principle everything hangs on

Run inventory as if only the main store existed. Every stock-touching process — receiving, corrections, write-offs, counts — happens there. The connected stores are projections: useful, sale-generating, and never edited by hand.

Once that is internalised, every question below answers itself. The routine is just the principle applied to each thing that happens in a week.

Daily

• Receive in the main store. Purchase orders arrive, get counted, and get entered there. The sync carries the new quantities outward within seconds; nothing needs doing in any connected store.
• Correct in the main store. Damaged unit, miscount, sample taken for a shoot — the adjustment happens where the shelf is tracked. A connected store that looks wrong gets diagnosed, not edited.
• Refunds without restock in the connected stores. The support person refunding one of their orders unticks restock. Goods that physically return get added to the main store when they arrive and pass inspection — which is usually days later, and that lag is honest: the unit was genuinely not sellable in between.
• Watch the failure alerts. A sync write can fail — a token expires, an API hiccups. The difference between a non-event and a slow leak is whether anyone is told. If your tool cannot alert on failed writes, the weekly check below is carrying the entire load.

Weekly

• Check the counts still agree. Compare every matched SKU’s quantity across all stores. Zero gaps is the expected, boring result; any gap is a story worth thirty seconds — a missed webhook, a manual edit someone snuck into a connected store, a duplicate SKU that crept into the catalogue. Daily during sales periods: drift risk scales with order volume, and the cost of an open gap scales with it too.
• Re-match the products after catalogue edits. New products, renamed variants, seasonal relists — matching quietly breaks at edit time, not at sync time. If anything changed in either catalogue this week, confirm the matched and unmatched lists still look deliberate.
• Review the unmatched list. It should read as “things this store deliberately does not carry”. The moment it contains something that should be shared, that item has been selling unsynced all week.

Monthly

• Stocktake in the main store. Cycle counts or full counts, always against it. The corrections propagate outward on their own.
• Review low-stock and reorder against the main store’s numbers. It is the only store whose quantities mean anything for purchasing. Low-stock alerts from the connected stores are noise — turn them off if the app allows it.
• Audit who can edit inventory. Staff permissions drift like everything else. Staff in the connected stores need orders, customers and fulfilment; they specifically do not need inventory edit rights, and removing the ability is kinder than policing the habit.
• Read the write log for anomalies. A month of logged writes shows patterns a day cannot: an SKU that syncs suspiciously often, a store that fails more than the others, a weekly spike that lines up with someone’s bulk-edit habit.

Quarterly, or when things change

• Repeat the full SKU audit across every store — twenty minutes per store in a spreadsheet, per the duplicate-SKU guide.
• Re-verify the disconnect story before adding or removing any store from the network. What happens to a store’s counts when it leaves the sync should be a sentence someone can say from memory, because the answer differs sharply between tools.
• Re-check the connected stores’ settings. “Continue selling when out of stock” has a way of getting re-enabled per-product during launches and never turned back off. In a store that follows, it silently disarms the whole system for that product.

The metrics that tell you it is working

Three numbers, all of which should be boring:

Where StockUnison sits

StockUnison automates the parts of this routine that should never have been manual: the sync itself is event-driven and one-way out of your main store, the difference report is the weekly check as a button (and its gaps are listed by SKU, so the thirty-second investigation starts prefilled), matching re-runs on demand after catalogue edits, and every write is logged with its result, including the refusals. Failed writes surface instead of vanishing.

It does not do purchasing, forecasting or stocktakes — that is deliberately a different tool class — and it will not stop a connected store staff member with admin rights from editing stock; it will only make the edit visible when the next change in the main store overwrites it. The free plan matches products, previews every change and runs difference checks on an unlimited catalogue, which is the whole observability half of this page without paying.