> 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/getting-started/key-entities-variables-drivers-branches.md).

# Key Entities (Variables, Drivers, Branches)

This article explains the three core entities that make up almost every model in Model Reef:

* **Variables** - what is happening financially.
* **Drivers** - the assumptions behind those variables.
* **Branches** - where in the business it is happening.

If you understand these three concepts, you can reason about almost any model in the platform.

***

## 1. Variables

A **variable** is an atomic piece of the model that creates movements in the three financial statements and the Cashflow Waterfall.

Examples:

* Revenue - Subscription - UK.
* COGS - Cost of Goods Sold - Retail.
* Opex - Marketing - Paid Search.
* Staff - Sales Team.
* Asset - Machinery Purchase 2025.
* Liability - Bank Loan Tranche A.
* Tax Expense.
* Dividend Payment.

### 1.1 Variable types

Each variable has a **type** that tells Model Reef how it behaves:

* **Revenue** - increases revenue and contributes to gross profit.
* **COGS** - direct costs that reduce gross profit.
* **Opex** - operating expenses below gross profit.
* **Staff** - staff costs with additional payroll logic.
* **Tax** - tax expense and payables.
* **Asset** - assets that depreciate over time.
* **Liability** - loans and other liabilities with interest and repayments.
* **Equity** - capital injections.
* **Dividend** - payments to shareholders that reduce retained earnings.

The type controls how the variable flows into P\&L, Balance Sheet, Cashflow and the Waterfall. You do not wire these flows yourself.

### 1.2 Key fields on a variable

Each variable has a set of fields, including:

* **Branch** - which part of the business it belongs to.
* **Category and sub category** - how it appears in reports.
* **Amount or formula** - what value it has each period.
* **Timing** - start date, end date, frequency and schedule.
* **Delay** - how long between accrual and cash.
* **Units and bounds** - how values are displayed and validated.
* Optional **links to drivers or Data Library series**.

The combination of type plus these settings is enough for Model Reef to compute that variable's full impact on the model.

### 1.3 Relationship to statements

Variables never sit directly on the statements. Instead:

* The engine reads the variable's settings.
* It writes accruals into P\&L.
* It creates receivables, payables, assets and liabilities in the Balance Sheet.
* It calculates cash movements for the Cashflow Statement and Waterfall.

To change the statements you change variables, not lines on the statements themselves.

***

## 2. Drivers

A **driver** is a reusable time series that variables refer to when they need an input.

Think of drivers as the assumption layer of the model. They capture things like:

* Unit volumes.
* Prices.
* Growth rates.
* Wage inflation.
* FX rates.
* Macro indicators.

Drivers live in the **Data Library** and can be used anywhere in the model.

### 2.1 Driver types

Conceptually there are three driver classes:

* **Economic drivers**
  * Prices, FX, inflation, commodity indices.
  * Market growth, discount rates, external benchmarks.
* **Operational drivers**
  * Units sold, hours, headcount, utilisation.
  * Store counts, capacity, bookings.
* **Modifier drivers**
  * Growth percentages.
  * Seasonality multipliers.
  * Scaling factors and scenario overrides.

Drivers themselves do not hit the financial statements. They only affect statements when a variable uses them.

### 2.2 How drivers are used

Drivers are used in formulas and presets such as:

* Revenue = Units driver × Price driver.
* Cost = Units driver × Cost per Unit driver.
* Staff cost = Headcount driver × Salary driver × On cost factor driver.
* Cash buffer target = Revenue × Percentage driver.

When you update a driver:

* Every variable referring to it updates automatically.
* All dependent statements and dashboards change.

This is what makes Model Reef good at "change one assumption, see the impact everywhere" style analysis.

### 2.3 Drivers and the Data Library

All drivers are stored as entries in the Data Library, alongside imported historical series.

For each driver you can see:

* Name and tags.
* Type and category.
* Time series values.
* Which variables reference it.

You can also change frequency, forecasting method or values from the Data Library view and see changes propagate through the model.

***

## 3. Branches

A **branch** is a structural unit inside a model. Branches answer the question "where does this happen in the business?"

Branches are used to represent things like:

* Legal entities.
* Regions or countries.
* Stores, venues or sites.
* Business lines and divisions.
* Projects, contracts and funds.
* Cost centres and departments.

### 3.1 Branch hierarchy

Branches form a tree:

* The **root branch** represents the whole model.
* Each **child branch** sits under a parent branch.
* Branches can have any depth of nesting.

Variables are attached to branches. When a variable lives in a branch:

* Its impact shows in that branch's statements.
* It rolls up into all ancestor branches.
* It is excluded from siblings and other branches.

This is how you get store, region, division and group views from one model.

### 3.2 Enabling and disabling branches

Branches can be toggled on or off in consolidated views.

Typical uses:

* Compare consolidated results with and without a region or project.
* Exclude a branch for a disposal case.
* Temporarily park experimental changes in a branch without including them in the main view.

Disabling a branch removes its contributions from statements and dashboards but does not delete data. You can re enable at any time.

### 3.3 Branches and permissions

In a collaborative setup you can limit who can see or edit branches. Typical patterns include:

* One team per branch (for example region or division).
* Central team with access to the whole model.
* Limited access for external partners to only see relevant branches.

This allows large organisations to keep one model while controlling access appropriately.

***

## 4. How variables, drivers and branches work together

You can summarise the relationship like this:

* **Drivers** capture assumptions.
* **Variables** turn those assumptions into financial movements.
* **Branches** determine where in the business those movements belong.

A simple example:

{% stepper %}
{% step %}

### Driver — Units Sold — UK

Define a Units Sold driver for the UK in the Data Library.
{% endstep %}

{% step %}

### Driver — Price per Unit — UK

Define a Price per Unit driver for the UK in the Data Library.
{% endstep %}

{% step %}

### Variable — Revenue — Product A — UK Branch

Create a Revenue variable for Product A in the UK branch that uses the Units and Price drivers.
{% endstep %}

{% step %}

### Branch — UK holds the revenue variable

Attach the variable to the UK branch so the revenue appears in the UK branch's statements.
{% endstep %}
{% endstepper %}

The result is:

* UK branch shows Product A revenue and margin.
* Group branch shows UK plus other branches.
* Changing the price driver updates both branch and group views instantly.

***

## 5. Practical modelling tips

{% hint style="info" %}
Start with structure and shared assumptions to keep models flexible and maintainable.
{% endhint %}

* Start by sketching your **branch structure** to match how you want to view the business.
* List the **variables** you need for revenue, costs, assets, funding and tax.
* Identify the **drivers** behind these variables (volumes, prices, rates).
* Put shared assumptions in the **Data Library** rather than buried in one variable.
* Use clear naming so that variables and drivers are easy to find and reuse.

With these habits, your models will stay understandable and flexible as they grow.

***

## Where to go next

* [Importing and Data Inputs](/help/importing-and-data-inputs.md) to learn how variables are created from real data.
* [Drivers, Variables and Timing](/help/drivers-variables-and-timing.md) in the Syntax section for field by field detail.
* The [Core Modelling](/how-tos/core-modelling.md) how tos for step by step recipes that use these entities in practice.