Designing multi-warehouse stock and transfers as you grow past one location

With one warehouse, most of this does not exist

With a single location, "how much stock do we have" is one number. Add a second and it becomes a set of numbers, and several new questions appear at once:

• An order arrives — which location ships it?
• Neither location has enough but together they do. Is that in stock?
• While goods move from A to B, whose stock are they?
• Does counting have to happen on the same day everywhere?

This article covers the design choices behind those questions, and what choosing wrongly costs.

First, separate "warehouse" from "bin"

These get used interchangeably but sit at different levels:

A common mistake is skipping warehouses and expressing location as a bin (making "the shop" a bin). It works briefly, then blocks per-location costing and transfers — and correcting it later means rebuilding history.

Conversely, small warehouses do not need bins. Bins defined too finely at rollout end up unmaintained, which is worse than not having them.

Which location ships

Three common strategies:

Fixed assignment — each channel is tied to one location. Simplest and most predictable; will not automatically look elsewhere when that location is short.

Priority order — check locations in a defined sequence. Suits a main location with a backup.

Nearest location — pick by delivery address. Cheapest freight and fastest delivery, but needs address-to-location rules, and returns need a destination decision.

Start with the first or second. The third only pays off at volume, while its complexity is due immediately.

Sellable quantity: the question that causes the most trouble

Two locations hold five units each. A customer wants eight. In stock or not?

• Aggregate — show ten. Higher conversion, but shipping splits into two consignments, raising freight and handling, and the customer may receive two parcels
• Per-location — show five. No split shipments, but you cannot sell eight of the ten you actually hold

There is no universal answer; it depends on what a split costs you. What matters is choosing explicitly and writing it down. The worst outcome is a storefront using aggregate while the back office uses per-location — orders get taken that cannot be shipped.

Transfers: in-transit needs its own state

Goods have left A and not arrived at B. Where are they?

If the system only has "issue" and "receive", then during that window they are in no location at all, so the company total silently drops and the books cannot reconcile. With transit times over a few days, or across a month end, this becomes very visible.

A transfer should have three states:

1. Created — nothing has moved; stock is still at A
2. In transit — deducted from A, not yet added to B, but still counted in the company total
3. Received — added to B, with the ability to record a discrepancy if the received quantity differs from what was issued

That discrepancy record matters. Damage and shortfall happen. If the system insists received must equal issued, the warehouse will work around it another way and the books scatter again.

Cost travels with the goods

A transfer does not move quantity only — it moves cost.

If A's weighted average cost is 100 and B's is 120, B's cost has to be re-weighted after the transfer. Ignore this and per-location stock values will not add up to the general ledger.

Also decide: who bears the freight? Capitalised into B's stock cost, or expensed in the period. Both are defensible; being inconsistent is not.

When not to open a second warehouse

One argument the other way: if two locations genuinely back each other up and sit close together, treating them as two bins of one warehouse may be simpler — no transfers, no in-transit state, no argument about sellable quantity.

A warehouse exists because something needs to be calculated separately. If it does not, do not split it.

Further reading

• How to synchronise multi-channel inventory
• What data to prepare before an ERP rollout
• Inventory system vs ERP