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 source store that owns the number, destinations 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.

The principle everything hangs on

Run inventory as if only the source store existed. Every stock-touching process — receiving, corrections, write-offs, counts — happens there. The destinations 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 source. Purchase orders arrive, get counted, and get entered in the source store. The sync carries the new quantities outward within seconds; nothing needs doing in any destination.
• Correct in the source. Damaged unit, miscount, sample taken for a shoot — the adjustment happens where the shelf is tracked. A destination that looks wrong gets diagnosed, not edited.
• Refunds without restock in destinations. The support person refunding a destination order unticks restock. Goods that physically return get added to the source 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 drift check below is carrying the entire load.

Weekly

• Run the drift check. 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 destination edit someone snuck in, 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-run the match report 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 source. Cycle counts or full counts, always against the source store. The corrections propagate outward on their own.
• Review low-stock and reorder against source numbers. The source is the only store whose quantities mean anything for purchasing. Destination-side low-stock alerts are noise — turn them off if the app allows it.
• Audit who can edit inventory. Staff permissions drift like everything else. Destination-store staff 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 destination 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 destination 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 from 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), the match report 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 source change overwrites it. The free plan runs the match report, preview mode and difference checks on an unlimited catalogue, which is the whole observability half of this page without paying.