Shopify inventory transfers: the native workflow, done without corrupting your numbers
How Shopify inventory transfers work — create, in-transit states, receiving with accept/reject/cancel — plus when a transfer beats a new PO and the traps.
InventoryX is in development and not available today. ClearStock is the live Shopify app.
Short answer: Shopify's native transfers (Products → Transfers) move stock between your locations — or to and from external ones like suppliers — through a draft → ready to ship → in transit → transferred lifecycle. While a transfer is in flight, the units are neither sellable at the origin nor available at the destination: they sit in Committed and Incoming states, which is exactly where most transfer mistakes happen.
This guide walks the full workflow verified against the Shopify admin and Help Center as of October 2026, then covers the decisions around it: transfer versus new PO, the lead time a transfer adds, and the receiving discipline that keeps both locations' numbers trustworthy.
The lifecycle, state by state
A transfer is a record, not a physical action — Shopify tracks the units through states as you process it (Shopify Help Center, "Creating and processing inventory transfers," accessed October 2026):
| Status | What you did | What happens to the stock |
|---|---|---|
| Draft | Created the transfer, hit Save | Nothing. Quantities aren't committed; you can edit or delete freely |
| Ready to ship (optional) | Marked as ready to ship | Units become Committed at the origin — set aside, can't be sold |
| In progress | Moved to in transit | Units are marked Incoming at the destination and can be received. A shipment record is created automatically |
| Transferred | All items received | Everything is Available at the destination. Transfer is complete |
| Canceled | Canceled a draft or ready-to-ship transfer | Committed units return to Available at the origin |
Two details from the docs worth internalizing:
- "Mark as transferred" is a shortcut, not a lie. If you've already physically moved the items, this completes the transfer immediately — shipment auto-created and auto-received, stock available at the destination. Useful for the walk-across-the-parking-lot transfer; dangerous when the boxes are actually on a truck for four days.
- Receiving is itemized, not all-or-nothing. At receive time you set each item to Accept (becomes available at destination), Reject (recorded on the transfer, changes no quantities — for items that arrived damaged or wrong), or Cancel (items never shipped — they return to Available at the origin). You can mix actions per line and add a note on why.
One state trap: transferring a product to a location where it isn't stocked records the quantity but doesn't make the product sellable there. At receive time Shopify asks whether to stock and fulfill or hold; choose deliberately, because "Not now" leaves you with on-hand units a channel can't sell — a classic source of "why is this showing stock but the store can't sell it" confusion (for the POS-side version of that, see the POS inventory guide).
Creating a transfer (and what's available while you do)
From Products → Transfers → Create transfer (Shopify Help Center, accessed October 2026):
- Pick origin and destination. Either can be blank — a blank origin is how you receive a supplier shipment into stock, a blank destination ships out to somewhere Shopify doesn't track.
- Add products and enter quantities in the Move column. Shopify shows the resulting change at both locations live, so you can sanity-check before saving.
- Optionally add a reference name, note, tags, and metafields (a carrier or expected-delivery metafield definition makes transfers sortable later).
- Save. You have a draft.
Bulk catalogs don't need clicking through one SKU at a time: a transfer CSV imports variants and quantities into a new or existing transfer (mind the overwrite behavior — re-imported variants replace their existing quantities). Barcode-driven creation and receiving also exist natively, and each transfer can carry multiple shipments — separate batches with their own tracking and expected arrival, received independently (the Inventory Shipments API and its webhooks confirm this structure; Shopify developer changelog, "Inventory shipment webhooks include inventory transfer IDs," accessed October 2026). If half the order is ready and half is a week behind, that's two shipments on one transfer, not two transfers to reconcile.
Transfer or new PO? A decision that's wrong half the time
Merchants default to whichever they used last. The cleaner test:
| Situation | Better tool | Why |
|---|---|---|
| Stock exists at one of your locations; destination needs it | Transfer | No new money spent; native tracking handles both ends |
| Nobody owns the stock yet — it's still with a supplier | New PO | A transfer can't conjure units; you'd be recording a move of nothing |
| Supplier ships direct to your retail location instead of the warehouse | Either | A transfer with a blank origin records the inbound shipment cleanly; a PO keeps supplier history and costs in one place |
| Moving stock to an external consignment or event location | Transfer (blank destination) | Tracks the units leaving without pretending they're sellable somewhere you control |
The honest frame: a transfer is logistics — moving units you already own. A purchase order is procurement — buying units you don't. When both are true (supplier ships to your warehouse, you then move stock to stores), they chain: PO receives at the hub, transfers fan out. The purchase order guide covers the receiving half of that chain.
Transfer lead time is a real lead time
A three-day van trip between your locations behaves exactly like a three-day supplier lead time for the destination: units on the road can't sell, and destination demand during transit is served by nothing. The destination's days of cover calculation should treat in-transit stock as unavailable until received — the Incoming state exists precisely because Shopify doesn't count it as sellable, and your planning shouldn't either.
Worked example — a coffee roaster moving bags from warehouse to café, illustrative numbers:
- COF-ETH-250 (250g Ethiopia bags): café sells 9 bags/day steady.
- Café stock at Monday open: 26 bags — 2.9 days of cover.
- Warehouse has 180 bags. A transfer is created Monday, marked in transit same day, and takes 3 days (van runs Tuesday/Thursday).
- The bags land Thursday — but the café's stock ran out Wednesday night. Thursday morning the café is dark on its bestseller while 180 bags sat "in the system" since Monday.
The fix isn't transferring earlier by guesswork — it's treating the transfer like any replenishment: destination demand rate (9/day) × transfer lead time (3 days) means the transfer needs to leave while the café still holds ~27 bags plus buffer, not 26. If your transfer lead times have their own rhythm (the Thursday van), write them down per route the way you'd record a supplier lead time — a transfer that's "usually 2 days, sometimes 5" is a lead time you haven't measured.
Receiving discipline: where transfer data goes to die
The transfer record is only as good as the receive step. The failure patterns:
- Receive before the boxes are opened. Accepting all items unopened records quantities nobody verified. Eight weeks later a count finds the discrepancy and nobody can say whether the transfer or the supplier receipt was wrong. Count against the transfer line items when you receive — the accept/reject/cancel structure exists for exactly this.
- Rejecting without notes. A rejected quantity with no comment is a mystery with a deadline. The note field on each receive action is the cheapest audit trail you'll ever keep.
- Selling out of the receiving bin. Received-and-available units that haven't been put away get sold from the staging area, then counted wrong at the next count. Put-away is part of receiving, not a task for later — the same rule the cycle count guide applies to supplier receipts.
- "Mark as transferred" on faith. Completing a transfer because the driver left, not because the pallet arrived, puts phantom stock at the destination — sellable numbers with no physical units behind them. That's how oversells start at the destination while the origin shows the units gone.
If transfers happen weekly, the watchdog is a saved view: check the Incoming tab on the Inventory page for quantities aging past their expected arrival (you can click a variant's incoming quantity to see exactly which transfers make it up).
Multi-location honesty: where planning tools fit
Transfers are native and free, and they handle the tracking well. What they don't do — and what native Shopify broadly doesn't do as of October 2026 — is the planning across locations: per-location velocity, per-location reorder points, suggested transfer quantities based on demand at each end. You set quantities by judgment; Shopify records the result.
That's also where we'll state our own limits plainly: InventoryX (in development) does not do multi-location optimization — it doesn't split demand per location, suggest transfer quantities, or optimize distribution across locations; its buying list and out-of-stock ledger are built for a single pool of stock. If your operation lives and dies by two-location balancing, you need the native transfers plus your own spreadsheet for the destination-level math. We'd rather say that than let you install the wrong tool.
Common questions
How do I transfer inventory between locations in Shopify? Go to Products → Transfers → Create transfer, pick origin and destination, add products with quantities in the Move column, and save as a draft. Process it by marking ready to ship (commits stock at origin), moving to in transit, or marking as transferred if the items already arrived. Receive at the destination by accepting, rejecting, or canceling line items (Shopify Help Center, as of October 2026).
What does "in transit" mean in Shopify inventory? In-transit units are marked Incoming at the destination location — on the Inventory page's Incoming tab — and are not available to sell until received. At the origin, marking a transfer "ready to ship" puts the units in Committed, so they can't be sold twice. Only the Receive step with Accept makes the units available at the destination.
Can I receive a partial transfer in Shopify? Yes. Receive items line by line — accept some, reject damaged units, cancel lines that never shipped — and the transfer stays In progress until every item is resolved. You can also split a transfer into multiple shipments with their own tracking, each received independently when it lands.
Should I use a transfer or a purchase order? Use a transfer when the units already exist at one of your locations and you're moving them; use a PO when you're buying units from a supplier. A transfer with a blank origin is also the native way to record a supplier shipment arriving direct at a non-warehouse location — but POs keep supplier cost and history attached, so use them when procurement matters.
Why can't I sell transferred inventory at the destination? The units are Incoming, not Available, until received — and if the product was never stocked at that location, receiving doesn't automatically activate it. When you receive, choose "Stock and fulfill" to make the product sellable there, or activate the product at the location afterward from the product's inventory settings.
Next step: open Products → Transfers today and look at anything sitting In progress past its expected arrival — that's stock you paid for and nobody can sell. Then write down your actual transfer lead times per route; the café example above shows why "usually two days" isn't a number you can plan with.