Inventory & Channel Sync
How do I run two Shopify stores from one warehouse without overselling the same units?
Selling from two Shopify stores that share one warehouse without double-selling the same stock.
Last updated September 16, 2026
Shopify locations do not cross stores. Store A cannot see Store B's location, and a transfer inside one admin does not move units in the other. Two brands, two markets, or a wholesale store plus a DTC store still share one physical pile if they ship from the same warehouse. The storefronts do not know that.
Markets versus a second store
Shopify Markets is not a second store. Use Markets when the catalog, the theme, and the inventory pool are the same and you only need a local currency, domain, or tax. Stand up a second store when the brands, the catalogs, or the wholesale login cannot share an admin. Two stores do not share a location. They can share a warehouse only if something else publishes into both.
Why sync apps race
Apps that bounce counts between two Shopify databases race. Store A sells 3. The app writes 7 to Store B, then Store A's next export writes 10 back, then Store B sells 4 of a number that was already gone. You will spend the week reconstructing timestamps. Sync apps treat each Shopify on-hand as the truth. Neither is. Two databases both trying to own the same units is the oversell.
Publish from one warehouse ledger
The durable model is one warehouse ledger that publishes available-to-sell into each store. Same units. Two published numbers. Fund a buffer, or a pool, per store the way you would per channel: Store A gets a funded qty or a percentage cutback, Store B gets the remainder, or both get published slices that add up to less than on-hand. The ledger decrements once, when the warehouse allocates. Each store only sees what you published. A race between two Shopify exports cannot write stock back up, because Shopify is not the source.
Do not let either store publish on-hand. Do not map the same Shopify location into both stores and hope. Do not inventory-adjust Store B when Store A sells. Receive into the ledger, not into a store. Cycle-count the building, then republish. Item-level buffers override store defaults. Do not buffer twice if a storefront already holds stock back.
If one store is wholesale-only, fund that store like a wholesale pool and keep DTC on the other store as remainder. Orders from both stores must land as native orders against the same on-hand. A spreadsheet that moves units from Brand A to Brand B is how both oversell. Closed or leftover locations left mapped on either store will still take orders.
Same pile. Two storefronts. One publisher. If you cannot name the ledger that decrements first, you have a sync app, not a pool.
Connect Claude or ChatGPT to your Fulfil data with the Fulfil MCP, then run this prompt on your own numbers.
You are the ops lead running two Shopify stores from one warehouse. Here is: sku, on_hand, store_a_published, store_b_published, store_a_sold_today, store_b_sold_today, sync_app (y/n), ledger_is_source (y/n). [paste] Produce: 1. Honest ATS to publish to each store (slices that sum to less than on-hand). 2. SKUs where the two Shopify numbers plus sold qty exceed the pile. 3. Whether a sync app is bouncing counts (race) vs a ledger publish. 4. Locations mapped on a store that should not sell that stock. Same units, two published numbers. Shopify locations do not cross stores.
Explore this in Fulfil
More on Inventory & Channel Sync
How to manage inventory across multiple warehouses without overselling
How to publish accurate available-to-sell for each warehouse so your channels stop overselling.
One order hub for Shopify, Amazon, and wholesale
Running Shopify, Amazon, and wholesale orders from one system instead of three disconnected tools.
ABC classification for DTC
Using ABC analysis to focus your counts and reorder attention on the SKUs that matter most.
See it run on
your data.
Fulfil runs inventory, fulfillment, purchasing, and accounting for scaling DTC brands in one system.