Multi-Location Inventory Management: A Practical Guide
The day you open a second stockroom, your spreadsheet quietly breaks. One "quantity" column can't tell you whether those 300 units are in Toronto or Vancouver, and that gap is where stockouts, dead stock, and frantic transfers come from. Multi-location inventory management is the practice of tracking stock per location while still seeing the whole picture, and doing it well is the difference between a network that flows and one that firefights.
Here is what changes when you go from one location to many, the concepts you have to get right, and a worked example you can copy for your own network.
What multi-location inventory management actually means
Multi-location inventory management means every stock number is tied to a place, not just a product. A SKU no longer has "one quantity." It has a quantity at each location, plus a rolled-up total across all of them.
That sounds obvious, but it forces three things you didn't need before:
- Per-location stock. You track on-hand, reserved, and available at each site independently.
- Transfers. Moving stock between your own locations becomes a first-class action with its own paper trail, not an untracked "I grabbed some from the back."
- Per-location rules. Reorder points, suppliers, and lead times differ by site, so they have to be set per site.
A "location" can be a warehouse, a retail shop's back room, a 3PL, a supplier's consignment shelf, or a van. The mechanics are the same. If stock lives there and you sell or ship from there, it is a location.
The problems that show up with a second site
These are the specific failures a single-quantity system can't prevent:
- Phantom availability. Your total says 500 units, so you promise a customer 40. But 480 are in the wrong province and the local site has 20. The order is short and you don't find out until picking.
- Uneven stock. One location drowns in a slow mover while another stocks out of it weekly. Total inventory looks healthy; the distribution is broken.
- Untracked shrinkage. Stock moves between sites off the books, so your counts drift and nobody trusts the numbers.
- Reorder blindness. A blanket reorder point for the whole company reorders too late for the busy site and too early for the quiet one.
Every one of these traces back to the same root cause: quantity without a location attached.
The concepts you have to get right
On-hand, reserved, and available (per location)
Three numbers, tracked at each site:
- On-hand. Physically present, countable on the shelf.
- Reserved. On-hand but already committed to open orders.
- Available (ATP). On-hand minus reserved. This is the number you can actually promise.
The formula is boring and load-bearing:
Available to promise = on-hand - reserved
Run it per location, not just company-wide. Company-wide ATP tells you if you can fulfill an order somewhere. Per-location ATP tells you if you can fulfill it from where the customer expects it.
Transfers between locations
A transfer decrements one location and increments another, with a status in between (in transit). Treat it like a mini shipment: it has a quantity, an origin, a destination, and a moment where the stock belongs to neither shelf. Skip the in-transit state and your counts lie for the days the stock is on a truck.
Reorder points per product, per location
Each location has its own demand and its own lead time, so each needs its own reorder point:
Reorder point = (average daily usage x lead time in days) + safety stock
A downtown store selling 40 units a day with a 2-day resupply needs a very different trigger than a regional warehouse selling 8 a day with a 10-day supplier. One number for both guarantees you get one of them wrong.
A worked example: rebalancing three warehouses
One SKU, three locations, this morning's snapshot:
| Location | On-hand | Reserved | Available | Sells/day |
|---|---|---|---|---|
| East | 420 | 20 | 400 | 40 |
| Central | 180 | 30 | 150 | 15 |
| West | 50 | 30 | 20 | 30 |
| Total | 650 | 80 | 570 | 85 |
Company-wide you have 570 available and sell 85 a day, so roughly a week of cover. Looks fine. It isn't.
Look at West. Available is 20, daily demand is 30. West stocks out inside a day, and its supplier lead time is 6 days. Meanwhile East is sitting on 400 available against 40 a day, ten full days of cover.
The fix is a transfer, not a purchase order. Days of cover per site, available / sells per day:
- East: 400 / 40 = 10 days
- Central: 150 / 15 = 10 days
- West: 20 / 30 = 0.7 days
Pull stock from East (the site with the deepest cover) into West to level them out. Moving 150 units East to West gives East 250 (6.25 days) and West 170 (5.7 days). Now every site has roughly a working week of cover, and you did it without spending a cent on new inventory or paying rush freight from a supplier. That is the entire point of managing locations instead of a single pile: your own network is often your fastest, cheapest supplier.
Single pool vs per-location: a quick comparison
| Single pool (one quantity) | Per-location | |
|---|---|---|
| Order promising | Guesses, oversells | Accurate to the site |
| Restocking | One blunt trigger | Right trigger per site |
| Transfers | Invisible | Tracked, auditable |
| Reporting | "We have stock" | "Where the stock is" |
| Works for | One location | Any number |
If you run more than one location, the left column isn't a simpler option. It is a source of errors you'll pay for later.
A setup checklist
Getting multi-location right is mostly discipline up front:
- Define every location explicitly, including 3PLs, consignment, and vehicles. If stock lives there, it's a location.
- Set on-hand, reserved, and available per location and stop reporting a single blended quantity.
- Make transfers a tracked action with an in-transit state.
- Set reorder points per product per location, driven by that site's usage and lead time.
- Decide your fulfillment logic: which location ships which orders, and when you rebalance instead of reorder.
- Connect it to your other systems so your store, POS, and shipping tools read the same per-location numbers.
Where Inventoros fits
Inventoros does multi-location inventory management out of the box: per-location stock, tracked transfers, and reorder points set per product per location. It is free, open source, and self-hosted, so your stock data stays on infrastructure you control. It installs on cPanel, a VPS, or with Docker (the documentation walks through each), and its REST and GraphQL API plus webhooks let your storefront and shipping tools read the same per-location numbers you do.
FAQ
What counts as a "location" in inventory management? Any place you hold and ship stock from: a warehouse, a store's back room, a third-party logistics provider, a consignment shelf, even a delivery van. The rule is simple. If inventory physically lives there and you fulfill from it, track it as its own location.
How do I decide which location fulfills an order? Most teams route by nearest location with available stock, then fall back to the next closest if the first is short. Check available (on-hand minus reserved) at the target site, not the company total, so you don't promise stock that's in the wrong place. For expensive shipping lanes, factor in freight cost too, not just distance.
When should I transfer stock instead of reordering from a supplier? Transfer when one of your locations has surplus cover and another is short, and the internal move is faster or cheaper than a purchase order. Compare days of cover across sites: if one has ten days and another has one, a transfer fixes it today, while a supplier order might take a week to land.
Do I need separate reorder points for each location? Yes. Demand and lead time vary by site, so a single blanket reorder point will restock one location too late and another too early. Calculate the reorder point per product per location using that site's own average daily usage and supplier lead time.