In-Transit Inventory: Tracking Stock Between Transfer and Receipt

In-transit inventory tracking between stores means knowing exactly how much stock is on the truck, in the van, or on the loading dock between the moment it leaves one location's shelf and the moment it's checked in at the other — not just the before-and-after counts at each end. For a transfer to be tracked properly, it needs its own status: draft, then in transit, then received, so the stock isn't sitting in a blind spot between two ledgers for however long the drive takes. Retailer OS tracks inter-location transfers this way, with a movement row written at each step, so a manager can answer "where is that stock right now" without calling the other store.

What Does "In Transit" Mean for Retail Inventory?

In-transit inventory is stock that has left the sending location's on-hand count but has not yet been added to the receiving location's on-hand count — it exists only as a transfer record until someone checks it in. Between those two moments, the inventory is real (it's physically on a truck or in a box at the back door) but invisible to a system that only tracks "sent" and "received" as a single instant event, with nothing in between.

That gap matters more than it looks. A two-store operation moving even a modest 15 to 20 line items a week between a warehouse and the sales floor can have several hundred dollars of inventory sitting in a van at any given moment during business hours. That's not a rounding error if it happens to fall during a stock count, or during a reorder calculation that assumes "on-hand" means physically on the shelf right now.

Why Does Stock Go Missing Between Locations?

Stock usually doesn't disappear — it just stops being tracked. The most common causes all trace back to a transfer that skipped a step, or a receiving process that didn't check the delivered count against what was actually shipped.

• No transfer record at all — stock is moved by whoever's driving, and the sending location's count gets adjusted by hand days later, if at all
• The transfer is created but never marked in transit, so it still shows as on-hand at the sending store even though it's already gone
• The transfer sits as in transit indefinitely because nobody closes the loop once it arrives, so the receiving store's count stays permanently short
• Receiving happens by eyeballing the boxes rather than checking quantities against the transfer, so a shortage or an extra case goes unnoticed
• Multiple transfers are moving between the same two locations at once, and it's unclear which shipment a given box belongs to

How Should a Transfer Move From Draft to Received?

A transfer that's tracked properly moves through three distinct states, each with its own effect on inventory:

• Draft — the transfer is created with a list of items and quantities to move, but nothing has shipped yet. Stock still shows as on-hand at the sending location.
• In transit — once the shipment physically leaves, the transfer is marked in transit. Stock comes off the sending location's on-hand count and is flagged as in-transit stock: no longer available to sell at the origin, not yet available at the destination either.
• Received — when the shipment arrives, someone checks the delivered quantities against what the transfer says was sent and marks it received. Stock is added to the receiving location's on-hand count, and any difference is recorded as a variance rather than silently adjusted away.

What Should You Check Before Marking a Transfer "In Transit"?

The in-transit step is only as useful as the data behind it. A few checks before you mark a transfer shipped save a lot of guesswork once it's on the road:

• Quantities on the transfer match what's physically loaded, not what you intended to send
• Each line item's unit of measure is correct — a case transferred as a single unit will throw off both locations' counts
• The transfer is assigned to the right destination, especially if more than one van or warehouse route is running that day
• High-value or serial-tracked items are confirmed individually if your inventory setup tracks them by serial
• Someone at the sending location marks it in transit the same day it leaves, not a week later when they remember

Scanning items in and out of a transfer with a barcode, rather than counting by eye, catches most of these mistakes before the truck leaves the dock. GS1's barcode standards exist specifically to make that kind of scan-based tracking consistent across a supply chain, not just inside one store.

How Do You Handle Receiving Discrepancies on Arrival?

Discrepancies happen — a case gets left on the dock, a box arrives damaged, a count was off at the sending end. The right process isn't to quietly adjust the number and move on; it's to record what was sent, what arrived, and the difference, so the gap leaves a trail. When a transfer is received in Retailer OS, the receiving screen shows what the transfer says should arrive next to what's actually being counted in, and a variance is recorded rather than overwritten. That variance is visible later, which matters: if the same route keeps coming up short, it's usually a packing problem at the sending location, not a receiving problem at the destination.

How Does In-Transit Tracking Affect Your Stock Counts and Reports?

Without in-transit tracking, a stock count taken mid-shipment looks wrong at both ends: the sending location looks like it's missing stock it didn't actually sell, and the receiving location looks short on inventory that's already on its way. With transfers tracked as draft, in transit, and received, a count taken during a transfer reflects reality — the stock is accounted for as in-transit inventory, not vanished or double-counted at either location.

This also matters when comparing sales across locations: if one store's reported on-hand includes stock that already shipped out, its numbers will look better than they actually are until the next physical count catches the difference. It's also why receiving stock sellable the moment it's marked in transit would be a mistake — a transfer gets delayed, short, or rerouted far more often than most vendor shipments, so the receiving location shouldn't treat it as available to sell until it's actually been checked in.

How Does Retailer OS Track Transfers Between Locations?

Retailer OS runs transfers as part of the same inventory ledger that tracks sales, receiving, and adjustments — a transfer isn't a side spreadsheet, it's a movement type with its own audit trail. Each transfer carries draft, in-transit, and received statuses, and every status change writes a row to the per-item, per-location ledger, so the history of who shipped what, when it left, and when it was checked in all lives in one place. Variance found on receiving is recorded with the transfer rather than folded silently into on-hand.

Because every store, warehouse, and van in a multi-location account shares that same ledger, a transfer leaving one location and a receipt at another are two sides of the same record — not two separate systems that have to be reconciled by hand. This is the same discipline covered in multi-location inventory management, and it's what replaces the kind of transfer tracking retailers try to run out of a shared spreadsheet once more than one location is moving stock regularly.

The same checked-not-guessed approach applies on the vendor side: receiving against purchase orders compares delivered quantities to what was ordered rather than assuming the delivery matches the PO, and a received PO generates a vendor bill tracked alongside accounts payable, ready to post to QuickBooks Online as part of the daily sync.