Guides

Multiple stores, one inventory: the operating model

Two or more Shopify stores can sell the same physical stock without lying to customers, but not by default and not by discipline alone. This is the architecture question — one source of truth, hub and spoke, and the five rules a team can actually follow.

Running two Shopify stores on one pool of stock is common. Running five is not rare. What is rare is doing it without the stores quietly disagreeing about what is on the shelf — because Shopify gives every store its own private inventory and no way to share it, so agreement is something you have to construct.

This guide is about the construction: the shape that works, the rules that keep it working, and the places it breaks. If you are still deciding whether to run more than one store, start with whether you need a second store at all — every store you do not open is a sync you never run.

Four guides sit next to each other here. This one is the architecture: which shape to build and the rules that keep it true. The others are which method — CSV, a custom build or an app; which routine — the daily, weekly and monthly habits; and expansion stores specifically if you are on Plus.

First, check the premise: one pool or several?

“Same inventory” only means something if the stores sell from the same physical stock. One warehouse, several storefronts: that is the mirroring problem this guide covers.

If each store has its own warehouse — a US store shipping from New Jersey, an EU store shipping from Rotterdam — you do not have one pool, you have two, and mirroring one store’s numbers into the other would advertise stock that cannot ship. That situation wants a different architecture, built on transfers rather than sync.

The shape that fails: a mesh

The intuitive setup for three stores is “keep them all in sync with each other” — every store connected to every other, changes flowing in all directions. It fails for a structural reason, not a tooling one: when two stores disagree, a mesh has no answer to which one is right. Every pairwise connection needs a conflict rule, every conflict rule is wrong in some scenario, and the number of connections grows quadratically — three stores is three links, five stores is ten.

The shape that works: hub and spoke

One store owns the number. Every other store follows it. That is the whole architecture:

• The main store is wherever physical reality is already recorded — receiving, stocktakes, write-offs, returns to the warehouse. Its count is the count.
• The connected stores mirror it, one way. Nobody edits stock in a connected store, because the edit would be a lie with a countdown: the next change in the main store overwrites it.
• Adding a store adds one connection. A fourth storefront is one more spoke, not three more relationships to reason about.

One-way is the load-bearing property. The moment a connected store can write back, you are back to needing a conflict rule, and back to the mesh problem with extra steps. The two-store guide covers why this holds even at N=2.

The five rules that keep it true

Architecture survives contact with a team only if the rules are few and blunt. These are the five:

1. All stock edits happen in the main store. Receiving, corrections, write-offs, stocktakes. If a connected store’s count looks wrong, the fix is an edit in the main store, never in the connected one.
2. Refunds in a connected store do not restock. Shopify’s refund flow offers a restock toggle; in a connected store that toggle writes that store’s own inventory, which the sync will overwrite. When goods physically come back, they come back to the warehouse — record them in the main store.
3. Turn off “continue selling when out of stock” in the connected stores. The mirror can only protect you if zero means stop. A store that keeps selling at zero has opted out of the whole system, one product at a time.
4. Keep SKUs disciplined. Matching runs on SKU, so duplicate and blank SKUs are a ceiling on how well any of this can work. Audit before connecting, and re-check after catalogue edits.
5. Check the counts still agree, on a schedule. A sync that fails does so silently. Comparing every matched SKU across stores — weekly at minimum, daily in season — is the difference between finding a gap and a customer finding it. Overselling is what the gap costs.

The rules have an organisational edge worth stating in the open: staff in the connected stores lose the ability to “just fix” a number. That is the point, and it needs saying out loud to the people it affects, or they will fix numbers anyway and be confused when the fixes vanish.

Rolling it out across three or more stores

Do not connect everything at once. The sequence that avoids surprises:

1. Fix the SKU audit findings in the main store first — every connected store inherits them otherwise.
2. Connect one other store in a preview or dry-run mode. Read what matched: the unmatched list should be exactly the items you expect that store not to carry.
3. Go live on that one store. Watch it for a few days — the difference check should be boring.
4. Repeat per store. Each new spoke is the same procedure against the same source, which is precisely why the hub shape scales and the mesh does not.

What this deliberately does not share

Inventory quantities are the part that must agree. The rest of the catalogue often should not: each store keeps its own prices (a wholesale store depends on that), its own titles and translations, its own collections and merchandising. Products themselves are a separate copying problem with separate tools, and orders stay where they were placed.

That separation is a feature. The stores exist because they serve different audiences; the shelf is the only thing they genuinely have in common.

Where StockUnison sits

StockUnison is the hub-and-spoke model as an app: one main store, one-way sync into as many connected stores as you like, matched by SKU with duplicates refused rather than guessed at. Every connection starts in preview mode, every write is logged, and the difference report is the scheduled check from rule five. Pricing is per live connected store — $19/month for one, $39 for five, $79 unlimited — and the free plan runs matching, preview mode and difference checks across an unlimited catalogue, which covers the entire rollout sequence above except the final go-live.

What it does not do: two-way sync, per-store allocation of a shared pool, or copying products and prices. If the connected stores genuinely need to write back, this is the wrong tool and the honest alternatives are in the comparison.