> 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/use-cases/saas-and-subscription-businesses/arr-mrr-forecasting.md).

# ARR/MRR Forecasting

This use case describes how to build an ARR and MRR forecasting engine for a SaaS or subscription business inside Model Reef.

The goal is to move away from a static top line assumption such as "revenue grows 30 percent per year" and instead model how monthly recurring revenue emerges from customers, plans, pricing, churn and expansion.

## When to use this pattern

Use this pattern when:

* You run or advise a subscription business and need a reliable MRR and ARR forecast.
* You want to link revenue to customer counts, average revenue per account (ARPA) and churn.
* You need a forecasting structure that can later grow into cohort and retention analysis.

If you already have complex cohort modelling, pair this with **Churn, Retention & Cohort Modelling** for more detail.

## Architecture overview

You will design three layers:

{% stepper %}
{% step %}

### Drivers

* Customer counts by segment or plan.
* New customers per period.
* Average price per customer or per seat.
* Churn and expansion rates.
  {% endstep %}

{% step %}

### Revenue variables

* MRR by product or plan.
* Total MRR and ARR rollups.
* Implementation or set up fees as separate revenue if needed.
  {% endstep %}

{% step %}

### Outputs

* P and L revenue lines.
* MRR and ARR charts and KPI cards.
* Inputs to valuation models where required.
  {% endstep %}
  {% endstepper %}

Everything is built using Model Reef drivers, variables and the three statement engine.

{% stepper %}
{% step %}

### Decide how granular you need to be

First decide whether you will:

* Model revenue at an aggregate level, using a single customer count and ARPA, or
* Model revenue by segment or plan, for example:
  * Self serve vs enterprise.
  * Monthly vs annual contracts.
  * Different product tiers.

Granularity should reflect how you actually make decisions. More detail is only worth it if it changes choices about sales, marketing or product.
{% endstep %}

{% step %}

### Build customer and pricing drivers

In the Data Library, create drivers for:

* Customer or account counts by segment.
* New customers per period.
* Average price per account or per seat.
* Conversion between seats and accounts where relevant.

Examples:

* `Driver - Customers - SME`.
* `Driver - Customers - Enterprise`.
* `Driver - ARPA - SME`.
* `Driver - ARPA - Enterprise`.

You can fill these drivers using:

* Manual assumptions.
* Regression or ML presets based on historical data.
* Simple rules such as steady percentage growth or step changes after funding rounds.
  {% endstep %}

{% step %}

### Create MRR revenue variables

For each revenue stream, create Revenue variables such as:

* `Revenue - MRR - SME`.
* `Revenue - MRR - Enterprise`.
* `Revenue - MRR - Add Ons`.

Define their formulas using your drivers, for example:

* `MRR = Customers × ARPA` per segment.
* `MRR Add Ons = Customers × Attach Rate × Add On Price`.

Make sure these variables are of type **Revenue** so they flow into P\&L, Cashflow and Cash Waterfall correctly.

If you have upfront implementation or services revenue, keep that in separate Revenue variables so that recurring and non recurring parts are clearly visible.
{% endstep %}

{% step %}

### Add churn and expansion behaviour

To make MRR more realistic, incorporate churn and expansion dynamics. At an aggregate level you can model:

* **Gross churn rate** per period.
* **Expansion rate** per period.
* **Net MRR churn** as the combination of the two.

Implementation options:

* Add drivers:
  * `Driver - Gross Churn Rate`.
  * `Driver - Expansion Rate`.
* Use these in formulas that adjust customer or MRR series, for example:
  * Customers next period = Customers current period plus New Customers minus Churned Customers.
  * Expansion MRR = Starting MRR × Expansion Rate.

If you require detailed retention curves, implement them using the separate **Churn, Retention & Cohort Modelling** pattern and feed the resulting MRR series into this structure.
{% endstep %}

{% step %}

### Translate MRR to ARR and revenue recognition

Model Reef works with period based variables. Depending on your periodicity:

* If the model is monthly:
  * MRR is directly the monthly revenue.
  * ARR can be calculated as `MRR × 12` for reporting purposes.
* If the model is annual:
  * Work with ARR directly and derive implied MRR for dashboards if needed.

For annual contracts paid upfront, you may:

* Recognise revenue monthly while cash arrives earlier.
* Use timing settings and delays to separate revenue recognition and cash receipt.

Ensure that the Revenue variables use the correct timing so that P\&L, Cashflow and Cash Waterfall stay consistent.
{% endstep %}

{% step %}

### Build MRR and ARR dashboards

Create a dedicated SaaS dashboard containing:

* MRR chart over time.
* ARR chart or table by year.
* MRR bridge style chart if you want to show:
  * Starting MRR.
  * New MRR.
  * Expansion MRR.
  * Churned MRR.
* KPI cards for:
  * Current MRR.
  * Current ARR.
  * Net MRR churn rate.

These visuals make it easier to talk to investors and internal teams about how growth is actually happening.
{% endstep %}

{% step %}

### Connect MRR to the rest of the model

Finally, ensure that MRR revenue variables are properly integrated with:

* COGS (for example hosting, support and delivery costs that scale with usage).
* Opex (for example sales and marketing spend).
* Staff planning (for example engineering and customer success headcount).

The same drivers that power MRR often inform hiring plans and cost structure, so reuse them where appropriate and keep assumptions centralised in the Data Library.
{% endstep %}
{% endstepper %}

## Check your work

* MRR and ARR outputs reflect your understanding of the business model.
* Driver names and formulas are clear and traceable.
* P\&L revenue lines are consistent with the MRR and ARR charts.
* Cash and timing behaviour for annual contracts matches reality.

## Troubleshooting

<details>

<summary>MRR appears to jump unexpectedly</summary>

Check the driver series for customer counts and ARPA to make sure there are no accidental step changes.

</details>

<details>

<summary>ARR looks too large or too small compared to MRR</summary>

Confirm that you are using consistent units and that ARR is derived correctly as a multiple of MRR.

</details>

<details>

<summary>Investors ask for additional SaaS metrics</summary>

Extend the dashboard to include churn, retention and LTV metrics using the related patterns.

</details>

## Related guides

* [Build a Central Assumption Library](/how-tos/data-workflows-and-automation/build-a-central-assumption-library.md)
* [Build a Consolidated Forecast Model](/how-tos/core-modelling/build-a-consolidated-forecast-model.md)
* [Archiving Models](/help/building-your-model/archiving-models.md)
* [Category Selection](/syntax/variables-syntax/category-selection.md)


---

# 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/use-cases/saas-and-subscription-businesses/arr-mrr-forecasting.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.