Balancing inventory between sites: when it's worth it

As soon as a business has two warehouses, someone eventually asks: "why are we buying in Lyon what's sitting in Lille?" The question is fair. The answer — "because moving it costs more" — is often fair too, and almost never demonstrated.

Why balancing stops on its own#

Why does inter-site balancing stop on its own?#

Nobody decides to stop. At the start, you transfer. Then one transfer goes badly — the goods arrive damaged, or arrive after the customer has ordered elsewhere, or the site that gave finds itself short the following week. The manager of the site that gave gets a telling-off. Next time, they say they have nothing available.

After two or three episodes, balancing is dead, without any decision having been made. Each site protects its own inventory, which is rational from its point of view and expensive from the group's.

It is an incentive problem, not a tooling one#

It is an incentive problem before it is a tooling problem. If the P&L of the branch that gives records a loss while the gain lands elsewhere, the branch will stop giving. No software fixes that — only the internal recharging rule fixes it.

The calculation, in one comparison#

Transferring pays when:

transfer cost < rebuy cost − recovery value on site

Let's break down the three terms, because that's where the mistakes hide.

What does the real cost of a transfer include?#

It It includes picking at the origin site, packing, transport, receipt at the destination, and the risk of damage. On small quantities, handling often exceeds transport.

Rebuy cost is not the catalog price#

It's the landed purchase price, transport and import duties included. In some geographies, goods bought at a hundred cost a hundred and twenty once on the dock. That coefficient completely changes the trade-off, and many businesses don't have it in their system: it's reconstructed separately, in a spreadsheet, at year end.

Recovery value on site#

It is what you'd get from the goods if you kept them: a probable sale, or a clearance value. On a fast-moving item it's high — and the transfer loses its point, since the origin site will sell it anyway.

Freight isn't proportional to distance#

This is the costliest misconception, and it's thoroughly counter-intuitive.

A busy route, with volume in both directions, costs little per mile. A secondary route is expensive, whatever the distance. I've seen sea freight between two neighboring islands, about a hundred and fifty miles apart, cost twice the freight from a mainland port more than four thousand miles away. Simply because on the first route there is one sailing a week and very little volume.

The practical consequence: your matrix of transfer costs between sites is not symmetrical and does not follow the map. It has to be built once, site by site, direction by direction, with real tariffs.

The last two rows are the ones that decide. It's half a day's work, and it's the piece of data most often missing.

We always knew it was expensive in that direction. We'd never put the figure next to it.

The three conditions for balancing that lasts#

When we put this kind of mechanism in place, we check three things before writing a single line of code. Without them, the tool will be worked around within six months.

The site that gives must not lose#

The goods are recharged at value, the transfer is neutral for its P&L, and its service level isn't degraded by what it gave away. Otherwise, it won't give again.

The proposal is automatic, the decision human#

The application spots the excess on one side and the need on the other, does the calculation, and proposes. A manager approves, knowing both situations. Nobody wants to discover on Monday morning that an algorithm emptied their shelves over the weekend.

A window, not a continuous flow#

Grouping transfers onto one weekly departure divides the unit cost. A one-off transfer triggered by every alert always costs too much.

What it looks like in practice#

In the applications we deliver, this is one weekly screen: surpluses on one side, shortages on the other, and for each possible match, the calculated net gain — transport, handling and landed coefficient included. Sorted by descending gain.

The manager checks it off, the transfer order goes out, and the internal recharge happens by itself. What used to take half a day in a spreadsheet, and for that reason was only done when someone thought of it, becomes fifteen minutes on a Thursday.

And above all: the lines whose net gain is negative don't appear. That's the main value of the calculation — it prevents as many transfers as it triggers.

How we make the trade-off possible#

Transfers between sites are decided badly because you only ever see one site at a time. What we put in place is a per-SKU view across every site at once, with each one's cover beside it.

From there the trade-off becomes arithmetic: what sleeps here and is missing there surfaces on its own, with the transport cost set against the cost of the stockout. It is the same threshold mechanic as replenishment, applied between your sites. See the inventory and replenishment module.

Inter-site balancing: what to remember#

A transfer is never free just because the goods are already paid for. Compare its full cost to the cost of a landed rebuy, not to the catalog purchase price.

Build your freight matrix site by site and direction by direction: it doesn't follow geography, and it's what decides.

Finally, settle internal recharging before the tool. Balancing that penalises the giver stops of its own accord, however good the software.