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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.modelreef.io/help/getting-started/core-concepts-overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.