Multi-Location Inventory in Tanzania — A Practical Guide

The moment stock leaves one branch, it belongs to nobody

Single-site stock control is an accuracy problem. Multi-branch stock control is an accountability problem, and it has one recurring failure point: the transfer. A carton leaves the Kariakoo warehouse on a Tuesday, arrives at the Mwanza shop on a Thursday, and for those two days it exists in a state that most Tanzanian businesses have no name for. Head office thinks Mwanza has it. Mwanza has not seen it. When it turns out to be four units short, there is no document that establishes where the four went — so the loss is absorbed, the conversation becomes personal, and it happens again next month.

Everything below is about giving in-transit stock a name, a document and an owner. If you are looking for the underlying single-site disciplines — cycle counting, ABC classification, landed cost — those are covered separately in our guide to inventory management best practices. This page is only about what changes when there is more than one location.

Make "in transit" a real stock state

In a working multi-branch system, stock has three states, not two: on hand at a location, in transit between locations, and received. A transfer moves stock out of the sending branch's on-hand balance into a transit balance that neither branch can sell. Only the receiving branch's confirmation moves it into their on-hand.

This matters for three reasons. It stops the same units being counted twice in a consolidated valuation. It stops a branch selling stock that is still on a lorry. And — the important one — it means that at any moment you can produce a list of every transfer that has been dispatched but not confirmed, with an age against each. That aged transit list is the single most useful control report in a multi-branch business, and almost nobody runs it.

The transfer document: what it has to carry

Treat an inter-branch transfer with the same formality as a sale to an external customer. The document should be raised at the sending branch and carry:

• A unique transfer number that both branches quote. "The delivery from last week" is not a reference.
• Line-by-line quantities with the unit stated — cartons or pieces, never ambiguous. Unit-of-measure confusion between branches is a top-three cause of phantom variance.
• Batch or serial detail where you track it. A transfer that drops batch information destroys traceability at the destination.
• The dispatcher's name and the date and time of dispatch.
• The carrier — own vehicle, bus parcel service, courier — and the waybill or parcel number, because that is what you will need if goods go missing between Dodoma and Mbeya.
• Space for the receiver's count, name, signature and date, separate from the dispatch quantities. If the same column is used for both, the receiving branch is simply agreeing with what they were told.

Our delivery note template gives you a printable starting point if you are still on paper. The critical rule, on paper or in software, is that the receiving branch counts before signing, and records what they actually counted, not what the document says. A signature that precedes a count transfers the loss to the receiving branch and teaches everyone that the process is theatre.

Investigating transfer variance

When dispatched and received quantities disagree, resolve it within 48 hours — not at month-end. A short escalation ladder that works:

1. Recount at the destination, with a second person, before raising anything. A meaningful share of "missing" stock is miscounted stock.
2. Check the unit. Was a carton of twelve recorded as twelve pieces or one carton? Most variance dies here.
3. Check the dispatch record and the vehicle. Was the last item left on the loading bay?
4. Assign the difference explicitly to sending branch, receiving branch, or carrier, and post an adjustment against that branch's account. An unassigned variance is a variance that will repeat.
5. Track variance by route and by dispatcher over time. One bad month is noise. The same route losing stock every month is a pattern, and it is the pattern — not the individual incident — that tells you what to fix.

Who buys: central purchasing versus branch autonomy

Multi-branch Tanzanian businesses tend to sit at one of two extremes, and both are expensive. Fully central purchasing gets better prices from suppliers but leaves upcountry branches out of stock on lines the head office does not see moving. Fully autonomous branches respond to local demand but destroy your buying leverage and fill each shop with a slightly different assortment nobody can consolidate.

The usable middle: central purchasing for the A-class items where volume buys you a real discount and demand is predictable, plus a controlled local purchase allowance for fast-moving low-value lines and genuinely local products. Publish the split explicitly. Ambiguity here is what produces the classic pattern of one branch holding eight months of an item while another has been out of it for three weeks.

Whichever model you choose, set reorder points per branch, not group-wide. Demand patterns differ by location, and so does lead time — restocking a Dar branch from the central store is not the same problem as restocking Mbeya. The formula is the same everywhere: reorder point = (average daily demand at that branch × lead time to that branch) + safety stock. Our reorder point calculator works it through, and notes that a branch fed by imports needs a heavier safety-stock buffer when the Dar port is congested. Where one branch is long and another short on the same item, a transfer is almost always cheaper than a new purchase — but only if your system can show you both balances at the same time.

Counting when you cannot close everything at once

A group-wide stock take that closes every branch on the same Sunday is the textbook answer and is rarely practical past three locations. The alternative is rolling cycle counts: each branch counts a defined slice of its catalogue every week — the A-class items monthly, B-class quarterly, C-class annually — so that everything is counted within the year without ever closing the doors.

Two rules make this work across branches. First, a branch never counts on the same day it receives a transfer; count first, then receive, or the transit stock contaminates the count. Second, the count sheet is generated blind — without the system quantity printed on it. A counter who can see the expected number will write the expected number. This one change typically surfaces more variance in the first month than the previous year of counting produced.

Pricing, valuation and the reports that matter

Branches in different cities frequently need different prices — transport into the interior is a real cost, and local competition differs. Support that with per-branch price lists rather than manual overrides at the till, so that a price difference is a deliberate policy you can report on rather than a cashier's discretion you cannot audit.

On valuation, decide early whether cost is held per group or per branch. Holding cost per branch is more accurate once transport into the interior is capitalised into the transferred item, and it stops upcountry branches looking artificially profitable because they are carrying Dar es Salaam's cost base.

The reporting set for a multi-branch operator:

• Aged in-transit transfers — anything dispatched and unconfirmed beyond your normal transit time.
• Stock cover in days, by branch and by item. Total group stock hides the branch that is about to run dry.
• Transfer variance by route and dispatcher, trended monthly.
• Same item, long at one branch and short at another — a rebalancing worklist, not just a report.
• Dead stock by branch, because slow at one location is often fast at another.

The upcountry connectivity problem

A branch in a small town will lose its connection, and it cannot stop trading when it does. Confirm before you commit that the till keeps selling offline, queues its fiscal submissions, and — the part that is easy to overlook — that transfers received during an outage sync correctly rather than duplicating when the link returns. Test it deliberately: dispatch a transfer, take the destination offline, receive it, restore the connection, and confirm the stock moved exactly once. Systems that double-post offline receipts will hand you a stock ledger you cannot trust across the whole group.

For how these workflows are set up, see the Tawala inventory module, and purchase management for the central-versus-branch ordering split.