Naming (Branches)
This article covers naming conventions for branches in Model Reef.
Branch names matter because they appear everywhere:
In the branch tree.
In report filters.
In dashboards and charts.
In collaboration and permissions settings.
You will learn:
How to name entity, division, region and project branches.
How to handle multiple levels.
How to keep names stable while the business evolves.
1. What branch names represent
A branch usually corresponds to a real world unit, such as:
A legal entity.
A country or region.
A division or business line.
A store, clinic, venue or site.
A project or initiative.
An eliminations or adjustment layer.
Branch names should therefore match the labels your team already uses for those units.
2. Recommended naming patterns by level
Some patterns that work well in practice:
2.1 Group and entity levels
Group Consolidatedor simplyGroup.Entity - AU Pty Ltd.Entity - UK Ltd.Entity - US Inc.
This makes entity roles obvious and keeps them grouped in the tree.
2.2 Division and region levels
Under an entity:
Division - Retail.Division - Online.Division - Wholesale.Region - ANZ.Region - UK and Europe.
This separates structure type (division vs region) from the descriptive name.
2.3 Store, clinic or venue levels
Under a region or division:
Store - Sydney CBD.Store - Melbourne North.Clinic - Central.Venue - Oxford Street.
Short, descriptive names work best here.
2.4 Project and special branches
Project - Data Centre Upgrade.Project - New Product Launch.Eliminations - Intercompany.Adjustments - Management.
These make their purpose obvious in filters and reports.
3. Keep names aligned with reality
Where possible:
Use the same names as your chart of accounts descriptions, store list or entity registry.
Avoid internal nicknames that only one team uses.
Update branch names when the real world unit is renamed (for example after a rebrand), but avoid renaming purely for cosmetic reasons.
Consistent naming makes it much easier to cross reference between Model Reef, accounting systems and operational reports.
4. Handling codes and IDs
If your organisation uses codes, you can include them in branch names, for example:
Entity - AU Pty Ltd (ENT_AU)Store - Sydney CBD (ST01)
This works well as long as:
Codes are stable.
The human readable part is still present.
You do not rely on codes alone.
Remember, branches are used by all collaborators, not just finance.
5. Renaming and restructuring branches
You can rename branches and move them in the tree without breaking variables:
Variables stay attached to the same branch even if the branch is renamed.
Parent level and consolidated reports automatically use the new names.
Permissions attached to the branch carry over.
When restructuring, it is often better to follow a multi-step approach:
6. Branch naming and permissions
If you use branch level permissions, branch names become part of how you explain access, for example:
"You have Editor access to
Division - Retailand Viewer access toGroup Consolidated.""You can work on
Region - ANZbut notRegion - North America."
Clear naming reduces confusion and avoids misconfigured access.
7. Common branch naming pitfalls
Avoid:
Completely generic names such as
Branch 1,Branch 2.Names that do not match real organisational units.
Very long names that make the tree hard to scan.
Reusing the same name for different branches in different parts of the tree.
If a branch name is ambiguous, anyone reviewing the model has to open it and inspect variables to understand what it is.
Related articles
Last updated