> 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/core-concepts-overview.md).

# Core Concepts Overview

This article gives you a mental model for how Model Reef is structured and how the main pieces fit together.

You will learn about:

* Workspaces and models.
* Branches and how they represent your business.
* Variables and drivers.
* The Data Library.
* Timing and statements.
* Scenarios and comparisons.

Once you understand these concepts, the rest of the documentation will make more sense.

{% stepper %}
{% step %}

### Workspaces and models

#### Workspace

A **workspace** is a container that holds many models. It is mainly about organisation and collaboration, not accounting logic.

You might use workspaces to separate:

* Client groups or legal groups.
* Internal teams.
* Business units.
* Personal sandboxes.

Permissions can be set at model level within a workspace.

#### Model

A **model** is the core computational object in Model Reef. Each model has:

* Its own start date and end date.
* A single base frequency, for example monthly or weekly.
* A single currency.
* Its own branch tree, variables, drivers and Data Library entries.
* Its own dashboards, reports and valuation outputs.

You can think of a model as the equivalent of a complete Excel workbook for one business, but with stricter structure and shared rules.
{% endstep %}

{% step %}

### Branches — how the business is structured

Inside each model you create **branches**. Branches represent logical parts of the business, such as:

* Legal entities.
* Divisions.
* Stores, venues or sites.
* Projects, contracts or funds.
* Countries or regions.

Branches form a tree:

* A root branch for the whole model.
* Parent branches that aggregate.
* Child branches that hold local detail.

Variables live inside branches. When you add a variable to a branch, its P\&L, Balance Sheet and Cashflow impact:

* Shows up in that branch.
* Rolls up into all parent branches.
* Is excluded from unrelated branches.

You can toggle branches on and off to see the impact of including or excluding parts of the business in consolidated views.
{% endstep %}

{% step %}

### Variables — the building blocks of the model

A **variable** is an atomic modelling object. Examples include:

* Revenue - Subscription - UK.
* COGS - Hosting Costs.
* Opex - Marketing - Paid Search.
* Staff - Engineering Salaries.
* Asset - Plant and Equipment.
* Liability - Term Loan.
* Tax Expense.
* Dividends Paid.

Each variable has:

* A **type** that drives financial behaviour (Revenue, COGS, Opex, Staff, Tax, Asset, Liability, Equity, Dividend).
* A **time series** of values over the model horizon.
* **Timing rules** for when it occurs and when cash moves.
* **Category and sub category** for reporting.
* An associated **branch** where it lives.
* Optional **drivers or formulas** that generate its values.

Variables do not contain their own P\&L or Balance Sheet formulas. The engine knows what to do based on the type and timing you assign.
{% endstep %}

{% step %}

### Drivers — reusable assumptions

A **driver** is a reusable time series that variables can reference.

Common driver types include:

* Volumes (units sold, hours, headcount).
* Prices (price per user, rate per hour).
* Growth rates and multipliers.
* Seasonality indices.
* FX rates and macro indices.
* Any other series that you want to reuse across variables.

Drivers live in the **Data Library** and can be used in many places, for example:

* Revenue = Volume driver × Price driver.
* Staff cost = Headcount driver × Salary driver.
* Cost index = Base cost × Inflation driver.

Updating a driver flows automatically through every variable and chart that uses it, in that model.
{% endstep %}

{% step %}

### The Data Library — central assumptions and imports

The **Data Library** is the central store of time series in a model. It holds:

* Imported historical series from PDF, Excel, CSV, Xero, QuickBooks or external APIs.
* Manually created drivers for volumes, prices and growth.
* Machine learning or regression based forecasts.
* Shared assumptions such as wage inflation, FX or discount rates.

When you import data, Model Reef:

* Detects series.
* Adds them to the Data Library.
* Creates variables that reference them.

When you edit a Data Library series, every dependent variable in that model updates.

Each model has its own Data Library. Models do not share Data Library entries by default.
{% endstep %}

{% step %}

### Timing — when things happen in the model

Timing is a first class concept in Model Reef. Every variable has:

* **Occurrence timing** - when the revenue or cost is recognised in P\&L.
* **Cash timing** - when the cash actually moves.
* **Delay or payment terms** - for example 30 days, 60 days, end of next month.
* **Start and end dates** for when the variable is active.
* **Frequency or schedule** - such as monthly, quarterly or specific dates.

The engine then:

* Records the amount in P\&L when it occurs.
* Creates receivables or payables on the Balance Sheet until cash moves.
* Books the cashflow in the period the delay expires or the schedule says to pay.

Getting timing and delays right is essential for any cash focussed use case.
{% endstep %}

{% step %}

### Statements and reports

Model Reef automatically generates four core statements from variables:

* **Profit and Loss** - accrual view of performance.
* **Balance Sheet** - assets, liabilities and equity, including AR, AP, loans and cash.
* **Cashflow Statement** - direct method cash view, split into operating, investing and financing.
* **Cashflow Waterfall** - a combined view that bridges from EBITDA down to free cashflow and financing flows.

In addition you can build:

* **Custom reports** with any mix of lines, charts and KPIs.
* **Board, lender, investor or management packs** reusing the same data.

You do not edit these statements directly. You edit the underlying variables and drivers instead.
{% endstep %}

{% step %}

### Scenarios — different versions of the future

In Model Reef, a **scenario** is implemented as a separate model that you treat as a scenario for comparison.

Typical pattern:

* Start with a **Base Case** model.
* Duplicate it to create **Downside Case** and **Upside Case**.
* Change assumptions independently in each copy.
* Compare outputs across models using shared templates or external rollups.

Because each scenario is a complete model:

* There is no risk of cross scenario contamination.
* You can archive or branch scenarios without breaking the base.
* You can give different people access to different scenarios if needed.
  {% endstep %}

{% step %}

### Putting it together

You can summarise the core concepts like this:

* A **workspace** contains many **models**.
* Each **model** has a **branch tree**, **Data Library**, **variables**, **drivers** and **statements**.
* **Variables** live in **branches** and use **drivers** from the **Data Library**.
* The **timing engine** turns variables into P\&L, Balance Sheet, Cashflow and Waterfall.
* **Scenarios** are separate models that you use for comparison.
* **Dashboards and reports** sit on top and make the outputs easy to read.
  {% endstep %}
  {% endstepper %}

Next, read:

* [Time and Periodicity Basics](/help/getting-started/time-and-periodicity-basics.md) to understand how time is handled.
* [Key Entities - Variables, Drivers, Branches](/help/getting-started/key-entities-variables-drivers-branches.md) for more detail on the three most important building blocks.