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 Consolidated or simply Group.
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:

Create the new branch structure

Set up the new structure before making changes to existing branches.

Move existing branches under it

Re-parent branches into the new structure so you preserve history and variables.

Rename to match the new organisation

Rename branches to match the new organisation once they are in place, avoiding ambiguous intermediate states.

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 - Retail and Viewer access to Group Consolidated."
"You can work on Region - ANZ but not Region - 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.

PreviousNaming (Drivers)NextModel Template Structure

Last updated 6 months ago

Was this helpful?