> 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-variables.md).

# Naming (Variables)

This article covers **naming conventions for variables** in Model Reef.

Good variable names make it easier to:

* Read and review your model.
* Search and filter variables.
* Use autocomplete reliably in formulas and drivers.
* Collaborate with other users.

You will learn:

* What makes a good variable name.
* Recommended naming patterns.
* How to handle variants, overrides and scenarios.
* Common mistakes to avoid.

{% stepper %}
{% step %}

### What a variable name should convey

A variable name should tell you, at a glance:

* **What** the variable represents.
* **Which part** of the business it relates to.
* **How** it behaves, if relevant (for example count vs rate vs amount).

Examples:

* `Revenue - Subscriptions - UK`
* `COGS - Hardware - Europe`
* `Staff - Engineering - Headcount`
* `Marketing - Paid Search - Spend`
* `Capex - New Store Rollout`

If you can answer "what is this?" and "where is this?" from the name alone, it is probably a good name.
{% endstep %}

{% step %}

### Recommended naming pattern

A simple, robust pattern is:

**\[Category or type] - \[Subject] - \[Qualifier]**

Where:

* Category or type gives the high level context, for example `Revenue`, `COGS`, `Opex`, `Staff`, `Capex`.
* Subject describes the product, activity or cost driver, for example `Subscriptions`, `Hardware`, `Support Team`.
* Qualifier adds a geography, channel, unit type or other useful dimension, for example `UK`, `Online`, `Headcount`.

Examples:

* `Revenue - Subscriptions - Online`
* `Revenue - Services - Enterprise`
* `Opex - Marketing - Paid Social`
* `Staff - Sales - Headcount`
* `Capex - Data Centre - Phase 1`

You do not need all three parts for every variable, but keeping to a consistent pattern pays off when models become large.
{% endstep %}

{% step %}

### Align names with categories and branches

Variable names should be consistent with their:

* **Category and subcategory**.
* **Branch** (entity, division, store, project).

For example, if a variable lives in branch `Store Sydney` and category `Revenue - Retail`, a good name could be:

* `Revenue - Retail - Sydney`
* Or `Revenue - Store Sales - Sydney`

This way, you can often understand the branch and category context directly from the name when scanning lists or using search.
{% endstep %}

{% step %}

### Naming variants and overrides

Sometimes you have multiple variables that are closely related, for example:

* Base cost vs scenario override.
* Original budget vs updated forecast.
* Old product vs new product.

To keep them clear:

* Include a suffix describing the role, for example `Base`, `Override`, `Scenario B`, `Legacy`, `New`.
* Use tags as well as names if there are many similar variables.

Examples:

* `Revenue - Subscriptions - UK - Base`
* `Revenue - Subscriptions - UK - Scenario B`
* `Opex - Marketing - Brand - Legacy`
* `Opex - Marketing - Brand - New Strategy`

Avoid names that differ only by a numeric suffix with no meaning, for example `Revenue 1`, `Revenue 2`, as these become confusing quickly.
{% endstep %}

{% step %}

### Abbreviations and readability

Short names are convenient, but they should still be understandable. Guidelines:

* Use standard abbreviations where they are widely recognised, for example `GP`, `EBITDA`, `FX`, `COGS`.
* Avoid internal shorthand that only one person understands.
* Do not rely on codes alone (for example `ACC_1001`) unless you also include a plain language description in the name.

Remember that variable names appear in:

* Formula autocomplete.
* Drill down views from reports and charts.
* Data Library listings.

Readable names save time every time you or someone else uses the model.
{% endstep %}

{% step %}

### Renaming variables safely

You can rename variables without breaking the model.

Behind the scenes, references are tracked by internal IDs rather than by the display name, so:

* Formulas that reference the variable continue to work after renaming.
* Reports and dashboards that include the variable update to show the new name.
* Data Library entries linked to the variable remain connected.

This means you can safely improve names over time as the model matures.
{% endstep %}

{% step %}

### Common naming mistakes to avoid

Try to avoid:

* Overly generic names, for example `Revenue`, `Cost`, `Staff`, when there are many such items.
* Names that do not match the branch or category, for example `Revenue - UK` inside an Australia only branch.
* Hard coded dates in names, for example `Revenue 2024`, unless the variable really is specific to that period.
* Long sentences as names. Use concise but descriptive labels instead.

If you are unsure, choose clarity. It is easier to shorten a descriptive name later than to decode an ambiguous one during a review.
{% endstep %}
{% endstepper %}

***

## Related articles

* [Loan Book Growth Forecasting](/use-cases/financial-services-lending-and-fintech/loan-book-growth-forecasting.md)
* [Build a Working Capital Model](/how-tos/operations-and-unit-economics/build-a-working-capital-model.md)
* [Categories](/help/building-your-model/categories.md)
* [Formula Editor Layout](/syntax/formula-syntax/formula-editor-layout.md)