Multi-Branch System Architecture: Where to Share Data and Where to Keep It Separate

Going from one store to two doesn't double your system's complexity — it quintuples it. Our own inventory-management SaaS powers the daily operations of a physical franchise network, so every decision in multi-branch architecture — what to share, what to keep separate — is an answer we earned through real operations. This article lays out the most critical boundaries so you can think them through before opening store number two, instead of tearing everything down and rebuilding after.

First, get clear: are you corporate-owned or franchised?

This is the watershed for every architecture decision. In a corporate-owned chain, branches are "different counters of the same company," so data leans toward sharing. In a franchise network, branches are "independent business entities," so data leans toward isolation. Many systems go wrong by building a franchise with corporate-chain thinking — franchisee A can see franchisee B's purchase costs and revenue, which is a business disaster. The reverse hurts too: force isolation onto a corporate chain and headquarters has to pull data store by store just to see the big picture.

There's no standard answer for multi-branch architecture — only the correct order: answer the business relationship first, then answer the data architecture.

Four questions you must answer

1. Is inventory shared?

Corporate chains commonly allow inter-store transfers, which means inventory needs two layers — "total inventory + per-store inventory" — and a transfer is a documented movement, not just editing two numbers. Franchise networks are the opposite: each store's inventory is its own asset, and restocking is a "purchase" from headquarters — a real transaction in the system that touches receivables and payables. A trap we fell into ourselves: early on we lazily implemented transfers as "just change the quantity," and when stocktakes didn't reconcile, there was no way to trace why. We rebuilt it as document-based, so every inventory change has a traceable source — the same core idea as our article on why inventory numbers go wrong.

2. Is membership shared?

The consumer's instinct is "you're the same brand — why can't I use my points at another store?" So membership should almost always be shared at the brand level. But the devil is in revenue splitting: when a member recruited by store A spends at store B, whose books absorb the points cost? In a franchise network this is a real-money question. The system must record both the member's "home store" and the "store where the purchase happened," so headquarters has the data to define settlement rules. Members can cross stores, but the money must reconcile — you need both.

3. Who sets prices?

The common structure is "headquarters sets suggested retail prices; branches adjust within an authorized range." In the system, build it as "headquarters price list + branch overrides" — not each store maintaining its own full price list. The latter is guaranteed chaos: every headquarters price change will miss some store. Promotions work the same way: headquarters campaigns apply to everyone; branch-run events affect only that branch.

4. Who can see what?

The permission matrix should be sliced by store: a store manager sees everything in their own store, headquarters sees all stores, and a franchisee must never see another store's costs and revenue. Build this layer into the system's foundation — not by hiding buttons in the frontend. Hidden buttons don't stop anyone who knows how to open the browser's developer tools.

Reporting: the headquarters view is a different world

Single-store reports are about operations; headquarters reports are about comparison — revenue rankings across stores, how the same item sells differently by location, growth curves of new versus mature stores. A practical warning here: stores differ in size, so comparing absolute values is misleading. Normalized metrics — sales per square meter, revenue per staff member, average basket size — are the fair comparison. We've watched a headquarters berate a small store's manager over the revenue ranking when that store actually had the highest per-staff productivity in the whole network. Design the reports wrong, and management decisions go wrong with them.

When should you deal with this?

Honest advice: think about it when you have one store, but don't build it all. Reserving the "branch" dimension in your data model (every order and every inventory movement tagged with a store ID) costs very little. When store number two actually opens, add transfers, permissions, and headquarters reporting then. The most expensive path is reserving nothing — two stores each running their own system, then paying for a data merge six months later. If you're on the road to opening more locations, we'd love to talk — this is the problem we operate every day. See our custom systems and SaaS services.