> For the complete documentation index, see [llms.txt](https://help.modelreef.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.modelreef.io/help/building-your-model/naming-branches.md).

# 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:

{% stepper %}
{% step %}

### Create the new branch structure

Set up the new structure before making changes to existing branches.
{% endstep %}

{% step %}

### Move existing branches under it

Re-parent branches into the new structure so you preserve history and variables.
{% endstep %}

{% step %}

### Rename to match the new organisation

Rename branches to match the new organisation once they are in place, avoiding ambiguous intermediate states.
{% endstep %}
{% endstepper %}

***

## 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.

***

## Related articles

* [Logistics, Transport & Fleet](/use-cases/logistics-transport-and-fleet.md)
* [Build an Annual Planning Pack](/how-tos/scenarios-and-planning/build-an-annual-planning-pack.md)
* [Economic Drivers](/help/drivers-variables-and-timing/economic-drivers.md)
* [How to Enter Drivers](/syntax/how-input-fields-work/how-to-enter-drivers.md)