What is branch accounting, exactly?
Branch accounting treats each business location as a first-class unit inside your books. Every transaction — a sale, a purchase, a stock movement, an expense — carries the identity of the branch it belongs to, so at any moment you can answer two questions at once: how is the whole company doing, and how is THIS shop doing. One question is for the tax authority and the bank; the other is for you, deciding whether location two deserves a location three.
You need it earlier than most owners expect. The trigger is not size — it is the second till, the second stockroom, the second team. The day two locations share one undivided ledger, every number becomes an average: average margin, average stock, average performance. Averages hide exactly the thing a multi-location owner must see, which is that one branch is usually carrying another. Branch accounting exists to stop the strong shop subsidising the weak one invisibly.
The two models — and the trap dressed up as a third.
Model one is the old way: each branch keeps its own separate ledger, and head office combines them at month end. It works, and for legally separate entities it is required — but for one company with several shops it recreates the same reconciliation pain as running several companies: inter-branch balances that never agree, three closes instead of one, and a consolidated view that is always weeks stale.
Model two is the modern way: ONE ledger where the branch is a native dimension on every transaction. One chart of accounts, one close, and per-branch statements that are simply filtered views of the same books. Consolidation stops being a monthly project because it is the default state.
The trap is the thing in between, sold as "location tracking" or "class tracking" by single-entity accounting products: a text tag stapled onto transactions. Tags produce a tolerable per-branch P&L — and nothing else. They cannot scope inventory cost by branch, cannot process an inter-branch transfer without inventing workaround accounts, and cannot stop Branch A’s manager from browsing Branch B’s numbers. If the location can be left blank, misspelled, or edited after the fact, it is a label, not a ledger dimension.
Set up the chart of accounts for multiple locations.
The classic beginner mistake is cloning accounts per branch: "Rent — Main", "Rent — Mall", "Sales — Main", "Sales — Mall". By branch five you have a chart of accounts with four hundred lines, reports that need manual regrouping, and a new account to create every time a location opens. The chart grows sideways forever.
The correct design keeps ONE account per concept — one Rent, one Sales, one Inventory — and lets the branch dimension slice it. Rent for the Mall branch is the Rent account filtered to Mall, not a separate account. Your chart stays readable (forty accounts, not four hundred), new branches cost nothing to add, and every report can pivot: P&L by branch, rent across branches, one branch’s whole trial balance. Software that does true branch accounting handles this natively; if you are stuck with tagging, at least resist the cloned-accounts urge — it is the hardest mistake to undo later.
Worked example one: recording a sale at a branch.
The Mall branch sells 60 units at $12.80 each; the units carry a weighted-average cost of $9.00 at THAT branch. Two entries post, both stamped with the branch: revenue and cash first — debit Cash $768, credit Sales Revenue $768 — then the cost side: debit Cost of Goods Sold $540, credit Inventory $540.
Two details make this branch accounting rather than plain bookkeeping. First, every line carries the Mall identity, so the same entry feeds both the company P&L and the Mall P&L with no extra work. Second — the detail tagging systems miss — the $9.00 cost came from the MALL’s own inventory layer, not a company-wide pool. If Main Street bought the same product cheaper last month, Main Street’s sales show Main Street’s cost. Per-branch margin is only honest when each branch carries its own cost history.
Worked example two: the inter-branch transfer.
This is the entry that breaks spreadsheets and exposes fake branch accounting. Head office sends stock costing $4,000 to the Mall branch. The naive treatment — credit inventory here, debit inventory there, done — quietly assumes the goods teleport. In reality they sit in a truck overnight, and if the month ends while they travel, both branches’ stock counts are correct and the books still would not balance without a home for the goods in motion.
The professional treatment uses an in-transit account as the middle station. On dispatch, the sender credits its Inventory $4,000 and debits Inventory In Transit $4,000. On receipt, the Mall debits its Inventory $4,000 and credits In Transit $4,000. The in-transit balance is a living checklist: anything sitting in it longer than the truck ride is a transfer someone forgot to receive — shrinkage, loss, or a paperwork gap, surfaced automatically at close.
Two rules keep transfers honest. Transfer at COST between branches of one company — marking stock up creates fake internal profit that consolidation must then eliminate (if you do transfer at a markup for franchise-style incentives, the margin must cancel out company-wide). And never let a transfer be a delete-here-add-there edit: it must be a document with a sender, a receiver, a date, and an audit trail, because transfers are where multi-location stock goes missing.
How do you split head-office costs across branches?
Rent on the head office, the accountant’s salary, the software subscription — none of it belongs to one branch, all of it belongs to the business. Leave it unallocated and every branch looks more profitable than it is; dump it on the biggest branch and your best location looks like your worst. Allocation is how per-branch P&Ls tell the truth.
Pick a base that matches the cost’s behaviour: revenue share for general overheads, headcount for HR-ish costs, floor area for premises-like costs. A $900 head-office rent split on a 50/30/20 revenue base posts as one entry: debit Rent Expense $450 to Main, $270 to Mall, $180 to Depot, credit the unallocated rent pool $900. No cash moves — allocation is a lens, not a payment. Write the basis down once and apply it every month; the fastest way to make branch managers distrust their P&L is to change the allocation rule whenever the result looks wrong.
Per-branch P&L, and the consolidated view that foots.
A real per-branch P&L has three properties. Its revenue and direct costs come from branch-stamped entries, not end-of-month estimates. Its COGS comes from the branch’s own cost layers, as in the sale example above. And its share of overheads arrives through the written allocation policy. Read together, the branch P&Ls answer the multi-location owner’s real question — which locations earn their keep — with contribution margin per branch, before allocated overheads, as the cleanest comparison line.
Consolidation is then addition plus one subtlety: anything the branches did with EACH OTHER must cancel. Transfers at cost cancel by construction. Internal markups, internal service fees, inter-branch balances — each needs its elimination, which is why the discipline of transferring at cost exists. The test of the whole system: the sum of every branch P&L, minus eliminations, must equal the company P&L to the cent. If it does not, somewhere a transaction is missing its branch stamp — and a system that allows blank stamps guarantees you will be hunting for it at every close.
The multi-location month-end close, as a checklist.
Closing multi-location books is the single-location close plus four branch-specific gates. Run them in order and the close stays a checklist; skip one and it becomes archaeology.
- In-transit accounts at zero — every dispatched transfer received, or investigated
- Per-branch bank and cash reconciled — each till and account to its own branch
- Branch stock counts tied to branch inventory balances — not to the company total
- Head-office allocations posted on the written basis — same rule as last month
- Sum of branch P&Ls minus eliminations = company P&L, to the cent
- Orphan check: zero transactions with a blank or invalid branch stamp
The five signs your current setup has already broken.
One: you know company profit but honestly cannot say which branch made it. Two: stock "moves" between shops via delete-and-re-add, and counts drift every month. Three: the consolidated spreadsheet takes days and still needs a plug figure. Four: a branch manager can see — or worse, edit — another branch’s numbers. Five: your accountant maintains a shadow spreadsheet because the accounting system’s per-branch view cannot be trusted.
Two or more of these is not a discipline problem to push through with better spreadsheet hygiene. It is the tagging model hitting its ceiling, and the fix is structural: books where the branch is a dimension, not a label.
What to demand from branch accounting software.
Whatever product you evaluate, hold it to six requirements: the branch stamp must be mandatory on every transaction (blankable = tag); inventory must be branch-scoped with each branch carrying its own cost; transfers must be first-class documents with an in-transit state; permissions must scope by branch so managers see only their own site; per-branch P&L must come from the system, not a spreadsheet; and the consolidated statements must foot against the branch statements automatically.
On the market map: QuickBooks and Xero offer the tagging model — workable for two or three light locations, structurally short of the six requirements above. NetSuite and Sage Intacct clear all six at enterprise depth and enterprise price. Full disclosure for the middle: Nonari is the product we build, and true branch accounting is its core design — mandatory branch stamps, branch-scoped inventory cost, first-class transfers with in-transit, branch permissions, live per-branch P&L — at $70/month for up to three branches (a single-location business starts at $29 and upgrades the day shop two opens). For the honest tool-by-tool shootout, read the multi-branch software comparison linked below.