One tenant, three companies, and the list they all share — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

You have three companies in mind and twenty-odd shops, and the first screen asks you to create a company. This lesson is about the decision behind that screen, because it is the one that is expensive to reverse, and about one thing the organisation tree deliberately does not divide. About eleven minutes.

Step 1 — Apply the test that actually settles company or branch

After this step you can stop arguing about size. The question is not how big the operation is, how far away it is, or whether it has its own manager. The question is filing. If the two operations file one tax return, they are branches of one company. If they file separately, they are two companies, and no amount of convenience changes that. A branch shares the company’s chart of accounts, its default account mapping, its tax defaults and its e-Invoice registration with the revenue board. It can carry its own tax registration number, but it cannot carry its own ledger. A company is a separate legal entity all the way down.

Reference: Organization — A second company, or another branch?

Step 2 — Know which mistake costs you more

After this step you will lean the right way when the answer is genuinely unclear. Making a company where you wanted a branch is annoying and visible: you maintain two charts of accounts, two sets of default account mappings and two e-Invoice registrations for what is really one business, and every movement of stock or money between them has to be keyed on both sides instead of being an internal note. Making a branch where you needed a company is quieter and worse. It surfaces months later, when somebody asks for that entity’s own set of accounts to file from, and there is no separate ledger to produce one from.

Reference: Setting Up a Group: What We Recommend — A second company, or another branch

Step 3 — Know where the boundary the server enforces actually runs

After this step you know which promises about separation you can make. Financial documents are genuinely scoped on the server. When somebody’s permission is targeted at one company or one branch, the document listing query carries that target into its own conditions, and it checks the branch the document was raised at and the branch it is delivered to. So a branch manager’s sales invoice listing really is their branch’s. That is the boundary, and for documents it is a real one, enforced where the data is read rather than in the browser.

Reference: Organization — What the organisation tree does not divide

Step 4 — Know the one list every company in your tenant shares

After this step you will stop looking for a setting that is not there. Customers, suppliers and items are one list for the whole tenant. Not one per company, not one per branch. Somebody scoped to a single shop opens the customer listing and sees every customer the group has, and nothing changes that. This is deliberate, and confirmed as the design. A shopper who buys at one branch and returns the item at another has to be the same customer record, found by both counters, or the return cannot be processed and their loyalty balance splits in two. Scoping the customer master would break the group’s own trade, so the layer that got the scoping is the layer where whose trade it is actually means something.

Reference: Organization — What the organisation tree does not divide

Step 5 — Plan around it, and know the one control that does hold

After this step you can answer the privacy question honestly. If separated customer lists matter to you — a franchise, a joint venture, two brands that must not see each other’s trade — the boundary you need is a separate tenant, not a separate company. Companies and branches will not give it to you and no configuration will. What does hold is taking the data away: the bulk export endpoint checks the permission target properly and refuses, so being able to read a list on screen and being able to download it are genuinely different permissions here. Say that plainly when somebody asks, rather than promising a restriction the screen implies and the server has never applied.

Reference: Teams and Permissions — What BigLedger does not do today

Step 6 — Settle the codes before you create the first record

After this step you have spent twenty minutes to avoid a migration. Branch codes and location codes cannot be changed at all, ever, by anyone. A company code can be replaced by an owner, and even that is a migration in all but name, because document numbers already issued and permission set names already granted carry the old one inside them. So agree the shape of the code first, out loud, with whoever will read it on a report in three years. Something that carries region and sequence reads correctly in a document number column and still sorts sensibly when the twenty-second shop opens. Then create the first branch.

Reference: Setting Up a Group: What We Recommend — The decisions that are expensive to reverse

How the steps fit together

    flowchart TD
  s1["Step 1 — Apply the test that actually settles company or branch"]
  s2["Step 2 — Know which mistake costs you more"]
  s3["Step 3 — Know where the boundary the server enforces actually runs"]
  s4["Step 4 — Know the one list every company in your tenant shares"]
  s5["Step 5 — Plan around it, and know the one control that does hold"]
  s6["Step 6 — Settle the codes before you create the first record"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: A branch is where you traded; a location is where the stock is · Back to the series · Play this as a presentation