One Owner, Five Businesses: Running Multi-Company and Multi-Branch on One ERP

The successful Pakistani businessman almost never owns one thing. He starts with a shop, the shop does well, and the money goes into the next thing, a second outlet, then a trading arm to import what the shops sell, then a small factory because why buy from someone else, and somewhere along the way a couple of properties on the side. In his own head it is one empire, run by one man, and he can tell you how all of it is doing over a cup of tea. In his software it is something else entirely: five separate company files, or five separate logins, that have never spoken to each other and never will.

So a man who thinks of his businesses as one thing is forced to account for them as five. Every report is five reports. Every time he wants the real picture of his wealth, someone has to open five files, export five trial balances, and stitch them together in Excel, usually weeks after he asked. And the moment money moves between his own businesses, which it does constantly, the whole thing starts to drift out of balance. This is the multi-company problem, and almost every growing business in Pakistan hits it.

Branch is not the same as company, and both matter

It helps to separate two things that get muddled. A branch is one business operating in more than one place, three outlets of the same retail chain, all selling the same goods under the same ownership. A company is a genuinely separate business, your trading firm and your factory are not the same entity, they buy and sell from each other, they have their own profit, often their own bank accounts and even their own NTN. Most established owners have both at once: several distinct businesses, and some of those businesses spread across several locations.

The wrong tool forces you to pick the wrong shape. Run everything as one big merged company and the branches and businesses blur into a single total where nothing can be told apart. Run everything as separate files and you lose the group picture and any link between them. Neither is what the owner actually wants. What he wants is to see each unit clearly on its own and the whole group together, from the same system, without doing arithmetic by hand.

The branch problem solves itself with a tag

For multiple branches of the same business, the answer is usually simpler than people expect, and it is not a separate company per shop. It is a single set of books where every transaction carries a tag for which branch it belongs to. Tag the sale, tag the expense, tag the stock movement, and suddenly the same pile of transactions can be shown per branch or all together, on demand, with no consolidation step at all because nothing was ever split. This is the same idea we wrote about at length in tracking profit by salesman, branch and project: the data is one, the views are many.

This is why so many “I need separate companies” requests are really “I need a branch dimension.” If the outlets share ownership, share stock, and you just want to know which one earns, you do not want the overhead of separate legal books for each, you want one company and a branch tag. It is switched on in an afternoon and it answers the per-branch question without fragmenting anything.

The real headache: money between your own businesses

Genuinely separate companies are a different animal, and the thing that quietly breaks them is the most ordinary event in a group: one of your businesses pays for, or lends to, another. The factory’s account is short this week, so the trading company covers a supplier payment. The showroom takes goods from the trading arm and will settle later. On paper these are everyday moves. In separate, unconnected books they are a slow poison, because the money leaves one set of books and the matching claim is never properly recorded in the other. Do this twenty times across a year and no single company’s books are trustworthy, and the group total certainly is not.

The proper way to handle this is the way accountants always have: a “due to” and “due from” between the entities, so that whenever one business owes another, both sides record it as a mirror of each other. When the trading company pays for the factory, the trading company shows “factory owes us” and the factory shows “we owe trading”, automatically, the same amount, at the same moment. Each company’s books stay self-balancing, and when you consolidate the group, those internal balances cancel out cleanly instead of double-counting.

What NavoBook actually does here

NavoBook treats this as a built-in capability, not a workaround. You can run several business units inside the system, each with its own self-balancing books, so every unit has a clean P&L and balance sheet on its own. When one unit transacts with another, the inter-company due-to and due-from entries are created automatically on both sides, so the link is never left half-recorded. And because all of it lives in one connected platform, you get both views without re-keying: each business statement on its own, and a consolidated P&L and balance sheet for the whole group with the internal balances eliminated.

It is also off by default. A business that genuinely is one company with one set of books is never burdened with multi-entity machinery it did not ask for; you switch it on only when you actually run more than one business. For the simpler case of one business across several locations, the branch dimension does the job without creating separate entities at all. Either way, you stop choosing between “see each one” and “see the whole”. The full setup is laid out on our main ERP page.

If you run more than one business and you are tired of opening five files to answer one question, talk to us. Tell us how your businesses are structured and how money moves between them, and we will show you the same group on one screen. NavoBook is one plan, PKR 30,000 a month, all 18 modules included. The details are on our pricing page.