Two apps manage the same inventory: how Shopify's multi-managed inventory works

Your admin says 340 pairs of HIK-CHUNK-M. Your 3PL's portal says 322. Last weekend the storefront sold 18 pairs it couldn't actually ship, and a customer emailed asking why half their order arrived and the other half went silent. Three numbers, three systems, one product — and none of them are "wrong." They're measuring different things at different moments, and until you understand the architecture Shopify uses when an app and your own locations co-manage the same SKU, every discrepancy will look like a bug to chase instead of a structure to work with.

This is the architecture-first view of multi-managed inventory: who writes which number, when each number moves, and the two failure modes the structure produces. (If you're already past architecture and debugging a specific "my stock won't update" symptom, the inventory-not-updating diagnostic owns that problem — this article is the map it assumes you have.)

What multi-managed inventory actually is

Since early 2026, every fulfillment service on Shopify — dropshipping apps, third-party logistics (3PL) providers, custom fulfillment services, print-on-demand services — supports the same model: a product can be stocked at your locations and the app's location at the same time, with each location keeping its own independent count (Shopify Help Center, "Understanding inventory management for multiple locations and apps," as of November 2026). Shopify's own example is a print-on-demand app coexisting with 50 units of the same shirt in your warehouse.

Four properties of the model do all the explanatory work:

• Counts don't pool. Each location's inventory is tracked separately and can't be shared. Your 120 units and the 3PL's 340 units are two different ledgers that happen to describe one SKU.
• Any location can be adjusted by you — including the app's. Quantity at the app's location is technically editable from your admin, whether or not the product is active there. Whether the app respects your edit is between you and the app: treat it as a buffer you manage, and confirm the sync behavior with the provider rather than assuming.
• Orders are assigned by order routing, not by the app. When both your warehouse and the 3PL hold the same SKU, routing decides who gets the order — which makes routing settings part of your inventory architecture, not just shipping plumbing.
• A product must be active at a location to sell from it. Quantity can exist where the product is inactive, and in that case Available displays a dash — the number one most-misread symbol in this whole system.

There's one migration footnote that explains a lot of 2026-era weirdness: between February and mid-March 2026, Shopify migrated all fulfillment services to this multi-location model (per the same Help Center page). Stores that only used fulfillment services kept their workflows; stores that mixed own-stock with app-stock got their settings updated automatically. If an app's inventory behavior changed on you in that window, this is why.

Who writes which number

The retail-only row deserves emphasis because it produces the strangest symptom in the set: an item showing out of stock online while you're looking at a full shelf. Stock at a location that doesn't fulfill online orders doesn't count toward the online quantity — and the reverse trap exists too, where a dropshipping app's products show as out of stock because the app's location is missing shipping rates (both behaviors documented in the Help Center as of November 2026). The number isn't lying; it's answering a narrower question than you asked. The day-to-day discipline of running stock inside a fulfillment partnership — receiving rhythm, sync expectations, who counts what — is the subject of the 3PL inventory management guide.

And the dash: if you transferred stock to a location or imported quantities by CSV and Available shows "—", the product was recorded there but never activated for sale. Activation is a separate flag from quantity — these actions record stock without touching it.

The two failure modes the architecture produces

Once two writers feed one SKU, exactly two things go wrong, and knowing which one you're in turns panic into a checklist.

Failure 1: the lag oversell

The 3PL's number updates on their schedule. Friday's promo sells 60 pairs in two hours; your admin still displays 340 because the last sync predates the rush; the weekend's orders route to the 3PL location because routing sees inventory there; Monday morning their portal reads −18. Nobody made an error. The system did what each part does on its own clock.

Mitigations, in the order they cost you:

1. Ask the 3PL to sync more often. Many support hourly or event-driven pushes. This is the only fix that attacks the cause.
2. Hold a manual buffer. Reduce the quantity at the app's location by a margin you choose (say 5% of on-hand, or a flat floor), so their lag has room to breathe. Since you can adjust any location's quantity yourself, the mechanism is native — just re-verify the app doesn't stomp your buffer on its next sync.
3. Keep rescue stock at your own location. For your top 10 SKUs, a dozen units in your warehouse converts an oversell from a refund into a slightly slower shipment — you can reassign the order to your own location and fulfill it yourself before the 3PL ever sees a request (a documented scenario in the Help Center).

Failure 2: the duplicate shipment

The order was assigned to the fulfillment service, their sync hiccupped or you didn't notice the assignment, and you fulfilled it yourself. Now two boxes are moving. The documented recovery sequence (Shopify Help Center, as of November 2026):

1. Contact the fulfillment service first and confirm whether they've actually shipped. Their answer determines everything after.
2. If they shipped: from the order in your admin, use Change location to move the fulfillment to a location you control, then mark it fulfilled from there. No duplicate box, and your inventory stays accurate on your side.
3. If they hadn't shipped: leave the order assigned, or reassign it deliberately — and tell them to release it.
4. Log it. A sync issue that happened once will happen again; the pattern is your evidence in the next conversation with the provider.

The prevention is boring and works: before manually fulfilling any order, check which location it's assigned to. That single glance is the whole discipline.

A worked month: what the ledgers look like

Worth seeing the arithmetic reconciled once. HIK-CHUNK-M, October: you start with 120 at your warehouse; the 3PL holds 340. You sell 95 through the 3PL and 30 through your own store, and one transfer of 40 moves from warehouse to 3PL mid-month.

• Your location: 120 − 30 − 40 = 50
• 3PL location: 340 − 95 + 40 = 285 (their portal may read 283 if two units were damaged in receiving — that variance is theirs to report, yours to reconcile)
• Total available: 50 + 285 = 335, which is what your admin should show

When the three numbers disagree, this decomposition is the check: your movements minus your sales, their movements minus their sales, transfers in transit belonging to exactly one side at a time. If the ledger adds up but the storefront still misbehaves, then — and only then — it's a symptom worth running the not-updating diagnostic on.

One design note from the tooling side, since it explains a lot of app conflicts: InventoryX deliberately reads your inventory without ever writing it. Co-managed stock has enough writers; a read-only layer that ranks where you're losing estimated revenue can't fight the 3PL's sync for the same quantity, which we consider a feature, not a limitation.

Where multichannel sellers get burned is assuming this discipline transfers up a layer: syncing Shopify with Amazon or Etsy is a different problem — different channel, different writer, same lesson. The multichannel sync guide covers what channel sync actually does and doesn't do, and it starts from the same architecture question this article answers: who owns the number.

Common questions

What is multi-managed inventory on Shopify? It's the model where the same product is stocked at your own locations and a fulfillment app's location simultaneously, each keeping an independent count. Orders are assigned between them by your order routing settings. Since the February–March 2026 migration, all fulfillment services — 3PLs, dropshipping, POD, custom services — work this way.

Can I and my 3PL both manage the same product's stock? Yes, that's the design: you hold some units, the 3PL holds the rest, and each location counts separately. You can even adjust the quantity at their location from your admin, though you should confirm with the provider whether their next sync will overwrite your edit.

Why does Available show a dash instead of a number? The product has quantity recorded at that location but isn't activated for sale there — common after transfers, CSV imports, or bulk edits, which record stock without changing activation. Fix it on the product page: Edit locations, select the location, save.

Why am I overselling when the 3PL shows stock? Their feed updates on their schedule; your admin can display a stale number during a rush, orders keep routing there, and their warehouse goes negative before their next sync. Ask for faster syncing, hold a buffer against their lag, or keep rescue stock at your own location for your bestsellers.

An order shipped twice — what now? Confirm with the fulfillment service whether they shipped, then in your admin change the fulfillment's location to one you control and mark it fulfilled, so Shopify's record matches reality without a duplicate shipment. If they hadn't shipped yet, reassign deliberately and have them release it.

Next step

Open the product you trust least, click Edit locations, and write down the full list of locations holding it — yours and every app's — plus who last touched each number. That five-minute inventory of writers is the input the order routing guide needs next, because who ships from where is decided by settings this article can't see.