Running several branches without losing track of any of them

A single-location business has an easy life: everything that exists belongs to the one place it could belong to. The second branch removes that assumption from every table in the system at once, and the failures it produces are peculiar - not wrong numbers so much as missing ones.

The invisible-record problem

When a system filters records by branch, a record with no branch belongs to no branch, so it appears in no list. It is not deleted and no error was raised. It simply never shows up, for anyone.

This is the single most common multi-branch bug, and it is worth knowing because the symptom is so unhelpful: a user swears they created something, and it is genuinely in the database. The cause is almost always a record created through a path that forgot to stamp the branch - an import, an API call, a background job, a record created before the second branch existed.

Two things prevent it. Every creation path must set the branch, including the ones nobody thinks of as creation paths. And an administrator needs a way to see unassigned records, because without it there is no way to find what has already fallen through.

Decide what is shared and what is not

Some master data is company-wide and some is per branch, and the decision has to be deliberate rather than emergent.

• An item is normally one item company-wide, with stock per warehouse. Two branches with their own item lists cannot report a consolidated stock figure.

• A customer is usually company-wide, but who may see them is per branch.

• Price lists go either way, and this is worth deciding early: a branch allowed its own prices is a branch whose margin you must analyse separately.

• Cash boxes, bank accounts and numbering series are per branch almost always. Two branches sharing a receipt series is a reconciliation problem on day one.

Transfers are two events, not one

Goods leaving branch A and arriving at branch B are separate facts with separate dates, and the gap between them is real - the goods are in a van. A system that models a transfer as a single instantaneous movement will show stock in two places or neither during that window, and the month-end that falls inside the window will not balance.

Model the goods in transit explicitly. It is one more state and it removes a whole class of unexplainable difference.

Report per branch and in total, from the same data

The test is whether the sum of the branches equals the company figure, on every report, without a reconciling line. If it does not, either something is unassigned, or something is being counted twice - and both are worth finding, because both distort the comparison you opened the report to make.

Branch comparison is the main reason to run multiple branches in one system rather than several. It only works if the allocation rules are the same everywhere: one branch charging its delivery costs to a central account and another charging them locally will produce a margin comparison that is pure accounting artefact.

And one practical warning

When you add a branch, run a check for records with no branch before anyone starts working in it. The cheapest moment to find unassigned data is before it has a year of transactions attached.