I still get a variation of the same confused Slack message from new clients every few months: "we need a new company for our Kenyan subsidiary, right?" Usually the honest answer is no, they need a branch. Getting Branch, Company, and Tenant confused is one of the costliest configuration mistakes I see on Acumatica projects, because unwinding the wrong choice after go-live means moving live transactional history between structures that were never designed to be re-parented casually.
Three different boundaries, solving three different problems
These three concepts sit at completely different layers of the platform, and the fact that all three can look like "a separate business unit" in a sales conversation is exactly what causes the confusion.
- Tenant is the top-level data isolation boundary. Every tenant in an Acumatica instance has its own completely separate dataset, its own set of companies, its own security configuration. Tenants share the same application and database schema, but a query in one tenant can never see rows in another without a deliberate cross-tenant mechanism. This is the boundary you use for genuinely separate customers on the same SaaS instance, or for a hard sandbox-versus-production split within one deployment.
- Company (Company or Company Group) is a legal entity boundary inside a tenant. A company has its own chart of accounts (or shares one via a company group), its own base currency, its own GL. Companies within the same tenant can consolidate financials and, if configured as an inter-company group, post inter-company transactions to each other with proper elimination entries. This is the boundary for actually distinct legal entities: separate registered businesses, separate tax jurisdictions, separate audited financial statements.
- Branch is a subdivision inside a single company, sharing that company's chart of accounts and legal identity, but with its own address, its own numbering sequences, its own restriction group for inventory and warehouses. This is the boundary for internal organizational structure that does not rise to the level of a separate legal entity: a regional office, a warehouse location, a department that needs its own GL sub-ledger view without needing its own balance sheet.
Ask: does this new unit file its own tax return and have its own audited financial statements? If yes, it is a company. Does it need separate data from every other customer on the instance, with zero visibility between them? If yes, that is tenant territory, and usually only relevant to Acumatica partners hosting multiple client instances. Everything else, regional offices, cost centers, warehouse locations, is a branch.
What branch actually controls day to day
Branch shows up constantly in transaction entry because most transactional DACs carry a BranchID field, and branch-level restriction groups control which warehouses, cash accounts, and sometimes which customers or vendors a user can see when working in that branch. A Sales Order posted from the Nairobi branch can be restricted to only see Nairobi's warehouses, while a user with access to multiple branches can switch context and immediately see a different restricted set, all still posting to the same company's chart of accounts.
// Branch-aware BQL is the default, not something you opt into.
// Any PXSelect against a DAC with BranchID automatically filters
// to branches the current user is restricted to, unless you
// explicitly bypass it with PXSelect...NoFilter or similar.
public PXSelect<SOOrder,
Where<SOOrder.branchID, Equal<Current<AccessInfo.branchID>>>> FilteredOrders;
Numbering sequences are commonly assigned per branch too, which is the detail that trips people up most: a client who thinks they need separate companies purely to get separate invoice number ranges per region can usually get that with one company, multiple branches, and a numbering sequence configured to segment by branch instead.
Company groups: when you actually do need separate companies
Real multi-entity groups, a holding company with three legally distinct subsidiaries, belong in separate companies under a company group. Each company keeps its own chart of accounts (or shares a template chart while maintaining independent balances), and the company group configuration is what enables consolidated reporting across them and, critically, inter-company transactions with automatic due-to/due-from elimination entries when one entity's transaction touches another's books.
I have done this migration twice for clients who started with "just add a branch" and later discovered the subsidiary needed its own audited GL. There is no supported one-click promotion from branch to company. It means exporting historical transactions, re-mapping account structures, and in one case, working with the client's auditors to agree on how to represent the cutover in the comparative financial statements. If there is any realistic chance a unit becomes its own legal entity within a year or two, it is worth the harder conversation up front about starting it as a company.
Tenant: mostly a partner and platform concern
Most implementation consultants working inside a single client's instance never touch tenant configuration at all, because one client typically gets one tenant. Where it matters is Acumatica partners running multi-tenant instances to host several unrelated clients on shared infrastructure, or internal setups that keep a sandbox tenant alongside production on the same physical deployment. Cross-tenant BQL access is deliberately restricted; if a GI or integration genuinely needs to read across tenant boundaries, that requires an explicit cross-tenant configuration rather than anything that happens by accident, which is the correct default given what a tenant boundary is supposed to guarantee.
Wrapping up
Tenant, company, and branch look similar in a requirements conversation because all three create some kind of separation, but they solve entirely different problems: tenant isolates unrelated datasets, company represents a distinct legal entity with its own books, and branch subdivides one company's operations without creating a new legal or financial boundary. Ask the audited-financial-statements question early, because getting this wrong is one of the few Acumatica configuration mistakes that is genuinely expensive to reverse after go-live.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.