What changes when you go from one branch to three: price lists per branch, stock per location, permissions, and reporting that is both consolidated and separate.
Key takeaways
- The moment there are two locations, stock without a location field is simply wrong.
- Per-branch pricing is a real need, so it must be a field rather than a note.
- Consolidated and per-branch reporting are both required, from the same data.
- The critical decision is what is defined once centrally and what per branch.
A second branch is not a duplicate of the first but a structural change: from that moment every data point carries a location. Stock is no longer "how many" but "how many where", a report is not one number but a number per branch plus a consolidated one, and permissions are not "who can edit" but "who can see whom".
What changes with more than one branch
| Area | One branch | Several branches |
|---|---|---|
| Stock | One quantity | A quantity per location plus transfers between them |
| Prices | One price list | A base list plus per-branch exceptions |
| Permissions | Who edits | Who sees which branch |
| Reporting | One number | Per branch and consolidated |
| Documents | One series | A series per branch, or a branch identifier inside |
| Customers | One list | A shared customer with activity per branch |
The last row is the surprise: a customer who bought at one branch and returns to another must be recognised, or each branch builds its own customer list - exactly the duplication problem described in duplicate customer records between systems.
The decision that sets everything else
What is managed centrally and what locally. There is no single right answer, but there is a split that works in most chains:
- Central: the item catalogue, base price list, discount policy, document wording, permissions.
- Local: stock, staffing, purchase orders from the central warehouse, customer activity.
- Varies by chain: prices - some chains are entirely uniform, others allow limited deviation.
What does not work is letting each branch maintain its own catalogue. Within a year there will be three names for the same item, and every consolidated report becomes a manual merge. The practical compromise is a central catalogue with a short request process: a branch asks for a new item, one person approves and adds it, so the local need is met and the catalogue stays consistent.
Inter-branch transfers - where it breaks
Moving goods between branches is the movement most businesses fail to record, and it produces the largest discrepancies. Branch A sends, branch B receives the next day, and in between the goods are in neither place - or worse, in both.
The structure that works is a two-step movement: a dispatch from branch A creating "in transit", and a receipt at branch B closing it. What matters is having a list of whatever has been in transit for more than a day or two, because that is where the discrepancies hide - and in many chains it is the only list needed to eliminate most stock-count gaps.
Permissions: who sees whom?
In a chain the important permission is viewing rather than editing. A branch manager who can see every branch's sales has information you may not want them to have; on the other hand, a manager who sees nothing but their own cannot compare and improve.
The decision should be explicit rather than a default: what a branch manager sees about other branches - nothing, sales figures only, or everything. Also decide who can see wages and costs, because that is the field most often exposed by accident when someone is given access to a profitability report.
A related point: who may actually change a price at the moment of sale. A chain that lets any staff member drop a price "to close it" discovers after six months that the real price list differs from the configured one. The fix is not a blanket ban but a discount range per role, with approval required above it - so a discount stays a selling tool rather than becoming the default.
Reporting: consolidated and per branch
The basic requirement is seeing the same metric at two levels. What is usually forgotten is the comparison between them - not just how much each branch sold, but how much relative to its size, opening hours and local footfall. Without that normalisation the report always shows the big branch doing best, which is not information.
Three metrics worth holding per branch: sales per opening day, average transaction value, and how much of its stock has not moved in ninety days. The third is the least common and the most useful, because it reveals that the problem is not selling but the stock mix the branch was given.
What to ask before opening the second branch
Five questions that are easy to answer before opening and very hard afterwards:
- Who owns the catalogue - one person, centrally, and how a branch requests a new item.
- How stock is ordered - from the central warehouse, direct from suppliers, or both.
- What happens to a customer who bought at branch A and arrives at branch B - including returns and warranty.
- Which branch is credited for a sale that started at one and completed at another.
- Who closes the day and what happens when the figures do not reconcile.
Question four looks formal and is a genuine source of friction between branch managers, especially where there are performance incentives. A simple rule agreed in advance - the branch that took the money, for instance - beats an argument in every individual case.
How not to replicate the mess
The natural temptation is to copy what works at the first branch exactly. The problem is that most of what works there works because of people rather than process: a manager who remembers the regulars, a staff member who knows where everything is, and an owner who is there every day.
That makes the fortnight before the second branch opens the cheapest opportunity you will get to write processes down - how goods are received, how a shift opens, what happens on a return - while the business is still small enough for someone to remember them all. Once there are three branches, the same work happens on the move and costs far more.
Sources
Frequently asked questions
When do you move to a system that supports branches?
In practice when the second branch opens, not later. The reason is practical: adding a location field to historical data is a project, so it is better to start recording it from the new branch's first day - even when it currently looks unnecessary.
Can two branches run on two separate systems?
They can, and it works when branches are fully independent - separate stock, separate customers, no transfers. The moment goods move between them or a customer buys at both, the separation costs more than it saves.
What about franchising?
That is a different case, because the franchisee is a separate business with its own books. What stays central is the catalogue, the brand and the recommended price list; what stays separate is the money. Settle that boundary in writing before configuring anything.
How do you handle different prices between branches?
As one base price list with defined exceptions, not a separate list per branch. The distinction matters: a defined exception can be seen, approved and withdrawn; a separate list becomes, within a year, three lists nobody remembers the reason for.
Keep reading
Related service
Inventory & Purchasing
SKU-level stock, reorder rules and an approval flow that leaves a record.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.