# Welcome to the Model Reef Help Center
#### Welcome aboard ๐
This is your home base for learning how to build, automate and scale financial models inside Model Reef.
Whether you're forecasting, valuing, scenario planning or building multi entity consolidations, the Help Centre is designed to get you to the right answer fast.
#### ๐ **Start with Search**
The fastest way to find what you need is to **type your question into the search bar above**.
If you prefer to browse manually, use the sections below to jump into the right space.
***
## ๐ก Use Cases
**Learn what Model Reef can do for businesses like yours.**
Use Cases show complete modelling patterns for industries and teams. Each use case explains:
* The business problem you are solving.
* Which variables, branches and drivers matter most.
* How data flows in from Xero, QuickBooks, PDFs or tickers.
* Which dashboards and reports to use to communicate results.
Go to Use Cases if:
* You want to see "what good looks like" for your sector.
* You are scoping a new model for a client or internal stakeholder.
* You want examples before you touch any syntax or configuration.
[๐ Explore Use Cases](https://help.modelreef.io/use-cases/)
***
## ๐ Help Articles
**Understand how the platform works under the hood.**
Help Articles explain the **core concepts and mechanics** of Model Reef, including:
* Getting started and core modelling ideas.
* Importing and cleaning data from PDFs, Excel, CSV and accounting tools.
* Building branches, variables, drivers and timing logic.
* How financial outputs and valuation rules are generated.
Go to Help Articles if:
* You are new to Model Reef and want the mental model first.
* Something is not behaving how you expect and you want to check the rules.
* You are designing a new template or architecture for your team.
[๐ Browse Help Articles](https://help.modelreef.io/help/)
***
## ๐งฉ Syntax
**See exactly how every field behaves.**
Syntax pages are the **reference manual** for the product. They describe:
* What each screen, input field and toggle does.
* Valid inputs and behaviours for variables, drivers, timing and formulas.
* How scenario, chart and table controls work.
* How the interface pieces fit together.
Go to Syntax if:
* You are looking at a screen and want to know what a specific option means.
* You are building internal training or checklists.
* You need precise behaviour for audits or complex models.
[๐ Open Syntax Reference](https://help.modelreef.io/syntax/)
***
## ๐ How Tos
**Follow step by step recipes to build real models.**
How Tos are **guided workflows** that show you how to:
* Build core models from scratch or from imports.
* Create valuations, scenarios and planning packs.
* Design dashboards and reporting suites for different audiences.
* Automate data workflows across branches and systems.
Each How To assumes the concepts are understood and focuses on **doing the work in Model Reef**.
Go to How Tos if:
* You know the goal, for example "Build a DCF model" or "Build a Budget vs Actuals model".
* You want a checklist style guide with an order of operations.
* You are standardising processes across a team or client base.
[๐ View How To Guides](https://help.modelreef.io/how-tos/)
***
## Not sure where to start?
{% stepper %}
{% step %}
### New to the product
Start with [**Help Articles โ Getting Started**.](https://help.modelreef.io/help/)
{% endstep %}
{% step %}
### Know the product but not the pattern
Check [**Use Cases**](https://help.modelreef.io/use-cases/) for something close to your situation.
{% endstep %}
{% step %}
### Stuck on a specific field or screen
Jump into [**Syntax**](https://help.modelreef.io/syntax/) to find precise behaviour and definitions.
{% endstep %}
{% step %}
### Need a recipe you can follow today
Go straight to [**How Tos**](https://help.modelreef.io/how-tos/) for step-by-step guides.
{% endstep %}
{% endstepper %}
You can always come back to this home page from the navigation sidebar to switch spaces quickly.
# ๐งฎ Accounting Firms & Advisors
# Multi-Entity Consolidation (QBO/Xero)
This use case shows how an accounting firm can use Model Reef alongside Xero and QuickBooks to deliver multi-entity consolidation for client groups.
Instead of maintaining brittle Excel workbooks, you will:
* Build one live actuals model per legal entity.
* Build a separate consolidation model that ingests those entity outputs.
* Standardise mapping so you can repeat the pattern across many client groups.
Model Reef currently connects each model to a single ledger file. Multi-entity consolidation is therefore implemented with multiple models and one consolidation model, not a single model connected to many ledgers.
## When to use this pattern
Use this approach when:
* A client has multiple entities, often with separate Xero or QuickBooks files.
* You need consistent, repeatable group level P\&L, Balance Sheet and Cashflow.
* You want to move away from fragile spreadsheet consolidations.
* You may need eliminations or group reclassifications on top of legal entity results.
If you only have one ledger and simply need divisional reporting, see the **Multi Division Model** pattern instead.
## Architecture overview
{% stepper %}
{% step %}
### Entity models
* One Model Reef model per ledger (per Xero or QuickBooks file).
* Each connected to its ledger using the live actuals integration.
* Responsibility: accurate legal entity actuals and, optionally, local forecasts.
{% endstep %}
{% step %}
### Consolidation model
* One Model Reef model with branches for each entity and an optional Eliminations branch.
* Responsibility: group P\&L, Balance Sheet, Cashflow and Cash Waterfall.
{% endstep %}
{% step %}
### Reporting views
* Dashboards and reports in the consolidation model that deliver group and entity breakdowns to the client.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Model Reef connects each model to a single ledger file. Multi-entity consolidation is achieved by creating multiple entity models plus a consolidation model that ingests their outputs.
{% endhint %}
{% stepper %}
{% step %}
### Step 1: Standardise chart-of-accounts mapping
Before building anything, choose a standard mapping scheme you will apply across all entities in the group.
* Define a firm level reporting chart:
* Revenue categories.
* COGS categories.
* Staff categories.
* Opex buckets.
* Asset and liability groupings.
* For each entity:
* Decide how its local COA maps into this standard structure.
* Document any exceptions or entity specific lines.
Store these decisions in internal working papers or in GitBook so future staff can follow the same mapping.
{% endstep %}
{% step %}
### Step 2: Build one live actuals model per entity
For each ledger (Xero or QuickBooks):
* Create a model named for the entity, for example:
* `ClientGroup - Entity A - Live Actuals`
* `ClientGroup - Entity B - Live Actuals`
* Connect the model to the Xero or QuickBooks file.
* Import and map the Chart of Accounts using your firm level structure.
* Import historical actuals (for example the last 2 to 3 years).
* Optionally add simple forward assumptions so each entity has its own forecast.
Check that:
* P\&L and Balance Sheet for each entity match the ledger within materiality.
* Categories align with your standard chart.
These models are your single source of truth for legal entity numbers.
For details, see **Build a Live Actuals Model Using Xero**.
{% endstep %}
{% step %}
### Step 3: Design the consolidation model structure
Create a dedicated consolidation model, for example:
* `ClientGroup - Consolidation Model`
In this model:
* Create a branch structure such as:
* `Group` (root consolidated branch)
* `Entity A`
* `Entity B`
* `Entity C` (if applicable)
* `Eliminations` (optional, for inter-entity adjustments)
* Set currency and periodicity to match the entity models.
This model will not connect directly to ledgers. It will ingest outputs from the entity models.
{% endstep %}
{% step %}
### Step 4: Export entity level results
From each entity model:
* Export the key series you want to consolidate, for example:
* P\&L by period (Revenue, COGS, Opex, Staff, EBITDA)
* Balance Sheet by period (Assets, Liabilities, Equity)
* Optional additional metrics such as headcount or units
* Use CSV exports with clear naming, for example:
* `entity-a pnl monthly.csv`
* `entity-a balance-sheet monthly.csv`
Ensure export settings are consistent across entities:
* Same period range.
* Same periodicity (for example monthly).
* Same units (for example whole currency or thousands).
{% endstep %}
{% step %}
### Step 5: Import entity results into the consolidation model
In the consolidation model:
* Use CSV import to bring in each entity file.
* For each imported series:
* Create Data Library entries named, for example:
* `Entity A - Revenue`, `Entity A - EBITDA`, `Entity A - Assets`
* Tag entries with the entity name and `SRC ENTITY MODEL`.
* Map each series to variables under the relevant branch:
* Variables in `Entity A` branch reference `Entity A` series.
* Variables in `Entity B` branch reference `Entity B` series, and so on.
You now have branch level variables that mirror each entity's statements inside the consolidation model.
For help on combining sources, see **Combine Multiple External Data Sources**.
{% endstep %}
{% step %}
### Step 6: Add group adjustments and eliminations
Most groups require adjustments on top of legal entity figures, such as:
* Intercompany revenue and cost eliminations.
* Intercompany loans and balances.
* Group reclassifications and management adjustments.
Implement these by:
* Creating an `Eliminations` branch with variables representing:
* Negative revenue and expense lines to eliminate internal trading.
* Adjustments to assets and liabilities where balances cancel out.
* Or, where preferred, adding separate adjustment variables inside the `Group` branch.
Because branches roll up to `Group`, the consolidated view will automatically reflect entity results plus eliminations and adjustments.
Document each adjustment in variable notes so you can explain them to the client or auditors.
{% endstep %}
{% step %}
### Step 7: Layer consolidated forecasts
Once actuals are in place, you can add group level forecasts in the consolidation model by:
* Projecting entity level series based on growth or margin assumptions.
* Adding group wide drivers (for example group marketing, corporate overhead, group capex).
* Modelling group level debt and equity transactions in the `Group` or a dedicated `Funding` branch.
Alternatively, maintain detailed forecasts inside each entity model and import those projections into the consolidation model via CSV, following the same pattern as actuals.
Choose the approach that matches your firm's workflow and the level of detail clients expect.
{% endstep %}
{% step %}
### Step 8: Build consolidated reports and dashboards
In the consolidation model:
* Use system reports for:
* Group P\&L
* Group Balance Sheet
* Group Cashflow Statement
* Group Cash Waterfall
* Build custom reports or dashboards to show:
* Group totals next to entity breakdowns
* Group versus Entity A, Entity B etc.
* Group level EBITDA, cash and debt trends over time
These become the deliverables you provide to client management or their external stakeholders.
{% endstep %}
{% endstepper %}
## Operating the monthly or quarterly workflow
{% stepper %}
{% step %}
Refresh actuals in each entity model from Xero or QuickBooks.
{% endstep %}
{% step %}
Export updated entity series.
{% endstep %}
{% step %}
Import them into the consolidation model, replacing or extending prior periods.
{% endstep %}
{% step %}
Re-run the consolidated statements and review:
* Group performance.
* Group cash and debt.
* Any covenant style ratios if applicable.
{% endstep %}
{% endstepper %}
Over time you can industrialise this process across many client groups by reusing templates and mapping conventions.
## Check your work
* Entity models reconcile to their source ledgers.
* Consolidation model shows group results that match your manual or prior consolidation.
* Eliminations behave as expected, with intercompany flows cancelling out.
* The workflow is repeatable each period without ad hoc fixes.
## Troubleshooting
Entity exports use inconsistent structures
Standardise the export template you use in each entity model so the consolidation imports remain stable.
Eliminations are hard to trace
Use clear variable names and notes in the `Eliminations` branch, and, if necessary, create a simple eliminations report to show the adjustments explicitly.
Updating many entities becomes time consuming
Focus on automating naming conventions and export/import processes, and consider limiting detailed consolidation to the most material entities.
## Related guides
* [Build Cross Branch Drivers & Dependencies](/how-tos/data-workflows-and-automation/build-cross-branch-drivers-and-dependencies)
* [Build Scenario Aware Data Overrides](/how-tos/data-workflows-and-automation/build-scenario-aware-data-overrides)
* [Actuals Import](/help/xero-integration/actuals-import)
* [Allowed Operators](/syntax/formula-syntax/allowed-operators)
# Client Forecasting Packs
This use case shows how an accounting firm or advisor can turn Model Reef into a forecasting product that can be delivered reliably across many clients.
Instead of building a bespoke spreadsheet for every engagement, you will:
* Create one or more standard forecasting templates.
* Attach each client to the relevant template via imports or live ledger connections.
* Produce a repeatable forecasting pack that you can update each period.
## When to use this pattern
Use this pattern when:
* Clients ask for ongoing forecasting support, not just one off models.
* You want a consistent structure that team members can work with across clients.
* You need to scale advisory services without scaling spreadsheet risk.
This pattern works for small businesses, scale ups and more complex entities, as long as they can fit into a common structural template with some customisation.
## Architecture overview
The pattern has three layers:
* Template models
* One or more pre built 3 statement models designed for common client types (for example SaaS, retail, simple services).
* Contain branches, variables, drivers and reporting layouts.
* Client specific models
* Copies of templates that are connected to client data via PDF, Excel, Xero or QuickBooks imports.
* Contain actuals plus client specific drivers and assumptions.
* Forecasting packs
* Dashboards and reports exported from client models for monthly or quarterly review.
{% stepper %}
{% step %}
### Design your firm level forecasting templates
Start by building one or more template models that reflect common client archetypes, for example:
* `Template - Simple Service Business`
* `Template - Product and Services Mix`
* `Template - SaaS`
* `Template - Retail Multi Site`
Each template should include:
* A clean branch structure (for example Group plus one or more divisions).
* Variable sets for revenue, COGS, Opex, staff, tax, assets and liabilities.
* A central assumption library for inflation, FX, tax and global drivers.
* Core outputs: P\&L, Balance Sheet, Cashflow, Cash Waterfall and a small set of dashboards.
Aim for templates that cover 80 percent of typical client needs, with the remaining 20 percent handled by client specific tailoring.
{% endstep %}
{% step %}
### Onboard a client by cloning the appropriate template
For each new client:
* Pick the closest matching template.
* Clone it to create a client specific model, for example:
* `Client - ABC Plumbing - Forecast Model`
* Set the model currency and fiscal year settings to match the client.
You now have a starting point that already contains full 3 statement logic and reporting.
{% endstep %}
{% step %}
### Bring in client history via ledger or PDF/Excel
Populate the client model with real historical data using:
* **Xero or QuickBooks integration** where the client uses those systems.
* **PDF or Excel import** where management accounts are available as files.
* **CSV import** for specific drivers or operational metrics.
During import:
* Map the client Chart of Accounts into your firm level categories.
* Check that historical P\&L and Balance Sheet match client reports.
Once this is done, the template becomes a client specific model with the right history.
{% endstep %}
{% step %}
### Configure client specific drivers and assumptions
Next, adjust the template assumptions to reflect the client reality:
* Revenue:
* Define units, prices and growth paths per branch or product.
* COGS and Opex:
* Link cost drivers to revenue where appropriate.
* Use central assumption library entries for inflation or general escalation.
* Staff:
* Input current headcount and planned hiring.
* Capex and funding:
* Model any planned asset purchases, debt or equity events.
Keep these drivers as simple as possible while still reflecting the main economics of the client business.
{% endstep %}
{% step %}
### Build the client forecasting pack outputs
Within the client model, build or reuse a forecasting pack layout, for example:
* An executive dashboard showing revenue, EBITDA, cash and runway.
* A summary P\&L and Cash Waterfall.
* A simple valuation summary if appropriate for the engagement.
* Scenario views where relevant (for example Base and Downside models derived from the client model).
These outputs will be exported or presented directly to the client.
For more detail on reporting outputs, see:
* **Build an Executive Dashboard**
* **Build a Board Reporting Pack**
{% endstep %}
{% step %}
### Establish an update cadence
Turn the client model into an ongoing service by:
* Agreeing a review frequency, for example monthly or quarterly.
* At each cycle:
* Refresh actuals from Xero/QuickBooks or updated files.
* Update key assumptions if new information has emerged.
* Regenerate dashboards, reports and any bundled valuations.
* Present the updated forecasting pack in a meeting or written update.
This process lets you maintain a living forecast without rebuilding the model.
{% endstep %}
{% step %}
### Standardise across clients
To scale this offering across many clients:
* Use consistent naming and structure across template models.
* Maintain a firm level assumption playbook that can be quickly customised per client.
* Build standard checklists for onboarding, update and review.
You can also use your GitBook documentation as an internal manual for staff delivering forecasting packs.
{% endstep %}
{% endstepper %}
## Check your work
* Templates are clean, documented and easy to adapt.
* Client models reconcile to their source accounts for historical periods.
* Forecasts are driven by simple but realistic assumptions.
* Packs present the same core metrics across clients, with room for client specific detail.
## Troubleshooting
Templates become overcomplicated
Periodically refactor templates to keep them lean. Move unusual features into client specific layers rather than bloating the shared template.
Clients provide data in inconsistent formats
Use the PDF and Excel import tools, along with clear internal procedures, to normalise data as it enters Model Reef.
Too many client variants are hard to manage
Focus on a small number of robust templates and standardise around them, even if this means some clients fit less perfectly.
## Related guides
* [Build a Board Reporting Pack](/how-tos/dashboards-and-reporting/build-a-board-reporting-pack)
* [Build a Bottom Up Forecast](/how-tos/core-modelling/build-a-bottom-up-forecast)
* [Actuals Import](/help/xero-integration/actuals-import)
* [Auto-Validation Rules](/syntax/how-input-fields-work/auto-validation-rules)
# Board/Investor Reporting for Clients
This use case shows how an accounting firm or advisor can use Model Reef to produce recurring board and investor reporting for many clients, using a repeatable structure and shared templates rather than ad hoc spreadsheets.
The idea is to let each client keep a live planning model inside Model Reef, and use that model as the engine for every board or investor pack.
## When to use this pattern
Use this pattern when:
* Your firm helps clients with regular board packs or investor updates.
* You want consistency in what you present across clients, while allowing for customisation.
* You would like to reduce manual work building decks from scratch each time.
This pattern works well when combined with the **Client Forecasting Packs** pattern.
## Architecture overview
{% stepper %}
{% step %}
### Client models
Each client has a Model Reef model that contains historical actuals and forward forecasts.
{% endstep %}
{% step %}
### Board pack templates
You maintain a standard structure for board reporting that can be reused across clients.
{% endstep %}
{% step %}
### Investor pack templates
Where appropriate, maintain a separate structure tailored to investors.
{% endstep %}
{% step %}
### Update workflow
At each cycle, refresh the model and regenerate charts, tables and narratives.
{% endstep %}
{% endstepper %}
## Step 1: Define standard pack structures
Agree a set of standard sections for:
* Board packs, for example:
* Executive summary.
* Performance vs plan.
* Cash and runway.
* Major initiatives and capex.
* Risk and downside view.
* Decisions required.
* Investor packs, for example:
* Growth and unit metrics.
* Margins and unit economics.
* Cash runway and funding.
* High level valuation view where appropriate.
Document these structures and use them as a template when designing charts and reports in Model Reef.
## Step 2: Build core dashboards and reports for each client model
Within each client model, create:
* One or more dashboards that reflect the agreed pack structure.
* Custom reports for P\&L, Balance Sheet, Cashflow and Cash Waterfall views that match board or investor preferences.
* Optional scenario models (separate models) where downside or alternative strategies need to be discussed.
Use the same layout and naming patterns across clients so your team can navigate quickly.
For implementation details, see:
* **Build a Board Reporting Pack**
* **Build an Investor Update Pack**
## Step 3: Set up Budget vs Actuals views
For each client:
{% stepper %}
{% step %}
Maintain a Budget or Plan model that represents approved expectations.
{% endstep %}
{% step %}
Maintain a Live Actuals or Latest Forecast model.
{% endstep %}
{% step %}
Use exports from both models to build Budget vs Actuals comparisons, focusing on:
* Revenue and margin.
* EBITDA or operating cashflow.
* Cash and debt.
{% endstep %}
{% step %}
Present these comparisons in clear tables and charts.
Remember that scenarios are separate models, so treat Budget, Actuals and Forecast as distinct but related models in your process.
{% endstep %}
{% endstepper %}
## Step 4: Establish a quarterly or monthly reporting cadence
For each reporting cycle:
{% stepper %}
{% step %}
Refresh actuals in the Live Actuals model (for example using Xero or QuickBooks).
{% endstep %}
{% step %}
Update forward assumptions in the planning model if new information has emerged.
{% endstep %}
{% step %}
Regenerate all relevant charts and reports inside Model Reef.
{% endstep %}
{% step %}
Export charts and tables or capture screenshots into your preferred slide or document tool.
{% endstep %}
{% step %}
Add narrative commentary tailored to the client and audience.
Try to reuse the same report set each cycle to build familiarity with the structure.
{% endstep %}
{% endstepper %}
## Step 5: Manage stakeholder specific variations
Boards and investors sometimes require different levels of detail or emphasis.
To handle this efficiently:
* Use shared base outputs (for example the same P\&L and cash views) for both audiences.
* Create separate dashboards or report configurations for board and investor variants, modifying:
* Level of operational detail.
* Inclusion of valuation information.
* Depth of scenario discussion.
This avoids maintaining completely separate models for different audiences.
## Step 6: Standardise internally across the firm
To deliver this service at scale:
* Teach staff to navigate Model Reef models using common conventions.
* Maintain a library of favourite charts and report configurations that can be copied between client models.
* Use your GitBook site to document the standard board and investor pack structures, with references to the underlying guides.
Over time you can refine these standards as you learn what works best with your client base.
## Check your work
* Each client that uses this service has a clean, up to date Model Reef model.
* Board and investor packs are grounded in the same numbers used for internal planning.
* The process for each cycle is clear, repeatable and time bounded.
* Your team can move between clients without having to relearn entirely new structures.
## Troubleshooting
Inconsistent pack formats across clients
Re-align them to your standard structures and gradually migrate legacy formats as you renew engagements.
Numbers in packs do not match other reports
Ensure the Model Reef model you use for packs is the same one used for management reporting, or clearly explain any intentional differences.
Preparing packs still feels labour intensive
Identify manual steps that can be removed or templated, and ensure you are fully reusing Model Reef charts and tables instead of rebuilding them externally.
## Related guides
* [Build a Financial Statements Reporting Suite](/how-tos/dashboards-and-reporting/build-a-financial-statements-reporting-suite)
* [Build an Investor Update Pack](/how-tos/dashboards-and-reporting/build-an-investor-update-pack)
* [Aggregate Categories](/help/building-your-model/aggregate-categories)
* [Autocomplete Behaviour](/syntax/formula-syntax/autocomplete-behaviour)
# 3-Statement Model Setup for Advisory
This use case describes how an accounting or advisory firm can standardise the way it sets up three statement models for clients in Model Reef.
The aim is to have a repeatable pattern that team members can follow each time a client engagement requires a planning or advisory model.
## When to use this pattern
Use this pattern when:
* You want all advisory models to share a common backbone.
* You want to minimise the time it takes to onboard a new client onto a 3 statement model.
* You expect colleagues to move between models and quickly understand the structure.
This pattern is also a foundation for other use cases such as forecasting packs, board reporting and valuations.
## Architecture overview
A standard advisory model should include:
* A clear branch structure, even if you start with a single entity.
* Complete variable sets for revenue, COGS, Opex, staff, tax, assets, liabilities and equity.
* A central assumption library for global drivers.
* Clean three statement outputs and at least one summary dashboard.
You can then adapt this base to different client types by modifying branches and drivers.
{% stepper %}
{% step %}
### Define your firm standard layout
Before building anything, agree a firm standard for:
* P\&L structure:
* Revenue groupings.
* Cost of sales.
* Opex buckets.
* Balance Sheet layout:
* Current vs non current assets.
* Current vs non current liabilities.
* Equity and retained earnings.
* Cashflow layout:
* Operating, investing and financing classifications.
* Cash Waterfall presentation for advisory discussions.
Document this standard and stick to it across models.
{% endstep %}
{% step %}
### Build a clean base template model
Create a template model called, for example:
* `Template - Advisory 3 Statement Base`.
In this model:
* Create a single branch, for example `Entity`, under the root.
* Build variable skeletons for:
* Revenue categories (for example core products or services).
* COGS or direct cost lines.
* Opex lines (for example marketing, rent, professional fees).
* Staff (separate variables for major roles or teams).
* Tax, assets, liabilities and equity as required.
* Set up a small central assumption library containing:
* Inflation or escalation rates.
* Wage growth.
* FX if relevant.
* Tax rate.
This template does not need client data yet. It is your starting frame.
{% endstep %}
{% step %}
### Configure three statement outputs
Check that the template produces valid financial statements even with placeholder numbers:
* P\&L shows all planned categories in the desired order.
* Balance Sheet balances and shows cash derived from the Cashflow Statement.
* Cashflow Statement and Cash Waterfall behave as expected for simple test values.
Fix any classification or mapping issues at this template stage so they do not repeat across clients.
For reference, see Financial Statement Rules and Cash Waterfall Model related guides.
{% endstep %}
{% step %}
### Add a basic advisory dashboard
In the template, create a simple advisory dashboard with:
* Revenue and EBITDA over time.
* Cash balance and net debt over time.
* A few KPIs such as revenue growth and EBITDA margin (even if populated with placeholder data).
This layout will be cloned with the model and adapted per client.
{% endstep %}
{% step %}
### Turn the template into client specific models
When starting a new advisory engagement:
* Clone the template and name it for the client, for example:
* `Client - XYZ - Advisory Model`.
* Adjust currency, fiscal year start and period range as needed.
* Import client historical data using:
* Xero or QuickBooks integration where available, or
* PDF or Excel import where the client provides accounts that way.
* Replace placeholder variables with client specific series and drivers.
Because the structure is already set, most of the work is mapping and assumption refinement rather than building from scratch.
{% endstep %}
{% step %}
### Use the same pattern as you add branches
If the client has multiple divisions or entities:
* Add branches following your standard pattern, for example:
* `Group`.
* `Retail`.
* `Wholesale`.
* `Online`.
* Clone relevant variable sets into each branch.
* Maintain the same category structure so consolidated outputs stay standard.
The underlying three statement logic does not change as you add complexity.
{% endstep %}
{% step %}
### Keep the template up to date
As you learn from client work:
* Improve the template model with better variable design or dashboards.
* Add new assumption types to the central library where you see repeating patterns.
* Avoid making one off changes in client models that would be better incorporated into the standard template.
Over time, the template becomes a high quality internal asset that makes new engagements faster and safer to deliver.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Check your work
* The template model is clean, documented and free of client specific quirks.
* Client models derived from it share the same general layout and naming conventions.
* Three statement outputs behave correctly for all clients that use the pattern.
* Team members can move between models without long onboarding.
{% endhint %}
## Troubleshooting
Templates drift across different teams
Assign an internal owner for the advisory template and route changes through them.
Some clients require very different structures
Create separate templates for materially different patterns (for example SaaS vs project finance) while keeping the core three statement logic consistent.
Legacy models differ from the standard
When practical, migrate legacy models onto the new template pattern at the next major engagement milestone.
## Related guides
* [Build a Budget vs Actuals Model](/how-tos/scenarios-and-planning/build-a-budget-vs-actuals-model)
* [Build a Capex & Depreciation Model](/how-tos/operations-and-unit-economics/build-a-capex-and-depreciation-model)
* [Cashflow Statement Overview](/help/financial-outputs-and-valuation/cashflow-statement-overview)
* [Branch Assignment](/syntax/variables-syntax/branch-assignment)
# CFO-for-Hire Monthly Close Package
This use case describes how an outsourced CFO or advisory team can use Model Reef to deliver a monthly close and reporting package to clients.
The idea is to turn what is often an ad hoc combination of spreadsheets and slides into a repeatable, model driven workflow that covers:
* Month end close and reconciled actuals.
* Updated forecasts and cash projections.
* Board or management level reporting pack.
## When to use this pattern
Use this pattern when:
* You provide CFO or finance leadership services to clients on a retainer basis.
* You are responsible for monthly reporting, cash visibility and forward planning.
* You want a consistent way to deliver this service across multiple clients.
This builds on the **Live Actuals** and **Client Forecasting Pack** patterns.
## Architecture overview
For each CFO-for-hire client you will maintain:
* **Live Actuals model**
* Connected to the clients ledger (for example Xero or QuickBooks).
* Responsibility: accurate, refreshed historical results.
* **Planning model**
* Cloned from a standard advisory template.
* Responsibility: forward forecast, scenarios and valuation where relevant.
* **Reporting pack**
* Dashboards and reports exported from the planning model (and, where needed, live actuals).
* Responsibility: monthly management or board reporting.
You may choose to merge live actuals and planning into a single model once the structure is stable, or keep them separate for clarity.
{% stepper %}
{% step %}
### Step 1: Set up the live actuals backbone
Start by creating a live actuals model as described in **Build a Live Actuals Model Using Xero**:
* Connect to the clients ledger.
* Map the Chart of Accounts into your standard categories.
* Import at least 12 to 24 months of historical data.
* Check that P\&L and Balance Sheet reconcile to the ledger within materiality.
This model gives you a reliable actuals base for monthly reporting.
{% endstep %}
{% step %}
### Step 2: Create the planning model
Next, create a planning model either by:
* Cloning your **3-Statement Advisory Template**, or
* Cloning the live actuals model and simplifying as needed.
In the planning model:
* Bring in historicals via import from the live actuals model, PDF or CSV if necessary.
* Build drivers for revenue, margin, Opex, staff, capex and funding.
* Configure the valuation engine if your engagement includes valuation work.
This model will host the forward looking view that underpins your monthly advice.
{% endstep %}
{% step %}
### Step 3: Define the monthly close workflow
For each month end, your workflow should include:
* **Ledger close**
* Client closes the books in Xero or QuickBooks.
* **Actuals refresh**
* Update the live actuals model from the ledger.
* **Forecast refresh**
* Update key drivers in the planning model based on latest information.
* Optionally adjust scenarios (Base, Downside, Upside).
* **Pack preparation**
* Generate P\&L, Cashflow, Cash Waterfall and key dashboards.
* Extract or screenshot charts for use in documents or slides.
* **Review session**
* Walk the client through results, drivers and updated outlook.
Document this cadence with the client so expectations are clear.
{% endstep %}
{% step %}
### Step 4: Design a standard monthly reporting pack
For each client, design a reporting pack structure that can be reused every month, for example:
* Executive summary.
* P\&L vs last month and vs plan.
* Cash position, runway and funding outlook.
* Key KPIs and operational metrics.
* Variances and discussion points.
* Actions and decisions.
Most of the quantitative content will come straight out of Model Reef:
* P\&L and Cashflow from system reports.
* Cash Waterfall for explanation of cash movements.
* Dashboards for KPI charts.
Use the same structure each month so clients can quickly orient themselves.
{% endstep %}
{% step %}
### Step 5: Integrate scenario and downside views
As CFO-for-hire, you are often expected to provide forward looking risk perspectives.
Implement this by:
* Creating separate scenario models for Base, Downside and, if helpful, Upside.
* At each month end, updating scenarios based on the latest actuals and drivers.
* Including a short section in the pack that compares Base vs Downside on:
* EBITDA.
* Cash and runway.
* Debt and covenants where relevant.
* Highlighting triggers that could move the business from Base toward Downside.
You do not need to show full scenario model detail in the pack; focus on decision relevant summary views.
{% endstep %}
{% step %}
### Step 6: Handle multi entity or group clients
If the client operates multiple entities:
* Maintain one live actuals model per entity as described in the consolidation use case.
* Use a consolidation model to create group level reporting.
* Anchor the CFO-for-hire pack on group metrics, with entity detail in appendices where useful.
Link back to your firm standard mapping and consolidation patterns so you do not reinvent the structure per client.
{% endstep %}
{% step %}
### Step 7: Systematise across your client base
To scale the CFO-for-hire service:
* Use the same advisory template for planning models where possible.
* Standardise section headings and chart layouts across client packs.
* Train team members on a shared checklist for the monthly close and reporting cycle.
* Maintain documentation in GitBook so that new staff can quickly understand the workflow.
Over time this turns the service into a well defined product rather than a purely bespoke engagement.
{% endstep %}
{% endstepper %}
## Check your work
* Live actuals models remain accurate and in sync with ledgers.
* Planning models are clear, documented and use consistent drivers.
* Monthly packs are delivered on time with minimal manual rework.
* Clients can see a clear link between reported results and the forward view.
## Troubleshooting
Closing process is delayed by ledger issues
Agree responsibilities and timelines with the client so that ledger close happens early enough for you to complete your work.
Clients request new metrics each month
Capture requests, but funnel them through a standardised process for updating templates, rather than fragmenting the model.
Too many bespoke model structures emerge
Periodically rationalise client models back towards your standard advisory pattern, especially when renewing or expanding the engagement.
## Related guides
* [Build a Capital Raise Model](/how-tos/investment-and-transactions/build-a-capital-raise-model)
* [Build a Capital Structure Model](/how-tos/investment-and-transactions/build-a-capital-structure-model)
* [Amortisation](/help/financial-outputs-and-valuation/amortisation)
* [Branch Selector](/syntax/understanding-the-interface/branch-selector)
# ๐ป SaaS & Subscription Businesses
# 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
MRR appears to jump unexpectedly
Check the driver series for customer counts and ARPA to make sure there are no accidental step changes.
ARR looks too large or too small compared to MRR
Confirm that you are using consistent units and that ARR is derived correctly as a multiple of MRR.
Investors ask for additional SaaS metrics
Extend the dashboard to include churn, retention and LTV metrics using the related patterns.
## Related guides
* [Build a Central Assumption Library](/how-tos/data-workflows-and-automation/build-a-central-assumption-library)
* [Build a Consolidated Forecast Model](/how-tos/core-modelling/build-a-consolidated-forecast-model)
* [Archiving Models](/help/building-your-model/archiving-models)
* [Category Selection](/syntax/variables-syntax/category-selection)
# Churn, Retention & Cohort Modelling
This use case explains how to represent churn, retention and revenue cohorts inside a Model Reef SaaS model. It extends basic ARR and MRR forecasting by making the dynamics of customer behaviour explicit.
You will use drivers and variables to represent cohorts, retention curves and expansion behaviour without relying on spreadsheet style cell references.
## When to use this pattern
Use this pattern when:
* Aggregate churn assumptions are no longer sufficient.
* You want to understand cohorts by signup month, year, product or channel.
* You care about how expansion and contraction differ across cohorts.
* Investors ask for metrics like gross retention, net retention and cohort based LTV.
If you only need simple net churn, the **ARR/MRR Forecasting** pattern might be enough.
## Architecture overview
The cohort modelling structure has three main parts:
* **Cohort definition**\
How you group customers into cohorts (for example by signup month, product, channel or segment).
* **Retention and expansion drivers**\
Retention curves by cohort, plus expansion and contraction rates by cohort.
* **Revenue and churn variables**\
Per-cohort revenue streams, aggregate revenue and churn metrics, and derived retention/net dollar retention metrics.
All of this sits within the same three-statement and driver engine as the rest of the model.
{% stepper %}
{% step %}
### Decide your cohort dimensions
First, choose how you will define cohorts. Common choices are:
* Signup month or quarter for all customers.
* Signup month or quarter by segment (for example SME vs enterprise).
* Signup by channel (for example direct, partner, self serve).
More dimensions add complexity. Start with one or two that reflect meaningful differences in behaviour.
Examples of cohort names:
* `Cohort - SME - 2024-01`
* `Cohort - SME - 2024-02`
* `Cohort - Enterprise - 2024-Q1`
{% endstep %}
{% step %}
### Create cohort size drivers
In the Data Library, create drivers for cohort sizes, for example:
* `Cohort Size - SME - 2024-01`
* `Cohort Size - SME - 2024-02`
Populate these drivers from:
* Historical data (for past cohorts).
* Forecast assumptions (for future cohorts), often linked to sales or marketing activity.
Alternatively, use a single driver that defines new customers by period and derive cohort sizes from that if your cohort dimension is simply signup month.
{% endstep %}
{% step %}
### Define retention curves
For each cohort type, define a retention curve that specifies the percentage of the cohort that remains active over time.
Implementation options:
* Generic retention drivers such as:
* `Retention Curve - SME`
* `Retention Curve - Enterprise`
* Or separate retention drivers per cohort or cohort family for more detail.
Example retention values:
* Month 1: 100%
* Month 2: 95%
* Month 3: 92%
* Month 6: 85%
* Month 12: 80%
* Month 24: 70%
Store these curves in the Data Library for reuse.
{% endstep %}
{% step %}
### Combine cohort size and retention into active customers
For each cohort, create a driver or variable for active customers over time:
Active Customers - Cohort X = Cohort Size - Cohort X ร Retention Curve (aligned by age, not by calendar date).
Because Model Reef works in calendar periods, simulate cohort age by shifting the retention curve along the timeline for each cohort. Do this by specifying non-zero retention values starting in the cohort start period and continuing over the chosen horizon.
If needed, pre-compute age-aligned retention series outside the engine and import them as cohort-specific drivers.
{% endstep %}
{% step %}
### Model cohort level revenue, churn and expansion
For each cohort, define Revenue variables that use:
* Active customers from the previous step.
* ARPA or price per customer.
* Expansion rates if applicable.
Example formula:
Revenue - MRR - Cohort X = Active Customers - Cohort X ร ARPA ร (1 + Expansion Rate)
From this you can derive:
* Cohort revenue per period.
* Cohort churned revenue as the difference between revenue at 100% retention and actual revenue.
* Expansion revenue from the expansion component.
Aggregate revenue and churn metrics can be created by summing across cohorts using categories or custom report configurations.
{% endstep %}
{% step %}
### Derive retention metrics
From cohort and revenue variables, define metrics such as:
* Logo retention: customers retained as a percentage of starting cohort size.
* Gross revenue retention: retained revenue from existing customers divided by starting revenue.
* Net revenue retention: retained revenue plus expansion divided by starting revenue.
Implement these as custom chart formulas using cohort revenue series, or as external calculations based on model exports if you need complex time alignment.
Surface key metrics on a SaaS dashboard as KPI cards and trend charts.
{% endstep %}
{% step %}
### Link cohort modelling to the wider model
Ensure cohort-based revenue variables tie into:
* COGS (e.g., support and hosting costs that scale with active customers).
* Staff planning (e.g., customer success headcount driven by cohort sizes).
* Valuation (cohort-based projections feed into cashflow and valuation models).
Keep retention and expansion assumptions in the Data Library and document them for stakeholders.
{% endstep %}
{% endstepper %}
## Check your work
* Cohort sizes and retention curves match historical behaviour where data is available.
* Aggregate MRR and ARR from cohorts reconcile to existing high level revenue series.
* Retention metrics are stable and plausible when compared with benchmarks or internal expectations.
* The structure remains understandable and is not over-engineered relative to decision needs.
## Troubleshooting
Cohort model becomes too detailed to maintain
Reduce the number of cohort dimensions and aggregate similar cohorts into families.
Retention metrics fluctuate wildly
Check that cohorts are defined consistently and that retention curves are aligned to cohort age correctly.
Stakeholders cannot follow the cohort logic
Provide a summary view that shows only total MRR, ARR and high level retention metrics, and use cohort outputs mainly for internal analysis.
## Related guides
* [Build a Cost of Goods Model](/how-tos/operations-and-unit-economics/build-a-cost-of-goods-model)
* [Build a DCF Model (FCFF)](/how-tos/valuation/build-a-dcf-model-fcff)
* [Asset Variables: what is, rules, what it affects](/help/drivers-variables-and-timing/asset-variables)
* [Chart & Table Syntax](/syntax/chart-and-table-syntax)
# CAC/LTV & Payback Analysis
This use case describes how to use Model Reef to understand customer acquisition cost (CAC), lifetime value (LTV) and payback periods for a SaaS or subscription business.
Rather than computing these metrics in a separate spreadsheet, you will derive them from the same drivers and variables that power your MRR, ARR and three statement model.
## When to use this pattern
Use this pattern when:
* You want to understand whether your go to market spending is efficient.
* You need CAC, LTV and payback metrics for board or investor discussions.
* You want to connect unit economics directly to your forecast, not treat them as stand alone calculations.
This pattern builds on **ARR/MRR Forecasting** and optionally **Churn, Retention & Cohort Modelling**.
***
## Architecture overview
CAC, LTV and payback analysis will use:
1. **Acquisition drivers and costs**
* New customers per period.
* Sales and marketing spend attributable to acquisition.
2. **Lifetime value components**
* Revenue per customer over time.
* Gross margin.
* Churn and retention.
3. **Derived unit economics**
* CAC per customer.
* LTV per customer.
* LTV to CAC ratio.
* CAC payback period.
Some metrics can be approximated inside Model Reef using formulas and charts, while others may be calculated in external tools from exported series if you need more complex definitions.
***
{% stepper %}
{% step %}
### Set up acquisition and cost drivers
In the Data Library, define drivers for:
* New customers per period, ideally by segment or channel.
* Sales and marketing spend per period, broken down enough that you can decide which costs to include in CAC (for example paid media, sales salaries, marketing tools).
In your variables:
* Use Opex and Staff variables to represent acquisition costs by category.
* Tag or classify these variables so that you can distinguish acquisition costs from retention or support costs.
This separation is important when computing CAC.
{% endstep %}
{% step %}
### Derive CAC per customer
For a given period and segment, CAC can be approximated as:
* CAC = Acquisition Costs / New Customers
Implementation options:
* Use a custom chart or report that pulls:
* The sum of selected Opex and Staff variables for acquisition.
* The number of new customers from your drivers.
* Apply a simple division in the charting layer or outside the engine.
If you have multiple channels or segments, compute CAC separately for each, using the relevant cost and customer drivers.
{% endstep %}
{% step %}
### Define LTV assumptions
LTV is conceptually:
* LTV = Lifetime Gross Profit per Customer
You will need assumptions for:
* Gross margin percentage for your SaaS product or segment.
* Average lifetime or retention behaviour:
* Either a simple expected lifetime in months or years.
* Or more detailed retention curves from cohort modelling.
In the Data Library, create drivers for:
* Gross Margin Percentage by segment.
* Expected Lifetime (months) or equivalent.
Use cohort outputs if you prefer a more detailed view of lifetime revenue.
{% endstep %}
{% step %}
### Compute LTV per customer
There are two common approaches:
* Simple approximation
* LTV = ARPA ร Gross Margin Percentage ร Expected Lifetime
* Cohort based
* Sum discounted gross profit per customer across future periods until churn, using cohort based revenue and gross margin.
The simple version can generally be implemented via custom chart formulas using:
* Revenue per customer or ARPA driver.
* Gross margin percentage driver.
* Expected lifetime driver.
For cohort based LTV, you may export cohort revenue and margin series to a separate tool if you require more complex discounting than the chart engine provides.
{% endstep %}
{% step %}
### Calculate LTV to CAC ratio
Once you have CAC and LTV per customer for a segment:
* LTV to CAC ratio = LTV / CAC
Implement this as:
* A KPI card on a SaaS dashboard using custom formulas, or
* An external calculation based on model exports if you prefer to preserve flexibility.
This ratio is one of the primary indicators of whether your acquisition strategy is sustainable.
{% endstep %}
{% step %}
### Estimate CAC payback period
CAC payback period is the time it takes for gross profit from a new customer to cover the acquisition cost.
Approximate calculation:
* Payback Period (months) = CAC / Monthly Gross Profit per Customer
Where:
* Monthly Gross Profit per Customer = ARPA ร Gross Margin Percentage
You can represent this in Model Reef using:
* Drivers and formulas for ARPA and gross margin.
* A KPI card or chart that shows how payback changes over time as assumptions evolve.
For more complex models where gross profit per customer changes over time, you may choose to do a more detailed payback calculation externally using exported cashflows.
{% endstep %}
{% step %}
### Surface metrics on a unit economics dashboard
Create a dedicated **Unit Economics** or **SaaS Metrics** dashboard that shows:
* CAC per segment or channel.
* LTV per segment.
* LTV to CAC ratio.
* CAC payback period.
* Supporting charts such as MRR growth and gross margin.
Use consistent definitions across models so that comparisons between scenarios or across time are meaningful.
{% endstep %}
{% endstepper %}
***
## Check your work
* Acquisition costs used in CAC are clearly defined and not mixed with retention or general overhead costs.
* LTV calculations use realistic gross margin and lifetime assumptions.
* LTV to CAC ratios and payback periods are in ranges that make sense for your sector and maturity stage.
* Changes in these metrics can be traced back to changes in underlying drivers.
***
## Troubleshooting
CAC appears extremely volatile
Ensure that new customer counts are not too small in the periods you are analysing, or use a rolling or aggregated view.
LTV seems unreasonably high
Check that churn and retention assumptions are not overly optimistic and that margin assumptions are realistic.
Stakeholders are confused by multiple CAC definitions
Agree a firm or team standard for what counts as acquisition cost and stick to it across your models.
***
## Related guides
* [Build a Sensitivity Analysis Pack](/how-tos/scenarios-and-planning/build-a-sensitivity-analysis-pack)
* [Build a Variance Analysis Model](/how-tos/dashboards-and-reporting/build-a-variance-analysis-model)
* [Attachments](/help/permissions-and-collaboration/attachments)
* [Cloning Scenarios](/syntax/scenario-syntax/cloning-scenarios)
# Multi-Product SaaS P\&L
This use case describes how to design a SaaS P\&L in Model Reef that supports multiple products or lines of business. The aim is to see both:
* Product level performance and unit economics.
* Consolidated SaaS P\&L for the whole company.
You will use branches, categories and variables to separate product streams while maintaining a clean group view.
## When to use this pattern
Use this pattern when:
* You sell more than one product or price tier and want separate P\&L visibility.
* You intend to allocate shared costs across products for contribution margin analysis.
* You need to understand which product lines drive growth, margin and cash.
If you only have one core product, you may still use this structure to prepare for future expansion.
## Architecture overview
The multi product P\&L structure has three main elements:
1. Branch structure
* Branch per product or product family.
* Optional head office or shared services branch.
2. Product specific variables
* Revenue, COGS and product specific costs per branch.
* Product specific drivers such as customer counts or usage metrics.
3. Shared costs and allocations
* Central costs (for example general and administrative, platform engineering).
* Allocation logic where you want to see product level contribution after shared costs.
Branches roll up into a consolidated group view automatically.
## Steps to implement
{% stepper %}
{% step %}
### Design the branch and category structure
Create a Model Reef model with branches, for example:
* `Group`
* `Product A`
* `Product B`
* `Product C`
* `Shared` (optional, for central functions)
Within each branch, use the same category structure for P\&L:
* Revenue
* COGS
* Gross profit
* Opex (sales and marketing, research and development, general and administrative)
* EBITDA and below
This consistency makes product-to-product comparison straightforward.
{% endstep %}
{% step %}
### Create product level revenue and COGS variables
In each product branch:
* Define Revenue variables such as:
* `Revenue - MRR - Product A`
* `Revenue - Add Ons - Product A`
* Link them to product specific drivers:
* Customer counts for that product
* ARPA or pricing for that product
* Conversion or attach rates for add ons
* Define COGS variables such as:
* `COGS - Hosting - Product A`
* `COGS - Payment Fees - Product A`
* `COGS - Third Party Licences - Product A`
Use the same naming pattern across branches so you can easily see how costs differ by product.
{% endstep %}
{% step %}
### Separate shared and product specific costs
Decide which costs are:
* Directly attributable to a product (for example product specific advertising, dedicated customer success)
* Shared across products (for example platform engineering, finance, HR)
Implement this by:
* Placing product specific Opex and Staff variables inside the relevant product branch
* Placing shared Opex and Staff variables inside the `Shared` or `Group` branch
This separation is important when computing contribution margin by product.
{% endstep %}
{% step %}
### Add optional cost allocation logic
If you want to see product level results after some or all shared costs are allocated:
* Decide on allocation keys, for example:
* Revenue share
* Gross profit share
* Active customer share
* Create drivers in the Data Library for these keys, such as:
* `Driver - Shared Cost Allocation - Revenue Share`
* In each product branch, create allocation variables such as:
* `Allocated Shared Opex - Product A`
* Use formulas that:
* Take the total shared cost variable
* Multiply by the allocation key for that product
You can decide whether to leave the original shared cost in the `Shared` branch for transparency or treat allocations as the only view for decision making.
For more detail, see **Build Cross Branch Drivers and Dependencies**.
{% endstep %}
{% step %}
### Build product level and consolidated P\&L views
Use reports and dashboards to provide:
* Product level P\&L:
* Revenue, COGS, gross margin
* Product specific Opex
* Optional allocated shared costs
* Product contribution margin
* Consolidated SaaS P\&L at `Group` level:
* Total revenue and gross profit
* Total Opex, EBITDA and below
Create custom reports or dashboards grouped by branch to show product comparisons side by side.
{% endstep %}
{% step %}
### Integrate with SaaS metrics and valuation
Finally, connect the multi product P\&L to:
* MRR and ARR metrics per product, from your ARR/MRR forecasting structure
* CAC and LTV analysis by product where acquisition costs and retention differ
* Valuation models that either:
* Use consolidated cashflows, or
* Model product specific cashflows where required
Keep product specific drivers in the Data Library and ensure naming makes it easy to see which product each driver relates to.
{% endstep %}
{% endstepper %}
## Check your work
Checklist
* Product branches contain only variables relevant to that product.
* Shared costs are clearly identified and, if allocated, allocation logic is documented.
* Product level and group level P and L views reconcile to each other.
* Product comparisons help answer questions about growth, margin and investment priorities.
## Troubleshooting
Branches become cluttered
Introduce a consistent naming and subcategory pattern, and archive or merge rarely used variables.
Allocations make product results hard to interpret
Provide both pre-allocation and post-allocation views so stakeholders can see raw contribution and fully loaded results.
Difficult to align SaaS metrics to product P&L
Make sure customer, ARR and MRR drivers are segmented by product in the same way as revenue variables.
## Related guides
* [Build a Multi Division Model](/how-tos/core-modelling/build-a-multi-division-model)
* [Build a Multi Period Comparison Dashboard](/how-tos/dashboards-and-reporting/build-a-multi-period-comparison-dashboard)
* [P\&L Overview](/help/financial-outputs-and-valuation/p-and-l-overview)
* [Common Size Mode](/syntax/chart-and-table-syntax/common-size-mode)
# ๐ฌ Retail (Single & Multi-Site)
# Store-Level P\&L Modelling
This use case explains how to build a store-level P\&L for a retail business using Model Reef. It covers both single site and multi site structures.
You will use branches for stores, driver based revenue and COGS, and store specific Opex and staff variables. The result is a consolidated view plus clean store level performance.
## When to use this pattern
Use this pattern when:
* You operate multiple stores and want P and L per location as well as a consolidated view.
* You want to understand which stores drive growth and which underperform.
* You need to evaluate store rollouts, closures or refits using a consistent structure.
For a group that owns multiple entities, combine this with the **Multi Entity Group Model** pattern.
## Architecture overview
You will build three layers:
1. Branch structure
* One branch per store or site.
* Optional central or head office branch for shared costs.
2. Store variables
* Revenue, COGS, store Opex and staff costs in each store branch.
* Shared drivers from the Data Library where appropriate.
3. Consolidated outputs
* P and L at store and group level.
* Cashflow, Cash Waterfall and Balance Sheet at group level.
* Store comparison dashboards.
Branches roll up automatically so the group view aggregates all stores.
{% stepper %}
{% step %}
### Design the branch structure
Create a model with branches similar to:
* `Group` (root branch)
* `Store 01`
* `Store 02`
* `Store 03`
* `Head Office` (optional)
Guidelines:
* Use simple, human readable store names or codes.
* Align with how management already thinks about the store network.
* Keep branch names stable to avoid breaking mental maps and reporting.
If you only have one store today, still use a store branch under `Group` so future expansion is easy.
{% endstep %}
{% step %}
### Define store-level revenue drivers
Retail revenue is usually driven by a small set of operational drivers, for example:
* Foot traffic or transactions.
* Average basket size or average transaction value.
* Mix of product categories or price points.
In the Data Library, create drivers such as:
* `Driver - Store 01 - Transactions`
* `Driver - Store 01 - Average Basket`
* `Driver - Store 02 - Transactions`
For each store branch, create Revenue variables like:
* `Revenue - Store 01 - Core Sales`
* `Revenue - Store 01 - Other Income`
Link them to drivers via formulas, for example:
* `Revenue = Transactions ร Average Basket`
This lets you forecast revenue by adjusting operational inputs, not just top line percentages.
{% endstep %}
{% step %}
### Model COGS by store
For each store, create COGS variables such as:
* `COGS - Store 01 - Merchandise`
* `COGS - Store 01 - Freight and Handling`
Driver options:
* Use a percentage of revenue for simplified modelling, for example:
* `COGS = Revenue ร COGS Percentage` per store.
* Or use separate unit cost drivers if you track volumes by category.
Make sure COGS variables are of type **COGS** so that gross margin, working capital behaviour and cash timing follow the standard rules.
For more detailed stock timing, see **Inventory and Replenishment Planning**.
{% endstep %}
{% step %}
### Capture store Opex and local costs
Store level Opex usually includes:
* Rent and occupancy costs.
* Utilities.
* Local marketing.
* Repairs and maintenance.
* Store supplies and consumables.
In each store branch, create Opex variables, for example:
* `Opex - Store 01 - Rent`
* `Opex - Store 01 - Utilities`
* `Opex - Store 01 - Local Marketing`
Use timing settings for:
* Monthly or quarterly rent cycles.
* Utility delays if bills are paid a period after consumption.
Place head office level costs, such as central marketing or accounting, in the `Head Office` or `Group` branch, not in individual stores.
{% endstep %}
{% step %}
### Add store workforce and roster costs
Store staffing is usually one of the largest controllable costs. In each store branch, create Staff variables for:
* Store managers.
* Full time staff.
* Casual or part time staff.
Use drivers such as:
* Number of full time equivalents per store.
* Average hourly rate and expected hours.
* Roster patterns from **Retail Workforce and Roster Forecasting**.
This lets you analyse store profitability both before and after staff costs.
{% endstep %}
{% step %}
### Integrate central costs and allocations
Central costs such as:
* Head office salaries.
* Central marketing.
* Shared logistics or warehouse costs.
belong in a head office or group branch.
If you need to show store level results after central allocations, you can:
* Decide on an allocation key, for example revenue share or floor space.
* Create Data Library drivers for allocation keys.
* Define Opex variables in each store branch like `Allocated HQ Opex - Store 01` that use a share of central cost.
For guidance, see **Build Cross Branch Drivers and Dependencies**.
{% endstep %}
{% step %}
### Build store-level and consolidated P\&L views
Use reports and dashboards to provide:
* P\&L per store showing:
* Revenue.
* COGS and gross margin.
* Store level Opex and staff.
* Contribution margin before or after central allocations.
* Consolidated P\&L at `Group` level.
* Store comparison views, for example:
* Revenue per store.
* Gross profit per store.
* Contribution margin per store.
This structure makes it easy to see which stores are performing and which are dragging the group down.
{% endstep %}
{% endstepper %}
## Check your work
* Each store branch contains only store specific variables.
* Central costs are clearly separated from store costs.
* Store P\&Ls roll up to the consolidated P\&L without gaps or double counting.
* Drivers for revenue and staffing reflect the operational reality of each location.
## Troubleshooting
Store results do not reconcile to accounting reports
Check that imports or manual entries for revenue and COGS per store align with the way the ledger is coded. You may need additional mapping if accounts are not split by store in the source system.
Allocations obscure true store performance
Provide both pre allocation and fully loaded views in your dashboards so stakeholders can see both raw and allocated profitability.
Branch structure becomes unwieldy as stores grow
Use consistent naming and consider grouping stores under regional branches if the network is large.
## Related guides
* [Build a Debt Schedule & Covenants Model](/how-tos/investment-and-transactions/build-a-debt-schedule-and-covenants-model)
* [Build a Dilution / Cap Table Impact Model](/how-tos/investment-and-transactions/build-a-dilution-cap-table-impact-model)
* [Branch Level Permissions](/help/permissions-and-collaboration/branch-level-permissions)
* [Data Library Viewer](/syntax/understanding-the-interface/data-library-viewer)
# Inventory & Replenishment Planning
This use case explains how to represent retail inventory and replenishment planning inside Model Reef.
Model Reef does not have a dedicated inventory ledger module, but you can approximate inventory behaviour using COGS timing, drivers and working capital style variables. The aim is to forecast purchases, cost of goods and cash requirements for stock holding in a way that is good enough for planning and scenario analysis.
## When to use this pattern
Use this pattern when:
* You have meaningful stock holdings and want to understand cash tied up in inventory.
* You need to plan purchases and replenishment cycles as part of cashflow and funding discussions.
* You are comfortable with an approximation rather than full inventory accounting.
If you need detailed SKU level stock control, you will generally run that in a specialist system and feed summary series into Model Reef.
## Architecture overview
You will build four elements:
{% stepper %}
{% step %}
### Demand drivers
* Expected sales volumes by category or store.
* Seasonality patterns and promotions.
{% endstep %}
{% step %}
### Inventory policy drivers
* Target weeks or months of cover.
* Reorder points and lead times.
* Safety stock assumptions.
{% endstep %}
{% step %}
### Purchase and COGS variables
* Purchases modelled as COGS or as Asset purchases depending on detail required.
* COGS driven by sales volumes and unit costs.
{% endstep %}
{% step %}
### Working capital approximation
* Inventory related timing differences captured through COGS delays and, optionally, Asset style inventory balances.
{% endstep %}
{% step %}
### Step 1: Create demand and unit cost drivers
In the Data Library, define drivers for:
* Sales volume by product category or store, for example:
* `Driver - Units - Store 01 - Category A`.
* Unit cost per category, for example:
* `Driver - Unit Cost - Category A`.
These drivers will be used to derive both revenue (via units and price) and COGS (via units and unit cost).
If detailed volume data lives in another system, import it as a CSV series and tag it clearly.
{% endstep %}
{% step %}
### Step 2: Define inventory policy assumptions
Inventory policies can be approximated using:
* Target cover, for example:
* `Weeks of Cover - Category A`.
* `Months of Cover - Category B`.
* Lead times from order to receipt, for example:
* `Lead Time - Category A`.
Create these as Data Library drivers, often as Modifier type, for example:
* `Assumption - Weeks of Cover - Category A`.
* `Assumption - Lead Time - Category A`.
Document the rationale in notes so that changes can be reviewed in future.
{% endstep %}
{% step %}
### Step 3: Estimate required purchases
At a planning level, required purchases per period can be approximated as:
* Required Purchases = Forecast COGS plus Change in Desired Inventory.
You can represent this by:
* Using units:
* Compute required units = forecast sales units plus change in target stock units.
* Multiply by unit cost to get purchase cost.
* Or using value only:
* Model COGS as a percentage of revenue and adjust timing and magnitude using working capital assumptions.
In Model Reef, it is usually enough to create COGS variables that:
* Are driven by sales volumes and unit costs.
* Use timing and delays to approximate when cash leaves the business for purchases.
For more detail, you can add an Asset variable for `Inventory` and manually link purchases and COGS to changes in that balance, acknowledging that this is an approximation rather than fully automated inventory accounting.
{% endstep %}
{% step %}
### Step 4: Model cash timing for purchases
Use COGS timing and delay settings to represent payment terms with suppliers, for example:
* `COGS - Merchandise Purchases` with:
* Occurrence based on expected purchase timing.
* Delay representing supplier credit terms (for example 30 days or 60 days).
This creates Accounts Payable and captures the effect of inventory purchases on cashflow and working capital without tracking per SKU stock movements.
You can adjust the pattern of purchases to reflect known pre season buy ins or long lead time imports.
{% endstep %}
{% step %}
### Step 5: Represent inventory build up and run down
If you want to see a notional inventory balance:
* Create an Asset variable named, for example, `Inventory Balance`.
* Use a simple rule such as:
* Inventory balance equals a certain number of weeks or months of forecast COGS.
* Link this to cash by treating inventory changes as affecting working capital, for example:
* Increase inventory when building up for peak periods.
* Decrease inventory when running it down in off season.
This approximates the cash tied up in stock without implementing full inventory accounting rules.
{% endstep %}
{% step %}
### Step 6: Build an inventory focused dashboard
Create a dashboard that shows:
* Purchases, COGS and notional inventory balance over time.
* Cashflow impact of inventory, for example in the Cash Waterfall via working capital changes.
* Key assumptions such as weeks of cover and lead times as prominent KPIs.
Use this dashboard in planning meetings to discuss inventory and cash strategies without diving into line by line stock details.
{% endstep %}
{% endstepper %}
## Check your work
* Demand and unit cost drivers align with how the business plans merchandising.
* Purchases and COGS patterns look reasonable with respect to known buying cycles.
* Cash outflows for inventory are captured with realistic timing in the Cashflow Statement.
* If using an inventory balance approximation, the values are in a plausible range relative to revenue and COGS.
## Troubleshooting
Inventory balance looks implausible
Revisit your weeks or months of cover assumptions and unit cost estimates. Small changes can have large effects.
Cash crunch appears in the model but not in reality
Check payment terms and whether certain purchases are financed or deferred in ways not yet reflected in the model.
You need highly granular SKU behaviour
Keep detailed stock management in a dedicated system and feed only aggregated series such as total purchases, total COGS and category level volumes into Model Reef.
## Related guides
* [Build an Annual Planning Pack](/how-tos/scenarios-and-planning/build-an-annual-planning-pack)
* [Build an Inventory Timing Model](/how-tos/operations-and-unit-economics/build-an-inventory-timing-model)
* [Authentication (OAuth)](/help/xero-integration/authentication-oauth)
* [Drilldown Behaviour](/syntax/chart-and-table-syntax/drilldown-behaviour)
# New Store Expansion Model
This use case explains how to build a new store expansion model in Model Reef for retail businesses.
You will use branches to represent existing and planned stores, capex and pre opening costs for new locations, store specific revenue and cost drivers, and valuation outputs to assess the economics of expansion.
## When to use this pattern
Use this pattern when:
* You are planning to open one or more new stores in an existing retail network.
* You want to understand how new stores affect group P\&L, cash and funding needs.
* You need to compare different rollout speeds or location strategies.
This pattern builds on **Store Level P\&L Modelling** and **Inventory and Replenishment Planning**.
## Architecture overview
The expansion model includes:
* Branch structure
* Existing stores.
* New store branches for planned openings.
* Head office or group branch.
* New store drivers
* Ramp up for traffic, conversion and basket size.
* Store specific cost and staffing assumptions.
* Capex and pre opening expenses.
* Outputs and evaluation
* Store level and group P\&L.
* Cashflow and funding requirements.
* Store level and network level IRR and payback.
## Steps
{% stepper %}
{% step %}
### Start from an existing store-level model
Begin with a working store level model as described in **Store Level P\&L Modelling**:
* Existing store branches with revenue, COGS, Opex and staff.
* Head office and central costs in a separate branch.
* Inventory purchasing and timing where relevant.
Clone this model to create a dedicated expansion planning model, for example:
* `Retail - Expansion Plan Model`.
This keeps your planning scenarios separate from day to day operational models.
{% endstep %}
{% step %}
### Add branches for planned new stores
In the expansion model, add branches for each new store, for example:
* `Group`.
* `Store 01` (existing).
* `Store 02` (existing).
* `New Store A`.
* `New Store B`.
For each new store branch:
* Copy the variable structure from an existing store that is similar in format.
* Clear or adjust assumptions so they represent a new store rather than a mature store.
This gives you a consistent starting point for each planned location.
{% endstep %}
{% step %}
### Model new store capex and pre opening costs
For each new store branch, add Asset and Opex variables to represent:
* Fitout and build costs as Assets with depreciation schedules.
* Equipment and fixtures.
* Pre opening marketing and training as Opex.
* Any lease incentives or landlord contributions if material.
Use timing and delays to align spending with the planned opening date, for example:
* Fitout capex over the three to six months before opening.
* Pre opening marketing in the one or two months before opening.
This allows the Cashflow Statement and Cash Waterfall to show the investment phase clearly.
{% endstep %}
{% step %}
### Build new store revenue ramp up
New stores rarely trade at steady state from day one. For each new store branch:
* Define ramp up drivers in the Data Library, for example:
* `Ramp - Store A - Footfall`.
* `Ramp - Store A - Conversion`.
* `Ramp - Store A - Average Basket`.
* Set the ramp so that:
* Early months have lower volumes or conversion.
* The store reaches a target steady state after a defined period (for example 12 to 24 months).
* Use these drivers in store revenue variables, combining with base assumptions for mature stores where appropriate.
You can calibrate ramp patterns using historical data from previous new store openings.
{% endstep %}
{% step %}
### Set new store staffing and operating costs
For each new store, configure Staff and Opex variables to reflect:
* Pre opening staff build up.
* Full staffing levels after opening.
* Fixed and variable components of store operating costs.
Be explicit about:
* Store manager and core staff.
* Casual or part time staff that scale with traffic or sales.
* Rent and occupancy costs based on the specific lease.
This ensures that store level P\&L shows both ramp up losses and later profitability.
{% endstep %}
{% step %}
### Evaluate store and network level economics
With branches configured, use Model Reef outputs to assess:
* Store level P\&L and cash contributions over time.
* Network level P\&L and cash including existing stores and new stores.
* Peak funding requirement caused by capex and early operating losses.
* Store specific metrics such as:
* Time to break even.
* Cash payback period for store level capex.
Use the valuation engine to compute store or network level IRR and Money Multiple if needed, by treating capex as investments and store contributions as returns.
{% endstep %}
{% step %}
### Explore rollout scenarios
To compare different expansion strategies:
* Create separate models for alternative scenarios, for example:
* `Expansion Plan - Slow Rollout`.
* `Expansion Plan - Base Rollout`.
* `Expansion Plan - Fast Rollout`.
* Vary:
* Number of new stores.
* Opening dates.
* Capex per store.
* Ramp assumptions.
Compare outcomes for:
* Peak and cumulative funding requirements.
* Network profitability timelines.
* Store level economics.
This helps management choose a rollout strategy that matches capital availability and risk appetite.
{% endstep %}
{% endstepper %}
## Check your work
* New store branches are clearly identifiable and separate from existing stores.
* Capex, pre opening costs and ramp assumptions align with realistic timelines.
* Group P\&L and cashflow clearly show the impact of expansion on performance and funding.
* Results are easy to explain to non modelling stakeholders.
## Troubleshooting
Expansion model becomes too cluttered
Limit visible detail to key stores or group new stores into cohorts where fine grain analysis is not required.
Funding requirement seems out of line with experience
Double check capex, trading losses and working capital assumptions, especially around inventory and payment terms.
Difficult for stakeholders to follow technical detail
Build a summarised expansion dashboard that focuses on total investment, payback period, peak cash draw and timing of profitability.
## Related guides
* [Build a Discount Rate Scenario Model](/how-tos/valuation/build-a-discount-rate-scenario-model)
* [Build a Driver Based Forecast](/how-tos/core-modelling/build-a-driver-based-forecast)
* [Balance Sheet Overview](/help/financial-outputs-and-valuation/balance-sheet-overview)
* [Driver Editor Screen](/syntax/understanding-the-interface/driver-editor-screen)
# Retail Workforce & Roster Forecasting
This use case shows how to model retail workforce and roster costs in Model Reef. You will use Staff variables, drivers for hours and wage rates, and branch structures to represent staffing across stores.
The objective is to connect store rosters directly to P\&L, cash and headcount planning.
## When to use this pattern
Use this pattern when:
* Staff costs are a major driver of store profitability.
* You roster staff by week or day and want that logic reflected in your forecast.
* You need to understand how staffing plans interact with sales scenarios.
This pattern builds on **Store Level P\&L Modelling** and can support both single store and multi store networks.
## Architecture overview
You will build:
* Branch structure
* One branch per store.
* Optional head office branch for central staff.
* Workforce drivers
* Open hours per store.
* Expected traffic or sales per period.
* Hours per transaction or per sales level.
* Wage rates by role.
* Staff variables
* Manager, key full time staff, and casual or part time staff per store.
* Timing and pay cycle behaviour.
* Outputs
* Staff cost per store and per period.
* Staff cost as a share of sales.
* Cashflow impact of payroll.
{% stepper %}
{% step %}
### Decide your time granularity
Roster planning is often weekly, while most planning models are monthly.
Options:
* Keep the model at monthly granularity and approximate rosters via monthly averages.
* Use weekly granularity if workforce decisions are very sensitive and you need that resolution.
Choose the periodicity when creating the model. You can always aggregate weekly models to monthly or quarterly views in dashboards and reports.
{% endstep %}
{% step %}
### Define workforce drivers
In the Data Library, create drivers such as:
* `Store 01 - Open Hours per Week`
* `Store 01 - Expected Transactions per Week`
* `Hours per Transaction`
* `Hours per Open Day`
You can derive required hours from sales or service standards, for example:
* `Required Hours = Base Hours plus Hours per Transaction ร Transactions`
Also create wage rate drivers for each role:
* `Wage Rate - Store Manager`
* `Wage Rate - Casual Staff`
These can vary over time to reflect expected increases.
{% endstep %}
{% step %}
### Create Staff variables for each store
In each store branch, define Staff variables for:
* Store manager
* Supervisors if relevant
* Full time staff
* Casual or part time staff
For each Staff variable, configure:
* Number of staff or FTEs
* Hours per period
* Wage rate driver
* Oncosts, such as superannuation or payroll tax, using built in staff cost behaviour where available or explicit drivers
This will generate staff costs that flow into Opex and Cashflow automatically.
{% endstep %}
{% step %}
### Link staffing levels to sales or traffic
To make rosters responsive to expected demand, use formulas that connect staff hours to sales or traffic drivers, for example:
* Casual hours per week based on forecast transactions:
* `Casual Hours = Base Casual Hours plus Hours per Transaction ร Transactions`
* Additional staff for peak periods using seasonality drivers
Keep the relationships as simple as possible while still reflecting how rosters are actually built in the business.
{% endstep %}
{% step %}
### Model timing of payroll cashflows
Use the timing settings on Staff variables to represent payroll cycles, for example:
* Weekly or fortnightly pay cycles translated into the model periodicity
* Small delays between end of work period and actual cash payment
This ensures that both P\&L and Cashflow reflect payroll correctly:
* Staff costs accrue when hours are worked.
* Cash leaves when payroll runs.
Staff related payables will appear in working capital between accrual and payment.
{% endstep %}
{% step %}
### Build workforce and roster dashboards
Create a Workforce or Roster dashboard that shows:
* Staff cost per store over time
* Staff cost as a percentage of revenue per store
* FTE equivalent counts by store and role
* High level ratios, such as revenue per labour hour
These views help management see whether staffing plans look realistic in the context of expected sales.
{% endstep %}
{% step %}
### Stress test staff plans against scenarios
When you change sales forecasts in different scenarios:
* Update transactions or revenue drivers
* Allow workforce formulas to recompute required hours and staff costs
* Compare staff cost to revenue ratios between scenarios
This helps answer questions such as:
* What happens to labour productivity in a downside scenario?
* What staffing is required to support an upside sales plan?
Because scenarios are separate models, you can make different staffing assumptions in each without affecting the others.
{% endstep %}
{% endstepper %}
## Check your work
* Staff variables exist for all important store roles and match current workforce levels.
* Wage and hour assumptions are grounded in real rosters.
* Staff cost outputs tie back to historical payroll where data is available.
* Staff cost percentages and ratios are inside expected ranges for your retail category.
## Troubleshooting
Staff costs appear too smooth or unrealistic
Increase the sensitivity of staff hours to sales or traffic drivers, or use a finer time granularity if necessary.
Payroll timing does not match cash reality
Adjust the delay settings and pay cycle assumptions in Staff variables until cash outflows align with your payroll calendar.
Too many Staff variables become hard to manage
Group similar roles where possible and use clear naming per store and role, for example `Staff - Store 01 - Casual Floor`.
## Related guides
* [Build a Forecast Accuracy Tracker](/how-tos/scenarios-and-planning/build-a-forecast-accuracy-tracker)
* [Build a Forecast from Ticker Fundamentals](/how-tos/data-workflows-and-automation/build-a-forecast-from-ticker-fundamentals)
* [Branch Hierarchy Rules](/help/building-your-model/branch-hierarchy-rules)
* [Drivers Syntax](/syntax/drivers-syntax)
# ๐ฝ๏ธ Hospitality (Restaurants, Cafรฉs, Bars)
# Venue-Level Cost & Margin Modelling
This use case explains how to build a venue-level P\&L for restaurants, cafรฉs and bars in Model Reef.
You will use:
* Branches to represent each venue.
* Driver-based revenue for food, beverage, delivery and functions.
* COGS, staff and operating costs per venue.
* Consolidated views across the group.
The goal is to understand venue profitability and margin structure without relying on fragile spreadsheets.
## When to use this pattern
Use this pattern when:
* You operate one or more venues and want clear P\&L visibility per site.
* You want to model covers, average spend and mix rather than just top line percentages.
* You need to compare venues and test changes in labour, pricing or menu mix.
If you manage many venues across entities, combine this with the **Multi Entity Group Model** pattern.
## Architecture overview
The structure has three layers:
* Branch structure
* One branch per venue.
* Optional central branch for head office and shared costs.
* Venue variables
* Revenue variables per stream (food, beverage, delivery, functions).
* COGS per category.
* Staff and operating costs per venue.
* Outputs
* Venue-level P\&L.
* Consolidated group P\&L, Balance Sheet, Cashflow and Cash Waterfall.
* Margin dashboards focused on gross margin and prime cost.
{% stepper %}
{% step %}
### Set up the venue branches
Create a model with branches such as:
* `Group` (root).
* `Venue - City Centre`.
* `Venue - Suburb A`.
* `Venue - Suburb B`.
* `Head Office` (optional).
Guidelines:
* Name branches in the same way the business refers to its venues.
* Use one branch per trading location, not per cost centre, for clarity.
* Keep `Head Office` or `Central` for non venue specific costs.
Branches roll up automatically to `Group`, providing consolidated numbers.
{% endstep %}
{% step %}
### Build venue revenue drivers
Hospitality revenue is usually driven by:
* Covers (guests served).
* Average spend per cover.
* Service mix (lunch, dinner, drinks only).
* Seasonal patterns and day-of-week effects.
In the Data Library, create drivers such as:
* `Covers - Venue City Centre`.
* `Average Spend per Cover - Venue City Centre`.
* `Covers - Lunch Share`.
* `Covers - Dinner Share`.
In each venue branch, define Revenue variables, for example:
* `Revenue - Food - Venue City Centre`.
* `Revenue - Beverage - Venue City Centre`.
* `Revenue - Delivery - Venue City Centre`.
Use formulas like:
* `Revenue - Food = Covers ร Average Food Spend per Cover`.
* `Revenue - Beverage = Covers ร Average Beverage Spend per Cover`.
You can introduce seasonality by applying monthly or weekly multipliers to covers or spend drivers.
{% endstep %}
{% step %}
### Model food and beverage COGS
For each venue, create COGS variables that reflect:
* Food ingredients.
* Beverage costs (beer, wine, spirits, soft drinks).
* Packaging and disposables for delivery or takeaway.
Common patterns:
* COGS as a percentage of revenue per category:
* `COGS - Food = Revenue - Food ร Food COGS Percentage`.
* `COGS - Beverage = Revenue - Beverage ร Beverage COGS Percentage`.
* Or more detailed unit cost modelling if you have robust data.
Make sure COGS variables are typed as **COGS** so they affect gross margin correctly.
For menu level costing, see **Menu Pricing & Recipe Costing**.
{% endstep %}
{% step %}
### Add staff costs per venue
Staff costs are usually a major driver of venue profitability. In each venue branch, create Staff variables for roles such as:
* Front of house (servers, hosts).
* Back of house (chefs, kitchen hands).
* Bar staff.
* Venue managers.
Use drivers and Staff variables to represent:
* Hours per week or per service.
* Hourly rates or salaries.
* Oncosts such as superannuation or payroll tax.
You can link hours to revenue or covers where appropriate, for example:
* `Casual Hours = Base Hours plus Hours per Cover ร Covers`.
This ensures labour moves with volumes in your scenarios.
For more detail, see **Retail Workforce and Roster Forecasting** which applies similarly to hospitality venues.
{% endstep %}
{% step %}
### Capture venue operating costs
Create Opex variables per venue for items such as:
* Rent and outgoings.
* Utilities.
* Cleaning and linen.
* Licences and compliance fees.
* Local marketing and promotion.
* Repairs and maintenance.
Implement timing and delays to match how invoices and payments occur, for example:
* Monthly rent with no delay.
* Utilities billed in arrears with a one-month delay.
Place group-level or head office costs in the `Head Office` or `Group` branch, not inside individual venues.
{% endstep %}
{% step %}
### Build venue-level margin views
With revenue, COGS, staff and Opex per venue in place, use reports and dashboards to show:
* Revenue per venue over time.
* Gross profit and gross margin per venue.
* Staff cost as a percentage of revenue.
* Prime cost (Food COGS plus Labour) as a percentage of revenue.
* EBITDA per venue.
You can build custom reports grouped by branch to compare venues side by side and identify:
* Underperforming venues.
* Venues with good revenue but poor margin.
* Venues with healthy margin but low volumes.
{% endstep %}
{% step %}
### Use scenarios for menu, pricing and labour changes
Because scenarios are independent models, you can clone the venue model to test changes such as:
* New menu pricing.
* Adjusted portion sizes or recipes.
* Different roster patterns.
* Venue specific promotions or discounting.
Compare scenario models using:
* P\&L and Cashflow at venue and group level.
* Prime cost and gross margin trends.
* Cash Waterfall impacts.
You can then decide which changes to implement operationally.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
### Check your work
* Revenue drivers reflect how the venues actually operate (covers, average spend, mix).
* COGS percentages or unit costs are realistic for the cuisine and beverage mix.
* Staff roles and hours match current rosters or planned changes.
* Venue P\&Ls roll up cleanly to the consolidated group view.
{% endhint %}
## Troubleshooting
Venue P&Ls do not reconcile to accounting reports
Confirm that any imported revenue and COGS lines are properly allocated to the correct venue branches, and that mapping from the ledger or source files is accurate.
Prime cost looks unrealistically low or high
Revisit both COGS percentages and staff hours or rates. Restaurant margins are very sensitive to these assumptions.
Venue comparison is noisy
Use averages per cover, per seat or per square metre as complementary KPIs to simple totals.
## Related guides
* [Build a Staffing Cost Model](/how-tos/operations-and-unit-economics/build-a-staffing-cost-model)
* [Build a KPI Dashboard](/how-tos/dashboards-and-reporting/build-a-kpi-dashboard)
* [Model Level Permissions](/help/permissions-and-collaboration/model-level-permissions)
* [Economic Driver Fields](/syntax/drivers-syntax/economic-driver-fields)
# Menu Pricing & Recipe Costing
This use case describes how to cost recipes and set menu prices for hospitality venues using Model Reef.
Rather than relying on static spreadsheets, you will:
* Maintain an ingredient library with costs per unit.
* Define recipe cost per portion.
* Link those costs to menu prices and sales volumes.
* See the effect on venue-level COGS and gross margin.
{% hint style="info" %}
Model Reef does not replace a specialist stock system. Instead, it provides a planning-level recipe costing model that feeds into your P\&L and margin analysis.
{% endhint %}
***
## When to use this pattern
Use this pattern when:
* You want a clear view of food and beverage margins by menu item or category.
* You need to test the impact of price changes or recipe changes on margin.
* You care about prime cost and contribution of key items.
If you run complex inventory or recipe management operationally, treat Model Reef as the forecasting and planning layer, not as the live operational system.
***
## Architecture overview
You will build:
1. Ingredient library
* Ingredient cost per unit (for example per kilogram or per litre).
* Units and conversion factors.
2. Recipe cost drivers
* Quantities of each ingredient per serve.
* Cost per portion for each menu item.
3. Menu pricing and volume drivers
* Menu prices per item.
* Forecast sales volumes and mix.
4. Revenue and COGS variables
* Revenue per item or category.
* COGS per item or category.
* Aggregated venue-level COGS and margins.
***
{% stepper %}
{% step %}
### Step 1: Build an ingredient cost library
In the Data Library, create entries for each ingredient you care about at planning level, for example:
* `Ingredient - Chicken Breast - Cost per kg`.
* `Ingredient - Olive Oil - Cost per litre`.
* `Ingredient - Flour - Cost per kg`.
* `Ingredient - House Wine - Cost per litre`.
For each ingredient, specify:
* Units (for example kilograms, litres).
* Cost per unit.
* Tags indicating whether this is food or beverage.
Update these costs periodically to reflect supplier price changes.
If you already maintain ingredient costs in another system, you can export them and import into Model Reef as CSV series.
{% endstep %}
{% step %}
### Step 2: Define recipe quantities and yields per serve
For each menu item you want to cost, create drivers that represent recipe quantities per serving, for example:
* `Recipe - Chicken Burger - Chicken Breast grams`.
* `Recipe - Chicken Burger - Bun units`.
* `Recipe - Chicken Burger - Sauce grams`.
You can either:
* Maintain these directly in Model Reef as Modifier-style drivers, or
* Maintain them in a spreadsheet and import as a single cost-per-serve driver per menu item.
If you maintain them directly, make sure you document:
* Quantity per serve.
* Yield or wastage assumptions (for example trimmings, cooking loss).
This will make it easier to update recipes later.
{% endstep %}
{% step %}
### Step 3: Calculate cost per portion
Next, compute cost per serve for each menu item.
There are two implementation options:
* Inside Model Reef
* Use formula-style variables or drivers to calculate:
* `Cost per Serve = Sum of (Ingredient Quantity per Serve ร Ingredient Cost per Unit ร Conversion Factor)`.
* Store the resulting series as a driver such as `Cost per Serve - Chicken Burger`.
* Outside Model Reef
* Perform the above calculation in a recipe cost spreadsheet or specialist system.
* Import the resulting `Cost per Serve` series for each menu item into the Data Library.
In both cases, you end up with a time-series for cost per portion for each dish or drink that may change over time as ingredient prices change.
{% endstep %}
{% step %}
### Step 4: Set menu prices and sales volume drivers
In the Data Library, create drivers for:
* Menu price per item, for example:
* `Menu Price - Chicken Burger`.
* `Menu Price - House Red Wine Glass`.
* Sales volumes per period, for example:
* `Covers choosing Chicken Burger`.
* `Glasses of House Red Wine sold`.
Sales volumes can be derived from:
* Overall covers and mix percentages (for example 20 percent of mains are Chicken Burgers).
* Direct forecasts or historical POS data imported as CSV.
Menu prices can be stepped over time to reflect planned price increases.
{% endstep %}
{% step %}
### Step 5: Create revenue and COGS variables by menu item or category
For each menu item or category, create Revenue and COGS variables in the relevant venue branch, for example:
* `Revenue - Chicken Burger - Venue City Centre`.
* `COGS - Chicken Burger - Venue City Centre`.
Define formulas such as:
* `Revenue - Item = Volume ร Menu Price`.
* `COGS - Item = Volume ร Cost per Serve`.
You can also aggregate multiple items into category-level variables (for example Burgers, Salads, Starters) if you do not need item-level visibility everywhere.
Because COGS variables are typed as **COGS**, they will flow into gross margin correctly.
{% endstep %}
{% step %}
### Step 6: Analyse margins and test pricing scenarios
With recipe costs and menu prices wired into revenue and COGS, you can:
* Compute margin per item: `Margin per Serve = Menu Price minus Cost per Serve`.
* Compute percentage margin per item: `Margin Percentage = Margin per Serve divided by Menu Price`.
* Examine category-level margins by aggregating items.
Use dashboards to show:
* Top items by revenue.
* Top items by margin.
* Items with good revenue but weak margin.
* Items with high margin but low volume.
To test pricing or recipe changes:
* Adjust menu price or recipe cost drivers.
* Recalculate the model.
* Observe the effect on venue and group level P\&L and Cash Waterfall.
{% endstep %}
{% step %}
### Step 7: Connect to venue-level planning
Finally, ensure that menu-level costing links back into your wider venue model:
* Sum menu COGS into the same COGS categories used in **Venue-Level Cost and Margin Modelling**.
* Align menu revenue with venue revenue variables where you need consistency.
* Use the same branches for venues so reports can show menu impact per venue.
You can also use recipe cost outputs to inform inventory and purchase planning at a higher level.
{% endstep %}
{% endstepper %}
***
## Check your work
* Ingredient costs are realistic and updated for recent supplier changes.
* Recipe quantities and yields are representative of how dishes are actually prepared.
* Menu prices and volumes align with past performance or realistic plans.
* Venue-level margins reconcile to menu-level margins when aggregated.
***
## Troubleshooting
Recipe costing becomes too detailed to maintain
Focus on key items that matter most to cost and margin and group the rest into approximate categories.
Margins look off compared to historic performance
Compare modelled cost per serve with actual food cost percentages from the P\&L and adjust recipes or shrinkage assumptions accordingly.
Too many menu items clutter the model
Use categories for day-to-day planning and reserve item-level detail for analysis in a separate view or exported data set.
***
## Related guides
* [Build a Pricing Model](/how-tos/operations-and-unit-economics/build-a-pricing-model)
* [Build a Machine Readable Model for Automation](/how-tos/data-workflows-and-automation/build-a-machine-readable-model-for-automation)
* [COA Import](/help/xero-integration/coa-import)
* [Editing Bounds](/syntax/how-input-fields-work/editing-bounds)
# Multi-Venue Consolidated Reporting
This use case describes how to build consolidated reporting for restaurants, cafรฉs and bars operating across multiple venues.
You will use branches to represent venues, shared reporting structures for P\&L and Cashflow, and dashboards that show both venue-level and group-level performance.
If your venues sit in multiple legal entities, combine this pattern with **Multi Entity Group Model** or **Multi Entity Consolidation (QBO/Xero)**.
## When to use this pattern
Use this pattern when:
* You run more than one venue and want a single consolidated view.
* You need to compare venues side by side in a consistent format.
* You report group performance to owners, investors or lenders.
This pattern assumes that venue operations are similar enough that a shared reporting layout makes sense.
***
## Architecture overview
The consolidated reporting structure includes:
* Branch tree
* One branch per venue.
* Optional regional branches if the network is large.
* Head office branch for shared costs.
* Shared P\&L structure
* Same revenue, COGS and Opex categories in each venue.
* Consistent mapping from data sources into categories.
* Reports and dashboards
* Group P\&L, Cashflow and Cash Waterfall.
* Venue comparison views.
* Drilldowns from group totals to individual venues.
***
{% stepper %}
{% step %}
### Decide the reporting structure
Define a standard P\&L layout for all venues, for example:
* Revenue: food, beverage, other.
* COGS: food, beverage.
* Gross profit and gross margin.
* Staff: front of house, back of house, managers.
* Other Opex: rent, utilities, marketing, repairs, licences.
* Venue EBITDA.
Document this structure so that every venue follows it.
{% endstep %}
{% step %}
### Build the branch tree for venues
Create a model with branches such as:
* `Group`
* `Venue - City Centre`
* `Venue - Suburb A`
* `Venue - Suburb B`
* `Head Office`
If you have many venues, consider grouping them under regional branches, for example `Region North`, `Region South`, with venues as children.
Branches will roll up automatically into the group branch for consolidated output.
{% endstep %}
{% step %}
### Map data into each venue branch
Populate each venue branch with its own:
* Revenue variables (food, beverage, other income).
* COGS variables.
* Staff and Opex variables.
Data can come from:
* PDF or Excel exports from accounting or POS systems.
* Xero or QuickBooks, if the chart of accounts is set up to segment venues.
* CSV imports where you maintain venue splits manually.
Apply the same category mapping for each venue so that reports align across the network.
{% endstep %}
{% step %}
### Separate head office and shared costs
Use a dedicated branch such as `Head Office` or `Central` for:
* Executive salaries.
* Central marketing.
* Administration and finance.
* System licences and group insurances.
This ensures venue branches reflect local economics, while the group branch includes both venue and central costs.
If you need allocated views, see **Build Cross Branch Drivers and Dependencies** to allocate central costs back to venues using revenue or other keys.
{% endstep %}
{% step %}
### Build group and venue report views
Use Model Reef reports and dashboards to provide:
* Group level P\&L and Cashflow.
* Venue level P\&L views.
* Comparisons such as:
* Revenue per venue.
* Gross margin per venue.
* Staff cost as a percentage of revenue per venue.
* Venue EBITDA and contribution.
You can create:
* Group reports that include breakdowns by branch.
* Venue specific reports for local managers that only show their venue branch if you plan to apply branch-level permissions in future.
{% endstep %}
{% step %}
### Use scenarios for network planning
For planning and budgeting, clone the base model into separate models representing scenarios such as:
* Base trading plan.
* Downside trading plan.
* Expansion with additional venues.
* Rationalisation with planned closures.
For each scenario model, adjust venue assumptions and compare:
* Group revenue and EBITDA.
* Cash requirements and funding needs.
* Venue profitability and potential closure candidates.
Because scenarios are separate models, you can modify them independently while preserving the original structure.
{% endstep %}
{% step %}
### Standardise across the hospitality group or portfolio
To use this pattern across a portfolio of hospitality clients or venues:
* Keep the branch and category layout as consistent as possible.
* Use naming conventions for venue branches and key variables.
* Maintain a central assumption library for shared assumptions, such as wage escalation or general cost inflation.
This makes it easier to train staff and reuse patterns across different models.
{% endstep %}
{% endstepper %}
***
## Check your work
* All venue branches follow the same category structure.
* Head office costs are clearly separated but included in group results.
* Group P\&L matches the sum of venues plus central costs.
* Dashboards and reports allow users to move quickly between group and venue perspectives.
***
## Troubleshooting
Venue results do not reconcile to group totals
Check that all venue branches are enabled and that no data is being double counted between venue and head office branches.
Too many venues make reports hard to read
Use regional branches and filters to show smaller subsets of venues at a time. Provide summary tables that rank venues by key metrics.
Stakeholders focus only on venue totals
Include ratios such as margin percentages and revenue per seat to give more nuanced views.
***
## Related guides
* [Dashboards & Reporting](/how-tos/dashboards-and-reporting)
* [Build a Recurring Revenue Forecast](/how-tos/core-modelling/build-a-recurring-revenue-forecast)
* [COA Import](/help/xero-integration/coa-import)
* [Editing Driver Time Series](/syntax/drivers-syntax/editing-driver-time-series)
# Weekly Cash Flow for Hospitality
This use case explains how to build a weekly cashflow model for restaurants, cafรฉs and bars in Model Reef.
Hospitality is cash intensive, with short cycles between trading, payroll, rent and supplier payments. Weekly visibility can be more useful than monthly reporting when managing runway, staffing and ordering decisions.
You will use weekly model periodicity, driver-based revenue and costs, and timing rules for payments and receipts.
## When to use this pattern
Use this pattern when:
* You need to manage short term cash risk in a hospitality business.
* You make staffing, ordering and payment decisions weekly.
* Monthly cashflow views are too coarse to be actionable.
If you require daily visibility, you can use daily periodicity and then aggregate to weeks in dashboards, but weekly is usually sufficient for planning.
## Architecture overview
A weekly cashflow model uses:
* Weekly periodicity โ the model is built with weeks as the base period.
* Weekly drivers โ revenue drivers per week; staff hours and wage costs per week; weekly purchasing and other costs.
* Timing rules โ delays between card/platform receipts and cash arrival; supplier payment terms; payroll and rent cycles.
* Cash outputs โ weekly Cashflow Statement and Cash Waterfall; minimum cash balance and funding gap views.
{% stepper %}
{% step %}
### Create a weekly model
When creating the model:
* Choose weekly as the periodicity.
* Set a start date and end date that cover the planning horizon (for example 12 to 24 months).
* Align the start date to the start of a trading week if possible.
You can still view results on a monthly or quarterly basis using reporting aggregation, but calculations will occur at weekly resolution.
{% endstep %}
{% step %}
### Set up weekly revenue drivers
In the Data Library, create weekly drivers such as:
* `Weekly Covers - Venue City Centre`
* `Average Spend per Cover - Weekly`
* `Weekly Delivery Orders`
* `Average Spend per Delivery Order`
If you have historical weekly data from POS exports, import it as CSV and tag each series clearly.
Define Revenue variables per venue and stream, for example:
* `Revenue - Food - Weekly`
* `Revenue - Beverage - Weekly`
* `Revenue - Delivery - Weekly`
Example formulas:
* `Revenue = Weekly Covers ร Average Spend per Cover`
* `Delivery Revenue = Weekly Delivery Orders ร Average Delivery Spend`
You can incorporate seasonality and events by adjusting weekly drivers over time.
{% endstep %}
{% step %}
### Model weekly COGS and purchasing
For consumables and ingredients, create COGS variables with occurrence and timing that reflect:
* When goods are consumed (COGS occurrence).
* When suppliers are paid (delay).
Examples:
* Occurrence pattern based on weekly revenue and expected gross margin.
* Delay representing supplier terms, for example 14 to 30 days.
If you plan pre-season or bulk purchases, use additional Asset or COGS style variables to represent those purchases in specific weeks and adjust working capital behaviour manually (this is an approximation).
{% endstep %}
{% step %}
### Model weekly staff and roster costs
Use Staff variables for roles such as:
* Front of house
* Back of house
* Bar staff
* Managers and supervisors
Drivers:
* Weekly hours per role
* Hourly wage rates
* Oncosts such as superannuation
Timing:
* Payroll cycles and delays between end of working week and cash payment
This will generate weekly staff costs in P\&L and corresponding cash outflows in Cashflow, with payables in between if applicable.
For roster design ideas, see Retail Workforce and Roster Forecasting (applies analogously to hospitality).
{% endstep %}
{% step %}
### Represent other weekly costs
Add Opex variables that occur weekly, fortnightly or monthly, including:
* Weekly or fortnightly rent payments if applicable
* Weekly marketing spend
* Utilities and other overheads, usually with monthly billing but weekly accrual
* Debt service where relevant
Use timing settings and delays to match reality, for example:
* Rent paid weekly on a regular day
* Utilities accrued weekly but paid monthly
Model Reef will still work at weekly resolution even if some items occur on slower cycles.
{% endstep %}
{% step %}
### Configure cashflow views and alerts
With drivers and variables in place, use:
* The Cashflow Statement to see weekly net cash movement.
* The Cash Waterfall to understand how revenue, COGS, staff, Opex, tax and funding combine to create cash movements.
Build a dashboard that shows:
* Weekly opening and closing cash
* Minimum expected cash balance over the horizon
* Weeks where cash is projected to fall below thresholds
* Contributions by category to cash movements
This can serve as an early warning system for funding gaps and help prioritise actions such as reducing costs, changing rosters or negotiating terms.
{% endstep %}
{% step %}
### Use scenarios for stress testing
Clone the weekly model into separate models for:
* Base trading expectations
* Downside scenarios (lower covers, higher cancellations)
* Upside scenarios (higher volumes, price changes)
For each scenario, compare:
* Weekly cash positions and minimum balances
* Timing and size of any funding gaps
* Sensitivity of cash to changes in revenue and labour
Because scenarios are separate models, you can change assumptions freely without risking the base plan.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
### Check your work
* Weekly revenue and cost patterns approximate actual trading behaviour.
* Supplier and payroll timing assumptions match real payment cycles.
* Cash balance movements look plausible compared to prior actuals where available.
* The model is understandable by non-modellers who rely on it for operational decisions.
{% endhint %}
## Troubleshooting
Weekly model feels heavy to maintain
Focus detailed weekly assumptions on the next 3 to 6 months and use smoother patterns for later periods.
Cash swings look exaggerated
Check for one-off spikes caused by incorrect timing or double counting of costs, and verify COGS and staff drivers.
Stakeholders find weekly charts overwhelming
Provide both weekly and monthly aggregated views so they can zoom in when needed but still see the bigger picture.
## Related guides
* [Build a Relative Valuation Using Fundamentals](/how-tos/valuation/build-a-relative-valuation-using-fundamentals)
* [Build a Rolling Forecast](/how-tos/scenarios-and-planning/build-a-rolling-forecast)
* [Cash Priority Rules](/help/financial-outputs-and-valuation/cash-priority-rules)
* [Editing Frequency](/syntax/how-input-fields-work/editing-frequency)
# ๐งโ๐ผ Professional Services & Consulting
# Utilisation & Capacity Planning
This use case explains how to use Model Reef to plan utilisation and capacity for professional services and consulting businesses.
You will:
* Model headcount and roles across offices or teams.
* Convert FTE capacity into available and billable hours.
* Apply utilisation and realisation assumptions.
* Connect supply of billable hours to revenue, margins and hiring plans.
The aim is to move away from static spreadsheets and build a capacity engine that is directly tied into your three statement model.
***
## When to use this pattern
Use this pattern when:
* You run or advise a consulting, agency or professional services firm.
* Utilisation is a key driver of revenue and margin.
* You want to understand when to hire, and how many people you need, to support planned work.
* You need to see the impact of utilisation changes on P and L and cash.
It is often combined with:
* **Rate Card and Billable Hours Forecasting**
* **Project Pipeline and Revenue Scheduling**
* **Office or Team Profitability Modelling**
***
## Architecture overview
You will build four layers:
{% stepper %}
{% step %}
### Branch structure
* Branches for offices, teams or service lines.
* Optional group or holding branch.
{% endstep %}
{% step %}
### Capacity drivers
* FTE by role.
* Available hours per FTE.
* Utilisation and realisation assumptions.
{% endstep %}
{% step %}
### Revenue variables
* Billable hours by role.
* Revenue as billable hours times rate card.
{% endstep %}
{% step %}
### Outputs
* Utilisation and capacity KPIs.
* Office or team P and L.
* Impact on margin and hiring needs.
{% endstep %}
{% endstepper %}
***
## Step 1: Design the branch structure for your firm
Start by deciding how you want to see performance:
* By office or city.
* By practice or service line.
* By team or squad.
In Model Reef, create a branch tree such as:
* `Firm` (root).
* `Practice - Strategy`.
* `Practice - Technology`.
* `Practice - Implementation`.
* `Overheads` (for central costs).
Or, for geographic focus:
* `Firm`.
* `Office - London`.
* `Office - Manchester`.
* `Office - Remote`.
* `Overheads`.
This branch structure will drive how you see utilisation and profitability.
***
## Capacity & utilisation build steps
{% stepper %}
{% step %}
### Define headcount and capacity drivers
In the Data Library, create drivers for headcount and capacity, for example:
* `FTE - Consultant - London`.
* `FTE - Senior Consultant - London`.
* `FTE - Partner - Firm`.
* `Available Hours per FTE per Year` or per period.
You can choose to work in:
* Hours per week and number of weeks per year, or
* Hours per month or quarter directly.
For example:
* `Available Hours per FTE per Week = 40`.
* `Working Weeks per Year = 46`.
* `Available Annual Hours = 40 ร 46`.
You may prefer to work with capacity modules per branch, storing all the assumptions for that branch in a small group of drivers.
{% endstep %}
{% step %}
### Add utilisation and realisation assumptions
Define the following drivers per role or per branch:
* Target utilisation percentage (share of available hours that are billable).
* Realisation percentage (share of billable hours that can actually be billed at full rate, after write offs and discounts).
Examples:
* `Utilisation - Consultant - London = 75 percent`.
* `Utilisation - Senior Consultant - London = 80 percent`.
* `Realisation - Firm = 95 percent`.
Store these as Modifier type drivers in the Data Library so they can be reused in formulas and easily updated.
{% endstep %}
{% step %}
### Convert capacity into billable hours and revenue
In each office or practice branch, create variables to compute:
* Available hours per role.
* Billable hours per role.
* Billable hours after realisation.
For example:
* `Available Hours - Consultant - London = FTE - Consultant - London ร Available Hours per FTE`.
* `Billable Hours - Consultant - London = Available Hours - Consultant - London ร Utilisation - Consultant - London`.
* `Billable Hours Realised - Consultant - London = Billable Hours ร Realisation`.
Then link to rate card drivers (described in more detail in **Rate Card and Billable Hours Forecasting**), for example:
* `Revenue - Consultant - London = Billable Hours Realised ร Rate - Consultant - London`.
Set these revenue variables as type **Revenue** so they flow into P and L and cash correctly.
{% endstep %}
{% step %}
### Compare capacity to demand
If you implement **Project Pipeline and Revenue Scheduling**, you will have a view of demand for billable hours over time.
You can then compare:
* Supply of billable hours (from this utilisation and capacity structure).
* Demand for billable hours (from pipeline and project schedules).
Use charts or custom reports to show:
* Excess capacity or shortfalls per office or role over time.
* Expected utilisation compared to target.
This helps answer questions such as:
* When do we need to hire more people in a team or location.
* Where are we likely to be overstaffed if pipeline slows.
{% endstep %}
{% step %}
### Connect to staff cost and P and L
Make sure Staff variables exist for all roles in each branch, representing:
* Salaries or day rates for employees and contractors.
* Oncosts such as pensions and payroll tax.
Then check that:
* Revenue variables from billable hours and rate card are in the same branch as staff costs.
* Office or practice P and L shows revenue minus staff and Opex clearly.
This gives you a utilisation driven margin view at office or practice level.
{% endstep %}
{% step %}
### Build utilisation and capacity dashboards
Create a dashboard focused on utilisation and capacity that shows:
* FTE counts per role and branch.
* Available hours, billable hours and realised billable hours over time.
* Utilisation percentages per role and per office.
* Revenue per FTE and gross margin per FTE.
These views give partners and managers a clear line of sight from staffing to revenue and margin.
{% endstep %}
{% endstepper %}
***
## Check your work
{% hint style="info" %}
* FTE and hours assumptions are realistic and grounded in actual contracts and work patterns.
* Utilisation and realisation percentages are plausible given historical performance.
* Revenue per role and branch aligns with what you would expect from the rate card.
* Office or practice P and Ls reconcile to the consolidated firm view.
{% endhint %}
***
## Troubleshooting
{% hint style="warning" %}
Utilisation looks too high across the board โ Check that you have not confused billable hours with available hours, and that holidays and non-billable time are correctly reflected in the capacity assumptions.
{% endhint %}
{% hint style="warning" %}
Revenue jumps or dips unexpectedly โ Look for step changes in FTE drivers or utilisation assumptions, and align them with known hiring or restructuring events.
{% endhint %}
{% hint style="info" %}
Too many roles make the model hard to manage โ Group similar roles into bands for planning (for example junior, mid, senior) and track very granular titles only in HR systems.
{% endhint %}
***
## Related guides
* [Build an Opex Planning Model](/how-tos/operations-and-unit-economics/build-an-opex-planning-model)
* [Scenarios & Planning](/how-tos/scenarios-and-planning)
* [COGS Variables: what is, rules, what it affects](/help/drivers-variables-and-timing/cogs-variables)
* [Entering Accruals & Delays](/syntax/how-input-fields-work/entering-accruals-and-delays)
# Rate Card & Billable Hours Forecasting
This use case explains how to build a rate card and billable hours forecasting engine for professional services and consulting firms in Model Reef.
You will:
* Define rate cards by role, grade, office or practice.
* Forecast billable hours per role and location.
* Use those hours and rates to drive revenue.
* Integrate the result with utilisation and capacity planning, and with project pipeline schedules.
## When to use this pattern
Use this pattern when:
* Your revenue is driven by billable time and rates.
* You need to test changes in rates, discounting or mix.
* You want revenue forecasts to derive from headcount, utilisation and rate cards rather than top down assumptions.
It pairs naturally with:
* **Utilisation and Capacity Planning**
* **Project Pipeline and Revenue Scheduling**
* **Office or Team Profitability Modelling**
## Architecture overview
You will build three main elements:
* Rate card drivers
* Rates per role, grade, office or service line.
* Optional different rates per client type or channel.
* Billable hours drivers and variables
* Billable hours based on FTE, utilisation and realisation.
* Optional adjustments from project pipeline schedules.
* Revenue variables and outputs
* Revenue per role and branch.
* Aggregated firm revenue and margin.
{% stepper %}
{% step %}
### Decide rate card dimensions
First decide how granular your rate card needs to be, for example:
* Role based only:
* Consultant, Senior Consultant, Manager, Director, Partner.
* Role and office:
* Consultant - London vs Consultant - Manchester.
* Role and service line:
* Strategy Consultant vs Technology Consultant.
More granular rate cards give more detail but require more maintenance. Choose the smallest set of dimensions that meaningfully affect pricing decisions.
{% endstep %}
{% step %}
### Create rate card drivers
In the Data Library, create drivers for rates, for example:
* `Rate - Consultant - London`.
* `Rate - Senior Consultant - London`.
* `Rate - Manager - London`.
* `Rate - Consultant - Manchester`.
These should be periodic series so you can represent planned rate increases over time, for example:
* Annual increases each financial year.
* Step changes to reflect a strategic shift in pricing.
You can use manual, regression or ML based presets if you want rate changes to follow a pattern, but in many cases manual edits are sufficient.
{% endstep %}
{% step %}
### Build billable hours from capacity and utilisation
Reuse or create drivers for:
* FTE per role and branch.
* Available hours per FTE.
* Utilisation percentages.
* Realisation percentages.
Then, in each branch, define variables such as:
* `Available Hours - Consultant - London`.
* `Billable Hours - Consultant - London`.
* `Realised Billable Hours - Consultant - London`.
For example:
* Available hours = FTE ร available hours per FTE.
* Billable hours = available hours ร utilisation.
* Realised billable hours = billable hours ร realisation.
These variables can either be stand alone or integrated directly into the utilisation and capacity structure.
{% endstep %}
{% step %}
### Create revenue variables per role and branch
For each role and branch, define Revenue variables such as:
* `Revenue - Consultant - London`.
* `Revenue - Senior Consultant - London`.
* `Revenue - Manager - Manchester`.
Set the formula to:
* Revenue = realised billable hours ร relevant rate driver.
Ensure these variables are typed as **Revenue** so they feed P\&L, Cashflow and Cash Waterfall.
You may also add summarising revenue variables by practice, office or service line that sum multiple role level variables for reporting.
{% endstep %}
{% step %}
### Adjust for discounts and different client types
If you have materially different rates or discounts by client type or channel, you can model this by either:
* Creating separate rate drivers and revenue variables per client segment, for example:
* `Rate - Consultant - London - Enterprise`.
* `Rate - Consultant - London - SME`.
* Or using discount drivers that modify the base rate, for example:
* `Effective Rate = Base Rate ร (1 minus Discount Percentage)`.
Keep segment definitions as simple as possible to avoid a proliferation of variables.
{% endstep %}
{% step %}
### Integrate project pipeline and scheduling
To tie revenue more directly to work in the pipeline, you can connect billable hours to project schedules by:
* Using Pipeline drivers for expected hours per project and period.
* Allocating those hours to roles and branches.
* Ensuring that allocated hours reconcile with total billable hours capacity.
This approach is described in more detail in **Project Pipeline and Revenue Scheduling** and will allow you to check that the combination of rate card, hours and pipeline assumptions are consistent.
{% endstep %}
{% step %}
### Build rate and revenue dashboards
Create a dashboard that shows:
* Rate per role and office over time.
* Total billable and realised hours per role and branch.
* Revenue per role, office and practice.
* Revenue per FTE or per billable hour as key KPIs.
Use this dashboard to answer questions like:
* What happens to revenue if we increase rates by a certain percentage.
* How much of revenue growth comes from increased rates versus increased hours or headcount.
* How does rate and mix differ between offices or service lines.
{% endstep %}
{% endstepper %}
## Check your work
* Rate drivers match actual or planned rate cards used by the firm.
* Billable hours calculations align with utilisation expectations and past performance.
* Revenue per branch and role looks sensible when compared to historical data where available.
* Rate changes and hiring plans produce revenue patterns that match your expectations.
## Troubleshooting
Revenue jumps unexpectedly when rates change
Confirm that rate changes are scheduled correctly and that there are no overlapping or duplicated rate drivers.
Too many rate combinations create complexity
Rationalise the rate card to a smaller number of bands and only use detailed exceptions where they really matter.
Difficult to reconcile to time and billing systems
Use exports from those systems to calibrate your hours and realisation assumptions, but keep the planning model focused on drivers and aggregates rather than transactional detail.
## Related guides
* [Build a Synergy & Integration Model](/how-tos/investment-and-transactions/build-a-synergy-and-integration-model)
* [Build a Terminal Value Model](/how-tos/valuation/build-a-terminal-value-model)
* [Discount Rate Modifiers](/help/financial-outputs-and-valuation/discount-rate-modifiers)
* [Entering Delays](/syntax/timing-syntax/entering-delays)
# Project Pipeline & Revenue Scheduling
This use case explains how to represent a project pipeline and revenue scheduling for consulting and professional services firms using Model Reef.
You will:
* Capture the project pipeline as a series of engagements with fees, start dates and durations.
* Apply probabilities and win rates.
* Schedule revenue over time based on work patterns or milestones.
* Connect pipeline output to utilisation, capacity and cashflow.
## When to use this pattern
Use this pattern when:
* You win work through discrete projects or engagements.
* You want a forward view of revenue based on actual pipeline, not just run rate assumptions.
* You need to see how pipeline supports or falls short of capacity and headcount plans.
It is closely linked to:
* **Utilisation and Capacity Planning**
* **Rate Card and Billable Hours Forecasting**
* **Office or Team Profitability Modelling**
## Architecture overview
The pipeline modelling structure has three components:
1. **Project definitions**
* One set of drivers or variables per project or per project group.
* Fee, start date, duration, probability.
2. **Revenue scheduling rules**
* How fees convert into revenue by period (time and materials, fixed fee, milestones).
* How probabilities are applied (weighted pipeline versus committed work).
3. **Outputs**
* Pipeline based revenue series by office, practice and role.
* Comparison of pipeline revenue to capacity based revenue.
* Views for base, upside and downside scenarios.
***
{% stepper %}
{% step %}
### Step 1: Represent projects in the Data Library
Decide how granular your project list should be in the model:
* One entry per major project.
* One entry per client or per programme of work.
* Aggregated entries for many small jobs by type.
In the Data Library, create entries for each project or project group with fields such as:
* `Total Fee`.
* `Expected Start Date`.
* `Duration in Months or Weeks`.
* `Probability of Win` for pipeline stages.
* `Office` or `Practice` if you want branch level mapping.
You can maintain this list directly in Model Reef or import regularly from a CRM or sales system as a CSV.
{% endstep %}
{% step %}
### Step 2: Define revenue scheduling patterns
For each project, decide how fees will be recognised over time. Common patterns:
* **Time and materials**
* Revenue follows hours staffed and rates.
* Can be approximated as evenly spread over expected duration if detail is not required.
* **Fixed fee straight line**
* Equal revenue each period over the project duration.
* **Milestone based**
* Revenue recognised at defined milestones and dates.
In Model Reef, you can represent these patterns by:
* Using schedule style drivers for each project.
* Or using formulas that map total fee into a series over the chosen periods.
Document the rule for each project in notes so that it is clear how revenue scheduling is being applied.
{% endstep %}
{% step %}
### Step 3: Apply probabilities and build weighted pipeline
For pipeline stages that are not yet won, you can compute a weighted pipeline by:
* Weighted Fee = Total Fee ร Probability of Win.
* Weighted Revenue Series = Scheduled Revenue Series ร Probability of Win.
Implement this by either:
* Applying the probability directly in the formula that generates revenue.
* Or storing both unweighted and weighted series separately for reporting.
This allows you to see both committed work (probability near 100 percent) and earlier stage pipeline in the same structure.
{% endstep %}
{% step %}
### Step 4: Map projects into branches and roles
Use branches to reflect where work is delivered, for example by office or practice.
For each project:
* Assign the relevant branch.
* Optionally, break the project into components by role or team if you need role level revenue.
Create Revenue variables such as:
* `Revenue - Project Alpha - Strategy Practice`.
* `Revenue - Project Alpha - Technology Practice`.
These variables will reference the scheduled revenue series for that project. Because they are type **Revenue**, they feed P\&L and cashflow automatically.
{% endstep %}
{% step %}
### Step 5: Link pipeline to capacity and utilisation
Once pipeline based revenue is in place, compare it to your capacity based revenue expectations from **Rate Card and Billable Hours Forecasting** and **Utilisation and Capacity Planning**.
Use dashboards or reports to show:
* Pipeline derived revenue per branch and period.
* Capacity derived revenue per branch and period.
* Gaps where pipeline is insufficient to hit revenue targets or keep staff productively utilised.
* Overloads where pipeline implies more work than you can deliver with planned headcount.
This comparison provides an early warning for hiring, marketing and sales planning.
{% endstep %}
{% step %}
### Step 6: Build pipeline and scheduling dashboards
Create a **Pipeline and Revenue** dashboard that includes:
* Weighted pipeline by month or quarter.
* Committed work versus early stage opportunities.
* Revenue by project, office or practice.
* Funnel style views summarising total fee and weighted fee by stage.
If you maintain separate models for different scenarios, you can compare:
* Base pipeline.
* Optimistic or upside pipeline.
* Downside or conservative pipeline.
{% endstep %}
{% step %}
### Step 7: Maintain the pipeline over time
To keep the pipeline model useful:
* Update project inputs regularly from your CRM or sales pipeline tool.
* Move projects between stages and adjust probabilities.
* Close won projects and convert them to committed work with probability 100 percent.
* Archive lost or completed projects when no longer needed for planning.
You can either edit Data Library entries directly or replace them via periodic imports from external systems.
{% endstep %}
{% endstepper %}
***
Check your work
* The list of projects in the model reasonably matches the current live pipeline.
* Scheduling patterns reflect how work is actually delivered and invoiced.
* Weighted pipeline values are plausible when compared to typical win rates.
* Pipeline based revenue and capacity based revenue tell a coherent story.
Troubleshooting
* **Pipeline appears far larger than capacity**\
Confirm that probabilities are realistic and that projects are not double counted across segments or branches.
* **Revenue seems misaligned with invoicing patterns**\
Refine scheduling rules for large or unusual projects to better match expected billing and recognition.
* **Keeping the pipeline data up to date feels manual**\
Automate as much as possible using CSV exports from CRM systems and a regular import routine.
***
## Related guides
* [Build a Top Down Forecast](/how-tos/core-modelling/build-a-top-down-forecast)
* [Build a Unified Forecast from Multiple Inputs](/how-tos/core-modelling/build-a-unified-forecast-from-multiple-inputs)
* [Revenue Mapping](/help/financial-outputs-and-valuation/revenue-mapping)
* [Entering Schedules](/syntax/how-input-fields-work/entering-schedules)
# Office/Team Profitability Modelling
This use case describes how to model profitability by office, practice or team in a professional services or consulting firm using Model Reef.
You will:
* Use branches to represent organisational units such as offices, practices or teams.
* Map revenue, staff and Opex into the right branches.
* Allocate shared or central costs.
* Produce P\&Ls and KPIs at both office or team level and firm level.
***
## When to use this pattern
Use this pattern when:
* You want to understand profitability at office, practice or team level.
* You need to allocate shared overheads such as head office costs to those units.
* You want decision makers to be accountable for local performance while seeing the impact of central costs.
This pattern assumes you have already set up rate card, utilisation and pipeline structures that determine revenue.
***
## Architecture overview
{% stepper %}
{% step %}
### Branch structure
* One branch per office, practice or team.
* One or more branches for central or overhead functions.
{% endstep %}
{% step %}
### Direct revenue and costs
* Revenue, staff and direct Opex mapped to their owning branch.
* Expenses that clearly belong to a specific office or team kept local.
{% endstep %}
{% step %}
### Shared cost allocation
* Central costs grouped in an overhead branch.
* Drivers used to allocate those costs back to offices or teams for a fully loaded view.
{% endstep %}
{% step %}
### Reporting
* Office or team P\&L views.
* Consolidated firm view.
* Comparison dashboards across units.
{% endstep %}
{% endstepper %}
***
{% stepper %}
{% step %}
### Define the organisational units you want to track
Decide what you want to treat as a unit for profitability analysis, for example:
* Offices or geographies.
* Practices or service lines.
* Named teams or squads.
In many firms, a two dimensional view is helpful, such as offices by practice. For modelling purposes, choose one dimension as the primary branch structure and keep the other as a reporting attribute if needed.
In Model Reef, create a branch tree such as:
* `Firm`.
* `Office - London`.
* `Office - Manchester`.
* `Office - Remote`.
* `Overheads`.
Or, for practice first:
* `Firm`.
* `Practice - Strategy`.
* `Practice - Technology`.
* `Practice - Implementation`.
* `Overheads`.
{% endstep %}
{% step %}
### Map revenue to offices or teams
Ensure that Revenue variables are attached to the branch that actually delivers or owns the work, not just to a single firm level branch.
Depending on your modelling approach, you may:
* Create revenue variables per branch that link to billable hours and rates for that branch.
* Allocate a share of project or client level revenue to different branches based on delivery mix.
The objective is that each office or team branch has a realistic share of revenue that reflects their contribution.
{% endstep %}
{% step %}
### Map staff and direct costs to offices or teams
Next, ensure that:
* Staff variables (salaries, benefits, payroll tax) are assigned to the branch where people sit or where their costs are managed.
* Direct Opex such as local office rent, local travel, local marketing and team expenses are also placed in the relevant branch.
Patterns:
* `Staff - Consultant - London` in `Office - London`.
* `Opex - Office Rent - London` in `Office - London`.
* `Staff - Support Team - Firm` in `Overheads` if they serve the entire firm.
This separation of direct and central costs is critical for clear profitability analysis.
{% endstep %}
{% step %}
### Group central and shared costs
Create an `Overheads` or `Central` branch for costs that support the whole firm, such as:
* Executive leadership.
* Finance, HR and internal IT.
* Central marketing.
* Firm wide systems and licences.
* Office of the managing partner.
Model these as Staff and Opex variables in the `Overheads` branch.
Firm level P\&L at the root branch will include all branches, including Overheads, by default.
{% endstep %}
{% step %}
### Design allocation logic for shared costs
If you want to see fully loaded profitability per office or team, design allocation drivers for central costs, for example:
* Revenue share.
* Gross margin share.
* Headcount share.
* Some hybrid of the above.
In the Data Library, create drivers such as:
* `Allocation Key - Revenue Share - London`.
* `Allocation Key - Revenue Share - Manchester`.
These should sum to 100 percent across the target branches for each allocation scheme.
Then, in each office or team branch, create Opex variables such as:
* `Allocated Overheads - London`.
* `Allocated Overheads - Manchester`.
Define formulas that:
* Take total central costs from the `Overheads` branch.
* Multiply by the allocation key for each branch.
You can choose to leave central costs in the `Overheads` branch as well (for reconciliation) or show them only via allocations in profitability views, depending on communication needs.
For the mechanics of cross branch references, see **Build Cross Branch Drivers and Dependencies**.
{% endstep %}
{% step %}
### Build office or team P\&L views
Use reports and dashboards to provide:
* P\&L per office or team showing:
* Revenue.
* Direct staff and Opex.
* Allocated overheads.
* Operating contribution and fully loaded profit.
* Consolidated firm P\&L at the root branch.
You can add KPIs such as:
* Revenue per FTE.
* Contribution margin per office.
* Profit per partner or per manager.
Present pre allocation and post allocation views so that managers can see both raw and fully loaded performance.
{% endstep %}
{% step %}
### Use scenarios for structural changes
To test structural changes such as office openings, closures or team restructures:
* Clone the base model into scenario models representing different structures.
* Adjust branch structures, allocation drivers and staff assignments.
* Compare office and firm level profitability across scenarios.
This lets you evaluate the impact of:
* Consolidating small offices.
* Investing in new practices.
* Moving roles between locations.
Because scenarios are separate models, you can explore substantial changes without affecting the live plan.
{% endstep %}
{% endstepper %}
***
## Check your work
{% hint style="info" %}
* Revenue, staff and Opex are mapped to branches that match how the firm is actually run.
* Central costs in the `Overheads` branch are complete and not duplicated in local branches.
* Allocation drivers are clearly defined and documented so stakeholders understand how overheads are spread.
* Office or team P\&Ls reconcile to firm level P\&L.
{% endhint %}
***
## Troubleshooting
Units complain about overhead allocations
Present both pre allocation and post allocation results and be transparent about the allocation rules and rationale.
Results jump when organisational changes occur
Carefully track branch structure changes and staff moves between branches, and annotate major changes in notes or tags.
Difficulty reconciling to ledger based reports
Ensure source data imports align with branch and category mapping, and that central versus local costs are categorised consistently in the ledger.
***
## Related guides
* [Build a Unit Economics Model](/how-tos/operations-and-unit-economics/build-a-unit-economics-model)
* [Build a Valuation Sensitivity Model](/how-tos/valuation/build-a-valuation-sensitivity-model)
* [CSV Import](/help/importing-and-data-inputs/csv-import)
* [Entering Seasonality](/syntax/how-input-fields-work/entering-seasonality)
# ๐๏ธ Construction & Contracting
# Project Cash Flow (Milestones)
This use case explains how to model project cashflow for construction and contracting businesses using milestone based billing and cost recognition in Model Reef.
You will use:
* Branches to represent projects or sites.
* Revenue variables tied to milestones and claims.
* Cost variables tied to procurement, labour and subcontractors.
* Timing rules for retentions, variations and payment terms.
The aim is to produce a clear view of project level and group level cashflows aligned to how contracts are actually billed and paid.
## When to use this pattern
Use this pattern when:
* You project revenue based on milestones, claims, certificates or stages.
* You want to understand cash in and cash out by project, not just at group level.
* You need to plan funding for a project portfolio and understand timing of cash crunches.
If you also want to forecast work in progress and cost to complete, combine this with **WIP and Cost-to-Complete Forecasting**.
## Architecture overview
You will build four layers:
{% stepper %}
{% step %}
### Branch structure
* One branch per project or site.
* Optional parent branch for regions or business units.
* A group branch for consolidated outputs.
{% endstep %}
{% step %}
### Contract and milestone drivers
* Contract value per project.
* Milestone schedule and percentage of contract.
* Retention percentages and release timing.
* Variation assumptions.
{% endstep %}
{% step %}
### Revenue and cash receipt variables
* Revenue recognition per milestone or over time.
* Cash receipts based on claim approval and debtor terms.
* Retention balances and release.
{% endstep %}
{% step %}
### Cost and cash outflow variables
* Direct costs for labour, subcontractors, materials and plant.
* Timing of payments based on supplier and subcontractor terms.
{% endstep %}
{% endstepper %}
All of this sits inside the standard three statement engine so P\&L, Balance Sheet, Cashflow Statement and Cash Waterfall remain consistent.
***
{% stepper %}
{% step %}
### Set up branches for projects
Create a model where each project is a branch, for example:
* `Group`
* `Project - Hospital Extension`
* `Project - School Refurbishment`
* `Project - Retail Fitout`
* `Overheads`
If you have many projects, group them under regional or business unit branches, such as `Region North`, `Region South`, so reporting remains manageable.
Each project branch will hold only that projectโs revenue and costs.
{% endstep %}
{% step %}
### Capture contract value and milestone structure
In the Data Library, create drivers per project for:
* `Contract Value - Project X`.
* Milestone percentages, for example:
* `Milestone 1 Percentage`
* `Milestone 2 Percentage`
* `Practical Completion Percentage`
* `Retention Percentage`.
For each project, also specify:
* Expected milestone dates or periods.
* Retention release timing, for example:
* Fifty percent at practical completion.
* Fifty percent at the end of the defects liability period.
If you prefer, you can maintain milestone tables in a spreadsheet and import them as drivers for value by period per project.
{% endstep %}
{% step %}
### Build revenue and claim variables
In each project branch, create Revenue variables that represent claimable revenue per milestone or per period, for example:
* `Revenue - Milestone Claims - Project X`.
* `Revenue - Variations - Project X`.
Options for recognition:
* Straight line over the expected project duration.
* Milestone based, where revenue is recognised when milestones are reached.
* A combination of the two if you want to approximate percentage of completion.
Decide whether you want revenue in the model to match accounting recognition or claim timing. For planning, many teams use claim timing, treating each approved claim as both revenue and debtor creation.
Make sure all revenue variables are of type **Revenue** so they feed P\&L correctly.
{% endstep %}
{% step %}
### Model debtor timing and retentions
Use timing and delay rules on revenue variables to reflect:
* Typical debtor terms after a claim is approved, for example 30, 45 or 60 days.
* Partial payments where retentions are held back.
Implementation patterns:
* Split revenue into two variables:
* `Revenue - Claims Payable` (portion not retained).
* `Revenue - Retentions`.
* Apply different delays:
* Shorter delay for normal claims.
* Much longer delay for retentions (for example months after completion).
Alternatively, use a single revenue variable and adjust timing with custom drivers that approximate retention behaviour.
The effect should be that:
* P\&L shows revenue when work is done or claims are approved.
* Balance Sheet shows debtors and retention receivable.
* Cashflow shows receipts when payments are expected.
{% endstep %}
{% step %}
### Model project cost timing
Within each project branch, create cost variables for:
* Materials and procurement.
* Labour (site staff and supervision).
* Subcontractors.
* Plant, equipment and hire.
* Site overheads.
Use:
* COGS type variables for direct project costs.
* Staff variables for employed labour.
* Opex variables for project overheads.
For each, define:
* Occurrence pattern (when costs are incurred).
* Delay or payment terms (for example 30 days for suppliers, 14 days for subcontractors).
This will create Creditors and subcontractor payables in the Balance Sheet and show cash outflows in the Cashflow Statement and Cash Waterfall.
{% endstep %}
{% step %}
### Add variations and risk allowances
Construction projects frequently change scope. For each project, consider:
* Variation drivers, for example `Variation Percentage of Contract Value` or explicit variation amounts.
* Risk allowances, such as contingency percentages on labour or materials.
Implement variations as additional Revenue and COGS variables:
* `Revenue - Variations - Project X`.
* `COGS - Variations - Project X`.
You can tie these to scenario specific drivers so that different models represent base, upside and downside views of variation income and cost.
{% endstep %}
{% step %}
### Build project and portfolio cash views
With revenue and costs wired up per project, create:
* Project level P\&L, Cashflow and Cash Waterfall views.
* A portfolio dashboard showing:
* Cash in and out per project over time.
* Net cash position by project.
* Total portfolio cashflow per period.
* Retention build up and release over the horizon.
Use this to identify:
* Projects that cause large temporary cash deficits.
* Timing of funding requirements at portfolio level.
* Sensitivity of cash to delays in claims or payments.
{% endstep %}
{% endstepper %}
***
{% hint style="info" %}
### Check your work
* Contract values and milestone percentages sum correctly to total project value.
* Retention assumptions match actual contract terms.
* Cost timing approximates procurement, labour and subcontractor payment cycles.
* Project level and group cashflows look plausible when compared with known project histories.
{% endhint %}
***
## Troubleshooting
Cash receipts lag reality by too much or too little
Refine debtor delay settings and retention release assumptions, and treat claims and approvals separately if needed.
Project cash results do not reconcile to historicals
Start by calibrating one completed project to ensure your patterns match reality, then apply the same patterns to new projects.
Portfolio view is hard to interpret with many projects
Group smaller projects into aggregated branches and keep detailed modelling only for the largest or riskiest ones.
***
## Related guides
* [Build an Equity Valuation Model](/how-tos/valuation/build-an-equity-valuation-model-fcfe)
* [Build an Executive Dashboard](/how-tos/dashboards-and-reporting/build-an-executive-dashboard)
* [Categories](/help/building-your-model/categories)
* [Formula Editor Layout](/syntax/formula-syntax/formula-editor-layout)
# WIP & Cost-to-Complete Forecasting
This use case explains how to approximate work in progress (WIP) and cost to complete for construction and contracting projects using Model Reef.
Model Reef does not implement full accounting treatment of construction contracts. Instead, you can create planning level WIP and cost to complete structures that:
* Use project level contract, cost and progress drivers.
* Estimate remaining cost and margin.
* Show how much work and cost is ahead or behind plan.
The goal is to support project and portfolio management decisions, not to replace your official WIP accounting system.
## When to use this pattern
Use this pattern when:
* You manage multiple long running construction or contracting projects.
* You need forward visibility on cost to complete and margin, per project and in aggregate.
* You want to test scenarios such as cost overruns, delays or scope changes.
Combine this with:
* **Project Cash Flow (Milestones)** for cash timing.
* **Multi-Project Consolidated Model** for portfolio views.
## Architecture overview
You will build:
{% stepper %}
{% step %}
### Project level drivers
* Contract value.
* Original budgeted cost.
* Current forecast cost.
* Measured progress percentage.
{% endstep %}
{% step %}
### Derived WIP metrics
* Earned value (value of work performed).
* Cost to complete.
* Forecast final margin and margin percentage.
{% endstep %}
{% step %}
### Variables and outputs
* Project level WIP and cost to complete series.
* Portfolio dashboards showing risk and margin.
{% endstep %}
{% endstepper %}
***
{% hint style="info" %}
The following steps show a practical sequence to implement the above architecture in Model Reef.
{% endhint %}
{% stepper %}
{% step %}
### Step: Capture project level contract and cost baselines
In the Data Library, define entries per project for:
* `Contract Value - Project X`.
* `Original Budgeted Cost - Project X`.
* `Current Forecast Cost - Project X`.
These can be imported from your project costing system or maintained directly in Model Reef.
Optionally, include:
* `Approved Variations - Project X`.
* `Provisional Sums - Project X`.
* `Contingency Allowance - Project X`.
This provides a baseline for measuring performance and risk.
{% endstep %}
{% step %}
### Step: Define progress measures
Decide how you want to measure progress per project, for example:
* Percentage complete based on quantity surveys.
* Percentage complete based on cost incurred relative to forecast cost.
* Milestone completions mapped to percentage complete.
In the Data Library, create a progress driver per project, for example:
* `Progress Percentage - Project X`.
Update this by period based on site reporting or cost data.
{% endstep %}
{% step %}
### Step: Compute earned value and WIP
Use variables in each project branch to compute:
* `Earned Value = Contract Value ร Progress Percentage`.
* `Cost Incurred to Date` based on accumulated actual costs in the model.
* `WIP Position = Earned Value minus Cost Incurred to Date`.
Interpretation:
* Positive WIP may indicate you are ahead on margin recognition relative to cost.
* Negative WIP may indicate you are behind or have under recognised revenue relative to cost.
For planning purposes, treat WIP as an analytical metric rather than implementing detailed WIP journal entries.
{% endstep %}
{% step %}
### Step: Estimate cost to complete
Estimate cost to complete using:
* `Cost to Complete = Current Forecast Cost minus Cost Incurred to Date`.
You can create a Cost variable such as `Cost to Complete - Project X` that represents the expected future costs over remaining periods, either by:
* Spreading cost to complete evenly over remaining duration, or
* Using a schedule based on planned activity and procurement.
These cost to complete variables should be set up as COGS or Opex, depending on how you represent project costs in your P\&L.
{% endstep %}
{% step %}
### Step: Forecast final margin and margin changes
From contract value and forecast cost, derive:
* `Forecast Final Margin = Contract Value minus Current Forecast Cost`.
* `Forecast Final Margin Percentage = Forecast Final Margin divided by Contract Value`.
Compare this to original margin to see:
* Margin erosion due to cost overruns.
* Margin improvement due to favourable variations or efficiencies.
Present these metrics per project in a dashboard or report, and highlight projects with significant margin changes.
{% endstep %}
{% step %}
### Step: Build portfolio level WIP and cost to complete views
Aggregate project level WIP and cost to complete metrics in the `Group` branch and create a dashboard that shows:
* Total cost to complete per period.
* Total expected margin remaining.
* Distribution of projects by margin risk (for example traffic light coding based on margin degradation).
* Projects with the largest cost to complete or margin at risk.
Use this to guide management focus towards high risk or high value projects.
{% endstep %}
{% step %}
### Step: Use scenarios for risk and overrun analysis
Clone your base model into scenario models that represent:
* Base case (current best forecast).
* Downside case (cost overruns, delay, lower recovery of variations).
* Upside case (better buying, improved productivity).
Adjust drivers for:
* Current forecast cost.
* Progress rates.
* Variations.
* Contingency use.
Compare cost to complete, WIP and final margin metrics between models to understand the sensitivity of the portfolio to key risk factors.
{% endstep %}
{% endstepper %}
## Check your work
* Contract values and cost baselines per project reconcile to your source systems.
* Progress percentages are reasonable and sourced from consistent field data.
* Cost to complete and forecast margins are in line with project manager expectations.
* Portfolio views align with known areas of risk and opportunity.
## Troubleshooting
WIP swings unexpectedly
Check for large jumps in progress percentage or cost incurred, and ensure variations and forecast cost updates are applied consistently.
Cost to complete appears negative
Confirm that current forecast cost is up to date and that cost incurred does not exceed forecast by mistake.
Difficult to match accounting WIP reports
Treat Model Reefโs WIP metrics as planning approximations and use them to inform discussion alongside, not instead of, formal accounting reports.
## Related guides
* [Build an LBO Model](/how-tos/investment-and-transactions/build-an-lbo-model)
* [Build an M\&A Consolidation Model](/how-tos/investment-and-transactions/build-an-m-and-a-consolidation-model)
* [Staff Cost Mapping](/help/financial-outputs-and-valuation/staff-cost-mapping)
* [Formula Modal](/syntax/understanding-the-interface/formula-modal)
# Multi-Project Consolidated Model
This use case shows how to build a consolidated model for multiple construction and contracting projects using Model Reef.
You will:
* Represent each project as its own branch.
* Combine project level revenue, cost and cashflow into a portfolio view.
* Include overheads and financing at group level.
* Use scenarios to test different combinations of project wins, delays and cancellations.
This structure replaces spreadsheet based consolidation and makes it easier to see the portfolio as a whole.
## When to use this pattern
Use this pattern when:
* You manage several concurrent projects or a rolling portfolio of contracts.
* You need to understand group cashflow, profit and funding needs across the portfolio.
* You want to test which projects to prioritise, defer or decline.
It assumes you have already built project level structures such as **Project Cash Flow (Milestones)** and optionally **WIP and Cost-to-Complete Forecasting**.
## Architecture overview
The multi project model consists of:
* Branch tree
* One branch per project.
* Optional grouping branches by region or business unit.
* A group branch for consolidated results.
* An overheads branch for central costs.
* Project level variables
* Revenue, COGS, labour, subcontractors and other direct costs.
* Project specific assets, financing and working capital.
* Group level variables
* Head office costs.
* Shared assets and debt.
* Equity injections and dividends.
* Portfolio outputs
* Group P\&L, Balance Sheet, Cashflow and Cash Waterfall.
* Portfolio dashboards and funding analysis.
{% stepper %}
{% step %}
### Build or import project level models
Start from a base model that contains a single project branch with:
* Contract and milestone drivers.
* Project level revenue and cost variables.
* Timing and cashflow behaviour configured.
Clone that branch for each active or planned project, adjusting drivers to match the specific contract. Alternatively, if you have separate models per project already, recreate them as branches in a new consolidated model using consistent structures.
You should end up with branches such as:
* `Group`
* `Project - Hospital Extension`
* `Project - School Refurbishment`
* `Project - Retail Fitout`
* `Overheads`
{% endstep %}
{% step %}
### Ensure consistent category and variable structures
For consolidation to be meaningful:
* Use the same category and subcategory layout for revenue and costs across projects.
* Use consistent naming and tagging conventions for variables, such as:
* `Revenue - Contract - Project Name`.
* `COGS - Materials - Project Name`.
* `Staff - Site Supervisors - Project Name`.
This allows reports and dashboards to aggregate and compare projects cleanly.
{% endstep %}
{% step %}
### Add overheads and financing at group level
In the `Overheads` or `Group` branch, create variables for:
* Head office salaries.
* Central administration and compliance.
* Group wide insurance and systems.
* Bank loans and group level financing.
* Equity injections and dividends if relevant.
These variables will not belong to any single project but will affect group P\&L and cashflow.
If you want to allocate overheads back to projects for fully loaded margin analysis, see **Office or Team Profitability Modelling** and **Build Cross Branch Drivers and Dependencies**.
{% endstep %}
{% step %}
### Consolidate project cashflows and profitability
Model Reef automatically aggregates variables from project branches into the `Group` branch. Use this to create:
* Group level P\&L showing total revenue and cost across all projects plus overheads.
* Group Cashflow Statement and Cash Waterfall showing total cash in and out.
* Portfolio profitability and margin metrics.
Build dashboards that show, for example:
* Revenue and margin by project and in total.
* Cashflow contributions by project.
* Top projects by revenue, margin, cash consumption or cash generation.
{% endstep %}
{% step %}
### Analyse portfolio funding requirements
Use group level cashflow outputs to determine:
* Peak cash deficit across the portfolio.
* Timing of funding requirements.
* Contributions from specific projects to cash strain.
You can then test different portfolio compositions by adjusting project assumptions, start dates or whether a project proceeds at all, and observing the effect on group funding needs.
If needed, add debt drawdown and repayment variables at group level to simulate funding solutions.
{% endstep %}
{% step %}
### Use scenarios for portfolio strategy
Because scenarios are implemented as separate models, you can create different portfolio strategies by cloning the consolidated model and altering:
* Which projects are included.
* Project start dates and durations.
* Win or loss of major tenders.
* Contract terms, margins and risk allowances.
Example scenarios:
* Base portfolio as currently expected.
* Conservative portfolio excluding high risk or low margin projects.
* Aggressive portfolio with additional wins and faster expansion.
Compare scenarios using:
* Group level P\&L.
* Cashflow and funding metrics.
* Key portfolio KPIs such as average margin and revenue mix by project type.
{% endstep %}
{% step %}
### Extend to pipeline and backlog
You can link this structure to pipeline models by:
* Adding branches for likely future projects with lower probability weighting.
* Converting them to committed projects in the base model when work is won.
* Using separate scenario models to represent different win rates and pipeline conversions.
This allows you to track how the combination of current projects and likely pipeline affects the future portfolio.
{% endstep %}
{% endstepper %}
## Check your work
* Each project branch contains only that projectโs variables.
* Overheads and financing are clearly separated at group level.
* Group results reconcile to the sum of projects plus overheads.
* Portfolio dashboards are easy to read and reflect known project characteristics.
## Troubleshooting
Group results do not match accounting consolidations
Confirm that all relevant projects are included and that ledger imports or manual entries are mapped correctly into project branches.
Portfolio becomes unwieldy with too many small projects
Aggregate very small jobs into grouped branches by type or region and keep individual branches for the largest contracts.
Stakeholders focus only on project totals
Provide both project level and group level views, and use relative metrics such as margin percentage and cash contribution to deepen the discussion.
## Related guides
* [Combine Multiple External Data Sources](/how-tos/data-workflows-and-automation/combine-multiple-external-data-sources)
* [Convert a PDF to a Structured Forecast](/how-tos/data-workflows-and-automation/convert-a-pdf-to-a-structured-forecast)
* [Cleaning Headers](/help/importing-and-data-inputs/cleaning-headers)
* [Formula Output Preview](/syntax/formula-syntax/formula-output-preview)
# Labour & Subcontractor Planning
This use case explains how to plan labour and subcontractor deployment and costs across construction and contracting projects in Model Reef.
You will:
* Represent direct employees and subcontractors using Staff, COGS and Opex variables.
* Tie labour demand to project workload and schedules.
* Forecast subcontractor usage based on capacity gaps.
* See the effect on project margins and group cashflow.
The focus is on planning and forecasting rather than detailed timesheet level tracking.
When to use this pattern
* Labour and subcontractor costs are major drivers of project profitability.
* You want to understand whether you have enough internal capacity to deliver the pipeline.
* You need to decide how much work to give to subcontractors versus hiring more staff.
Combine this with:
* Project Cash Flow (Milestones) for project level cash behaviour.
* Multi-Project Consolidated Model for portfolio level views.
Architecture overview
The labour and subcontractor planning structure includes:
* Branch and role structure
* Project branches for where work occurs.
* Optional central branch for shared labour pools.
* Role definitions for site labour, supervisors and subcontractors.
* Capacity and demand drivers
* Internal labour capacity by role (FTE or hours).
* Project demand for labour hours by period.
* Subcontractor usage to cover gaps.
* Cost variables
* Staff variables for internal labour.
* COGS or Opex variables for subcontractors.
* Timing of payments based on contracts and terms.
* Outputs
* Labour cost by project and role.
* Subcontractor spend over time.
* Capacity gaps and utilisation.
{% stepper %}
{% step %}
### Define labour roles and structure
Decide how to group labour types, for example:
* Site workers (carpenters, electricians, general labour).
* Supervisors and foremen.
* Project managers.
* Specialist subcontractors (for example steel, electrical, mechanical).
In the branch tree, you can either:
* Place all labour in the project branches, or
* Use a central labour pool branch and allocate labour to projects using drivers.
Choose the approach that best matches how your organisation manages people.
{% endstep %}
{% step %}
### Create internal labour capacity drivers
In the Data Library, create drivers for internal capacity, for example:
* `FTE - Site Workers`.
* `FTE - Supervisors`.
* `FTE - Project Managers`.
Also define:
* `Available Hours per FTE per Period`.
* Leave and non productive allowances to reflect that not all time is billable or deployable.
Capacity per role each period is then:
* `Capacity Hours = FTE ร Available Hours per FTE`.
You can define separate drivers per project or per central pool depending on your structure.
{% endstep %}
{% step %}
### Estimate project labour demand
For each project, estimate labour demand over time. Options include:
* Labour hours derived from project schedule and quantities (for example labour hours per unit of work).
* Labour hours as a percentage of cost or revenue.
* Labour hours approximated via templates for similar projects.
Represent demand using drivers such as:
* `Labour Demand Hours - Site Workers - Project X`.
* `Labour Demand Hours - Supervisors - Project X`.
These drivers can be entered manually, imported from project planning tools or derived from other model variables and drivers.
{% endstep %}
{% step %}
### Identify capacity gaps and subcontractor needs
Compare labour capacity to demand across projects:
* If demand exceeds internal capacity for a role in a period, the gap must be covered by subcontractors or additional hiring.
* If capacity exceeds demand, you have under utilised staff or can take on more work.
Analytically, for each period and role:
* `Gap hours = max(0, demand hours โ capacity hours)`
From there, estimate subcontractor hours and costs:
* `Subcontractor Hours = Gap Hours`
* `Subcontractor Cost = Gap Hours ร Subcontractor Rate`
Represent subcontractor cost using COGS variables such as:
* `COGS - Subcontractors - Project X`
{% endstep %}
{% step %}
### Model labour and subcontractor costs
For internal labour, use Staff variables that represent:
* Salaries or hourly pay.
* Oncosts such as pensions, payroll tax and insurances.
* Timing of payroll.
For subcontractors, use COGS variables that reflect:
* Contract rates per hour, day or unit of work.
* Payment terms (for example 30 days from invoice).
Place these variables in project branches if they are clearly attributable to specific projects, or in a central branch if they are shared and later allocated.
{% endstep %}
{% step %}
### Connect labour planning to project margins and cashflow
Ensure that:
* Labour and subcontractor cost variables are correctly classified so they flow into P\&L and cashflow.
* Project level P\&L shows revenue minus labour, subcontractor and other direct costs.
* Group level Cashflow Statement and Cash Waterfall show aggregate labour and subcontractor cash outflows over time.
Use dashboards to show:
* Labour cost per project and as a percentage of project revenue.
* Subcontractor spend per project and overall.
* Capacity utilisation per role.
This makes it easier to see whether the chosen mix of internal labour and subcontractors is sustainable and profitable.
{% endstep %}
{% step %}
### Use scenarios to test hiring and subcontracting strategies
Create scenario models for different labour strategies, for example:
* Hire more internal staff to reduce subcontractor usage.
* Use more subcontractors to stay flexible and reduce fixed costs.
* Change mix by role or by project type.
Adjust drivers for:
* FTE levels and timing of hires.
* Subcontractor rates and usage.
* Project labour demand if schedule changes.
Compare scenarios using:
* Project and group level margins.
* Cash requirements and volatility.
* Utilisation and subcontractor dependence.
{% endstep %}
{% endstepper %}
Check your work
* Labour roles and cost structures reflect how the organisation actually operates.
* Internal capacity and project demand assumptions are grounded in past projects or realistic planning.
* Subcontractor cost patterns align with actual contract structures and rates.
* Project margins and group cashflows look plausible when compared to historical results.
Troubleshooting
Subcontractor spend appears unrealistically high
Check capacity assumptions and make sure internal labour is being used before subcontractors in your gap calculations.
Capacity appears sufficient but projects still show labour shortfalls
Ensure that you are comparing capacity and demand at the correct level of detail and that timing lines up across projects.
The model becomes too detailed to maintain
Group similar roles or subcontractor types and focus detail on the largest projects or the most critical labour categories.
Related guides
* [Core Modelling](/how-tos)
* [Data Workflows & Automation](/how-tos/data-workflows-and-automation)
* [Consolidation Logic](/help/building-your-model/consolidation-logic)
* [Formula Syntax](/syntax/formula-syntax)
# ๐ญ Manufacturing & Production
# BOM & Unit Cost Modelling
This use case explains how to model bill of materials (BOM) structures and unit production costs for manufacturing and production businesses in Model Reef.
You will:
* Build an ingredient or component library with costs per unit.
* Define BOMs for finished goods and intermediates.
* Compute unit cost per SKU or product family.
* Connect unit costs to production volumes, COGS and margins.
{% hint style="info" %}
Model Reef is not a full manufacturing execution or inventory system. The focus here is planning-level BOM and unit cost modelling that feeds into financial forecasts, pricing and margin analysis.
{% endhint %}
## When to use this pattern
Use this pattern when:
* You manufacture physical products with identifiable components or ingredients.
* Unit economics and gross margins are key decision drivers.
* You need to test cost changes, supplier changes or product redesigns on margin.
* You want a clean bridge from operations assumptions into P\&L and Cash Waterfall.
Often you will combine this with:
* **Capacity and Production Planning**
* **Inventory Turnover and Working Capital**
* **Multi Plant Consolidated Forecasting**
***
## Architecture overview
The BOM and unit cost structure has four layers. Use the stepper below to explore each layer.
{% stepper %}
{% step %}
### Component library
Base materials or components with cost per unit and units of measure.
* Examples: steel, plastic resin, motor assemblies, packaging.
* Key fields: unit of measure (kg, litre, unit, metre), cost per unit, tags (product family, plant, supplier).
{% endstep %}
{% step %}
### BOM definitions
Quantities of each component per unit of finished or intermediate product.
* Include scrap, wastage and yield assumptions.
* Support hierarchical BOMs for subassemblies and finished goods.
{% endstep %}
{% step %}
### Unit cost calculation
Compute direct material cost per unit and optionally add direct labour and overhead.
* Direct material cost = sum(component quantity ร component cost).
* Optionally add labour and factory overhead allocations to get total cost per unit.
{% endstep %}
{% step %}
### Integration with revenue and COGS
Connect unit costs to volumes to produce COGS and margin analysis.
* Unit cost ร volumes => COGS.
* Use product-level COGS variables to feed P\&L gross margin and Cash Waterfall timing.
{% endstep %}
{% endstepper %}
***
{% hint style="info" %}
Follow the steps below to implement BOM and unit cost modelling in Model Reef.
{% endhint %}
{% stepper %}
{% step %}
### Step 1: Build a component cost library
In the Data Library, create entries for each key component or material, for example:
* `Component - Steel Sheet - Cost per kg`
* `Component - Plastic Resin - Cost per kg`
* `Component - Motor Assembly - Cost per unit`
* `Component - Packaging - Cost per unit`
For each component, specify:
* Unit of measure (kg, litre, unit, metre, etc.)
* Cost per unit of measure
* Tags for product family, plant or supplier if useful
Update these drivers as supplier prices change. You can import updated price lists from CSV exports to avoid manual edits.
{% endstep %}
{% step %}
### Step 2: Define BOMs for finished and intermediate products
Decide which SKUs or product families you want to cost in detail. Start with the most important products by volume or margin.
For each SKU or product family, create drivers representing BOM quantities per finished unit, for example:
* `BOM - Product A - Steel Sheet kg per unit`
* `BOM - Product A - Plastic Resin kg per unit`
* `BOM - Product A - Packaging units per unit`
If you use intermediate products, create hierarchical BOMs:
* `BOM - Subassembly X` defined from components.
* `BOM - Product B` defined from `Subassembly X` plus other components.
Maintain these BOM drivers in Model Reef or import them periodically from another system.
{% endstep %}
{% step %}
### Step 3: Compute material cost per unit
Create a driver/variable for each SKU such as `Material Cost per Unit - Product A`.
Use formulas that multiply component quantities by component costs and sum the results. Example formula structure:
Material Cost per Unit - Product A = BOM Steel Sheet ร Cost per kg Steel Sheet
* BOM Plastic Resin ร Cost per kg Plastic Resin
* BOM Packaging ร Cost per unit Packaging
Handle scrap/wastage by either:
* Increasing BOM quantities to account for expected scrap, or
* Applying a wastage multiplier: Total Material Cost ร (1 + Scrap Percentage)
This produces a time series for material cost per unit that responds to changes in component prices and BOM assumptions.
{% endstep %}
{% step %}
### Step 4: Include labour and overhead if needed
To produce a fuller unit cost, add:
* Direct labour cost per unit
* Factory overhead per unit
Approaches:
* `Labour Hours per Unit - Product A` ร hourly labour rate for the plant/line
* Allocate factory overheads based on machine hours, labour hours or volume
Resulting drivers:
* `Conversion Cost per Unit - Product A`
* `Total Cost per Unit - Product A = Material Cost per Unit + Conversion Cost per Unit`
For planning-level costing, a single average overhead per unit for a product family is often sufficient.
{% endstep %}
{% step %}
### Step 5: Link unit cost to production volumes and COGS
For each SKU or product family create:
* A driver for production volumes per period, e.g. `Units Produced - Product A`
* Revenue and COGS variables, e.g. `Revenue - Product A`, `COGS - Product A`
Example formulas:
* Revenue - Product A = Units Sold ร Selling Price per Unit - Product A
* COGS - Product A = Units Sold ร Total Cost per Unit - Product A
If production and sales are tracked separately:
* Use units produced for capacity and cost modelling
* Use units sold for revenue and COGS, with inventory changes modelled separately in Inventory Turnover and Working Capital
COGS variables typed as **COGS** will flow into gross margin in the P\&L and into Cashflow and Cash Waterfall via model timing.
{% endstep %}
{% step %}
### Step 6: Build margin and sensitivity views
With unit cost and revenue per unit in place, compute:
* Unit Margin = Selling Price per Unit โ Total Cost per Unit
* Unit Margin Percentage = Unit Margin / Selling Price per Unit
Use dashboards to display:
* Unit cost components (materials, labour, overhead) per product or family
* Unit margin and gross margin percentage per product
* Sensitivity of margin to component costs or selling price changes
For scenario analysis, clone the model and adjust:
* Component prices (raw material shocks)
* BOM structure (design changes)
* Selling prices
Compare effects on gross margin and cashflow across scenarios.
{% endstep %}
{% step %}
### Step 7: Connect to pricing, capacity and working capital
Once BOM and unit cost are wired into the model:
* Use unit margin and gross margin analysis to support pricing decisions
* Feed production volumes into Capacity and Production Planning to verify deliverability with existing plant
* Feed production and sales volumes into Inventory Turnover and Working Capital to approximate stock levels and working capital needs
This connects engineering and operations assumptions back to financial outcomes for product and portfolio decision-making.
{% endstep %}
{% endstepper %}
***
## Check your work
* Component costs and BOM quantities are realistic and match engineering data or management expectations.
* Unit costs and margins per product line look plausible compared to historical margin analysis.
* Changes in component prices or BOM structure behave as expected and clearly show up in margin outputs.
* The level of detail is manageable for your team to maintain over time.
***
## Troubleshooting
Too many components make the model heavy
Group low-impact components into aggregate items and focus detail on the materials that materially move cost or risk.
Unit cost outputs do not match accounting COGS
Remember that the model is a planning layer. Reconcile patterns and magnitudes, but do not expect an exact match to ledger COGS for past periods without careful calibration.
Margins look incorrect after price or BOM changes
Double check formula references and ensure consistent units of measure and conversion factors across all components.
***
## Related guides
* [Investment & Transactions](/how-tos/investment-and-transactions)
* [Operations & Unit Economics](/how-tos/operations-and-unit-economics)
* [Current Assets](/help/financial-outputs-and-valuation/current-assets)
* [Formula Validation Errors](/syntax/formula-syntax/formula-validation-errors)
# Capacity & Production Planning
{% hint style="info" %}
You will:
* Define capacity by plant, line or work centre.
* Model production volumes, changeovers and utilisation.
* Identify bottlenecks and under utilised assets.
* Connect production plans to revenue, COGS and working capital.
Model Reef provides a planning-level view of capacity and production (not detailed shift/machine scheduling) and integrates with financial forecasts.
{% endhint %}
### When to use this pattern
Use this pattern when:
* You manufacture products in plants, factories or workshops with identifiable capacity constraints.
* You want to understand how planned volumes interact with capacity.
* You need to connect capacity decisions to revenue, cost and cashflow.
It is often paired with:
* **BOM and Unit Cost Modelling** for unit economics.
* **Inventory Turnover and Working Capital** for stock and cash planning.
* **Multi Plant Consolidated Forecasting** for group views.
### Architecture overview
Capacity and production planning uses:
* Branch structure
* Branches for plants, factories or production sites.
* Optional branches for individual lines or work centres where needed.
* Capacity drivers
* Available hours per plant, line or machine.
* Throughput or units per hour.
* Planned downtime and efficiency assumptions.
* Production plan drivers
* Units to produce per product and period.
* Changeovers and product mix.
* Outputs
* Utilisation, bottlenecks and headroom.
* Links to revenue, COGS and working capital.
{% stepper %}
{% step %}
### Define plant and line branches
In the modelโs branch tree, create structure such as:
* Group
* Plant - North
* Plant - South
* Plant - Contract Manufacturer
If you need more detail, add children branches per line:
* Plant - North
* Line - A
* Line - B
Keep the structure aligned with how the business thinks about capacity and performance.
{% endstep %}
{% step %}
### Create capacity drivers per plant or line
In the Data Library, define capacity drivers such as:
* Hours Available per Period - Plant North
* Hours Available per Period - Plant South
Or, if using lines:
* Hours Available per Period - Line A
* Hours Available per Period - Line B
Set these drivers based on shifts per day, days per week, planned shutdowns or holidays.
Then define throughput drivers:
* Units per Hour - Product A - Line A
* Units per Hour - Product B - Line A
Throughput can vary by product and line (changeovers and complexity). Optionally add efficiency/OEE modifiers:
* Effective Capacity Modifier - Line A
Example capacity calculation:
Capacity Units = Hours Available ร Units per Hour ร Effective Capacity Modifier
{% endstep %}
{% step %}
### Define production volumes and mix
Use drivers to specify planned production volumes by product, plant and period, for example:
* Units Produced - Product A - Plant North
* Units Produced - Product B - Plant North
Sources for these drivers:
* Sales forecasts and inventory strategies
* Commercial or demand planning teams
* Templates based on past production patterns
Alternatively, derive required production volumes from sales units plus target inventory change (see Inventory Turnover and Working Capital).
Assign production volumes to the correct plant or line so capacity checks are meaningful.
{% endstep %}
{% step %}
### Check utilisation and bottlenecks
Compute for each plant or line:
* Required Hours per period:
* Required Hours - Line A = Sum over products of (Units Produced รท Units per Hour)
* Utilisation percentage:
* Utilisation Percentage = Required Hours รท Hours Available
Use dashboards to show:
* Utilisation by plant, line and period
* Periods where utilisation exceeds 100% (over capacity)
* Periods where utilisation is far below capacity (under utilised)
Use these views to decide on production plan adjustments, shift pattern changes, outsourcing or capital investment.
{% endstep %}
{% step %}
### Connect capacity and production to financials
Ensure production volumes align with revenue and COGS in the model.
Approaches:
* If production and sales are treated the same for planning, use units produced as the basis for both revenue and COGS variables.
* If production and sales are separate:
* Use production units for factory cost and capacity.
* Use sales units for revenue.
* Model inventory change for the difference (Inventory Turnover and Working Capital).
If capacity constraints prevent the desired production plan, options include:
* Manually adjusting sales forecasts downward.
* Modeling external sourcing by creating COGS variables for outsourced production.
{% endstep %}
{% step %}
### Use scenarios for capacity expansion or contraction
Clone the base model into scenarios to represent capacity strategies such as:
* Adding a new line or plant
* Extending shifts or increasing automation
* Moving production between plants
* Outsourcing or insourcing
Adjust per scenario:
* Hours available
* Throughput drivers
* Production volumes and mix
Compare scenarios using utilisation/bottleneck views and impact on revenue, margin, cash, capex and payback (if capex/depreciation included).
{% endstep %}
{% step %}
### Integrate with inventory and working capital planning
Once capacity and production are connected to unit cost and revenue, you can:
* Use production and sales volumes to approximate inventory levels
* Derive stock-related working capital needs (Inventory Turnover and Working Capital)
* Feed resulting cashflows into the group Cashflow Statement and Cash Waterfall
This creates a coherent flow from machines and lines through to cash and valuation.
{% endstep %}
{% endstepper %}
### Check your work
* Capacity assumptions reflect actual plant configurations, shift patterns and realistic efficiency.
* Production plans are deliverable within capacity limits, or bottlenecks are explicitly visible and addressed.
* The link between units, revenue and COGS is consistent across the model.
* Scenario outputs are believable to operations and finance stakeholders.
### Troubleshooting
Utilisation exceeds 100 percent for long periods
Review production plans, throughput assumptions and capacity assumptions to ensure they are realistic. Consider whether some production is assumed in the wrong plant or line.
Capacity appears under utilised everywhere
Check that sales forecasts and production volumes are not understated, and that you have not double counted capacity from lines that will not actually run.
Difficult to maintain at very fine detail
Aggregate similar lines or product families and use average throughput and capacity values for planning, reserving detailed scheduling for other tools.
### Related guides
* [Valuation](/how-tos/valuation)
* [Build a Cost of Goods Model](/how-tos/operations-and-unit-economics/build-a-cost-of-goods-model)
* [Unit Detection](/help/importing-and-data-inputs/unit-detection)
* [Frequency Inputs](/syntax/timing-syntax/frequency-inputs)
# Inventory Turnover & Working Capital
This use case shows how to approximate inventory and working capital for manufacturing and production businesses in Model Reef.
Model Reef does not implement formal perpetual inventory accounting. Instead, you can use drivers and timing to approximate:
* Inventory levels by product family or plant.
* Inventory turnover and days on hand.
* Working capital tied up in raw materials, work in progress and finished goods.
* The impact of changes in stock policy, lead times and production plans.
## When to use this pattern
Use this pattern when:
* Inventory is a significant use of cash in your business.
* You want to understand how production and purchasing decisions affect cash.
* You need a planning view of inventory rather than detailed batch level tracking.
You will usually connect this with:
* **BOM and Unit Cost Modelling** for unit costs.
* **Capacity and Production Planning** for volumes.
* **Multi Plant Consolidated Forecasting** for group views.
## Architecture overview
The inventory and working capital structure includes:
1. **Inventory policy and turnover drivers**
* Target days on hand or turns per year for each product family or plant.
* Lead times for materials and finished goods.
2. **COGS and volume drivers**
* COGS per period by product family or plant.
* Production and sales volumes.
3. **Inventory level approximations**
* Average inventory based on COGS and days on hand or turns.
* Separation into raw materials, WIP and finished goods where useful.
4. **Working capital and cashflows**
* Inventory value as part of working capital.
* Changes in inventory feeding the Cashflow Statement and Cash Waterfall.
{% stepper %}
{% step %}
### Step 1: Define inventory groups and plants
Choose a manageable level of aggregation for inventory, for example:
* By product family (for example A, B, C).
* By stage (raw materials, WIP, finished goods).
* By plant or warehouse.
In the branch structure, you can:
* Represent plants as branches and track inventory at plant level.
* Or keep inventory modelling central and use drivers to apportion between plants if needed.
The key is to avoid modelling each SKU individually unless necessary.
{% endstep %}
{% step %}
### Step 2: Set inventory policy drivers
In the Data Library, create drivers such as:
* `Target Days on Hand - Raw Materials - Product Family A`.
* `Target Days on Hand - Finished Goods - Product Family A`.
* Or, if you prefer turns:
* `Target Inventory Turns per Year - Product Family A`.
You can also define:
* Supplier lead times for raw materials.
* Production lead times for WIP and finished goods.
These assumptions describe how much inventory you plan to hold relative to usage or sales.
{% endstep %}
{% step %}
### Step 3: Link COGS and volume to inventory
Using outputs from **BOM and Unit Cost Modelling** and your revenue model, determine:
* COGS per period by product family and plant.
* Production and sales volumes per period.
Then approximate inventory levels using formulas such as:
* If using days on hand:
* `Average Inventory = COGS per Day ร Target Days on Hand`.
* Where `COGS per Day = COGS per Period รท Number of Days in Period`.
* If using turns:
* `Average Inventory = COGS per Period รท Turns per Period`.
Create variables for inventory levels, for example:
* `Inventory - Raw Materials - Plant North`.
* `Inventory - Finished Goods - Plant North`.
These variables should be typed as **Asset** to ensure they appear on the Balance Sheet.
{% endstep %}
{% step %}
### Step 4: Separate raw materials, WIP and finished goods (optional)
If you need additional detail, you can split inventory into stages using shares or more detailed drivers, for example:
* `Raw Materials Share of Inventory`.
* `WIP Share of Inventory`.
* `Finished Goods Share of Inventory`.
Then compute:
* `Inventory - Raw Materials = Average Inventory ร Raw Materials Share`.
* `Inventory - WIP = Average Inventory ร WIP Share`.
* `Inventory - Finished Goods = Average Inventory ร Finished Goods Share`.
This allows more nuanced analysis of where cash is tied up and how policies differ by stage.
{% endstep %}
{% step %}
### Step 5: Model changes in inventory and working capital
The Cashflow impact of inventory comes from changes in inventory levels over time.
Model Reef will compute this automatically when you treat inventory as Asset type variables with appropriate timing, but conceptually:
* An increase in inventory uses cash.
* A decrease in inventory releases cash.
Use the Cashflow Statement and Cash Waterfall to see:
* Net change in working capital related to inventory.
* Contribution of inventory changes to total cash movement.
You can also compare inventory levels and changes to trade debtors and creditors to get a full picture of working capital.
{% endstep %}
{% step %}
### Step 6: Build inventory and working capital dashboards
Create dashboards that show:
* Inventory levels by product family and plant.
* Inventory days on hand and turns over time.
* Inventory value as a share of total assets or revenue.
* Cash impact of inventory changes.
Use these views to:
* Evaluate the impact of changing inventory policies (for example reducing days on hand).
* Assess whether improvements in capacity or forecasting could reduce stock without increasing risk of stock outs.
{% endstep %}
{% step %}
### Step 7: Use scenarios for policy and supply chain shocks
Clone the base model into scenario models that reflect different inventory strategies or supply conditions, for example:
* Reduced days on hand through better planning.
* Higher safety stock due to supply chain risk.
* Changes in lead times from key suppliers.
Adjust inventory drivers and compare:
* Inventory levels and working capital tied up.
* Cashflow volatility and minimum cash positions.
* Ability to meet sales plans given production and supply constraints.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
### Check your work
* Inventory policy drivers reflect realistic operational practice, not just theoretical targets.
* Inventory levels and days on hand for historical periods resemble what is seen in actual stock reports when you calibrate the model.
* Changes to policy or volumes produce expected directional changes in inventory and cash.
* The complexity of the structure is proportionate to the business size and decision needs.
{% endhint %}
## Troubleshooting
Inventory levels appear unrealistically high or low
Check that COGS per period is correctly calculated, that days on hand or turns are realistic, and that unit conversions are handled correctly.
Inventory metrics are too noisy
Consider smoothing inputs or using a slightly more aggregated view by product family or plant.
Difficult to reconcile to accounting inventory balances
Treat this pattern as a planning tool. Use it for forward looking decisions and policy analysis rather than expecting exact historical reconciliation without detailed calibration.
## Related guides
* [Build a Working Capital Model](/how-tos/operations-and-unit-economics/build-a-working-capital-model)
* [Build a Capital Raise Model](/how-tos/investment-and-transactions/build-a-capital-raise-model)
* [Working Capital](/help/financial-outputs-and-valuation/working-capital)
* [How to Enter Drivers](/syntax/how-input-fields-work/how-to-enter-drivers)
# Multi-Plant Consolidated Forecasting
This use case explains how to forecast across multiple plants, factories or production sites in Model Reef and consolidate results at group level.
You will:
* Represent each plant as its own branch.
* Attach revenue, cost, capacity and inventory structures to each plant.
* Add central overheads and group level financing.
* Produce plant level and consolidated forecasts for P\&L, Balance Sheet, Cashflow and Cash Waterfall.
This pattern extends plant level models built using **BOM and Unit Cost Modelling**, **Capacity and Production Planning** and **Inventory Turnover and Working Capital** to a multi plant environment.
## When to use this pattern
Use this pattern when:
* You operate more than one manufacturing or production site.
* You want clear visibility of performance per plant as well as group level.
* You need to plan transfers of production, investment or closure across plants.
* You use a mix of in house plants and contract manufacturers and want them in one view.
It is also useful for contract manufacturing arrangements where some production is internal and some external.
## Architecture overview
The multi plant structure uses:
* Branch tree
* One branch per plant, plus grouping branches if needed.
* A group branch for consolidated results.
* Optional branches for contract manufacturers and central overheads.
* Plant level models
* Revenue, unit cost, capacity and inventory structures per plant.
* Plant specific staffing and Opex.
* Group level structures
* Central overheads, shared assets and group debt.
* Equity injections, dividends and other group actions.
* Outputs
* Plant level P\&L and cash views.
* Consolidated forecasts and dashboards.
* Scenario comparisons for alternative network strategies.
{% stepper %}
{% step %}
### Set up branches for each plant
In the branch tree, create a structure such as:
* `Group`
* `Plant - North`
* `Plant - South`
* `Plant - Contract Manufacturer`
* `Central Overheads`
If you have many plants, you can group them under regional branches, for example `Region - EU`, `Region - US`, etc.
Each plant branch holds that plantโs revenue, cost, capacity and inventory variables. The group branch is used only for consolidation and group level items.
{% endstep %}
{% step %}
### Implement plant level revenue and unit cost structures
Within each plant branch:
* Implement BOM and unit cost structures for the SKUs or product families that plant produces.
* Define production volumes per SKU and period.
* Create revenue variables based on volumes and selling prices (which may be set centrally or per region).
Ensure that:
* Product naming is consistent across plants.
* Categories and subcategories are the same for all plants.
* Drivers such as selling price and unit cost are reused where appropriate via the Data Library.
This consistency allows reports and dashboards to aggregate meaningfully.
{% endstep %}
{% step %}
### Attach capacity and production planning per plant
For each plant branch, include capacity and production drivers such as:
* Hours available per period (shifts, days, planned maintenance).
* Throughput per line and product.
* Efficiency or OEE modifiers.
* Production volumes per product.
Use the **Capacity and Production Planning** pattern so that for each plant you can see:
* Required hours.
* Utilisation percentage.
* Bottlenecks and unused capacity.
This allows you to:
* Check whether the proposed production plan per plant is feasible.
* Compare utilisation and headroom across plants.
* Evaluate moving production from one plant to another in scenarios.
{% endstep %}
{% step %}
### Model inventory and working capital per plant
Use the **Inventory Turnover and Working Capital** pattern to approximate:
* Raw materials, WIP and finished goods per plant.
* Inventory days on hand and turns for each plant.
* Working capital tied up in stock across the network.
Implement this by:
* Creating Asset type variables such as `Inventory - Raw Materials - Plant North`, `Inventory - Finished Goods - Plant South`.
* Driving inventory levels from COGS and policy drivers like days on hand or turns.
* Letting the model compute changes in inventory so the Cashflow Statement and Cash Waterfall reflect working capital movements.
If inter plant transfers are material, you can represent them as:
* Additional COGS or internal revenue lines, or
* Reclassification entries between plants.
Keep in mind Model Reef is a planning engine, so keep intercompany logic simple and aligned with decision needs.
{% endstep %}
{% step %}
### Add central overheads and group financing
Create a `Central Overheads` or similar branch with variables for:
* Group level staff costs (executive, central finance, HR, IT).
* Central marketing and brand spend.
* Group wide systems and licences.
* Shared services.
At the group branch, add variables for:
* Group debt and interest.
* Equity injections or shareholder distributions.
* Shared assets not tied to a specific plant (for example HQ building).
These structures:
* Keep plant branches focused on operational performance.
* Keep group branch focused on capital structure, central overheads and investor facing metrics.
{% endstep %}
{% step %}
### Build plant and group reporting
Use reports and dashboards to provide:
Plant level views
* P\&L per plant, including revenue, COGS and gross margin.
* Opex and staff cost per plant.
* Plant level Cashflow Statement and Cash Waterfall.
* Capacity and utilisation charts per plant.
Group level views
* Consolidated P\&L across all plants plus central overheads.
* Consolidated Balance Sheet, including plant inventories and group debt.
* Consolidated Cashflow Statement and Cash Waterfall.
* Margin and working capital analysis by plant and in total.
You can add views such as:
* Revenue, COGS and gross margin by plant.
* Contribution per plant after allocated or unallocated overheads.
* Inventory and working capital by plant and in aggregate.
{% endstep %}
{% step %}
### Use scenarios for network strategy
Clone the multi plant model into separate models to test network strategies, such as:
* Opening a new plant.
* Closing or downsizing a plant.
* Shifting specific products from one plant to another.
* Moving some production to contract manufacturers.
* Investing in additional capacity or automation.
For each scenario, adjust:
* Branch structure (for example adding or removing plant branches).
* Capacity, unit cost and production drivers per plant.
* Central overheads and group financing assumptions.
* Inventory policy and lead times per plant.
Compare scenarios on:
* Group level P\&L and cashflow.
* Plant level margins and utilisation.
* Required capex and associated depreciation.
* Payback and valuation, using the Valuation Engine.
{% endstep %}
{% endstepper %}
## Check your work
* Each plant branch contains only variables that truly belong to that plant.
* Central costs and financing are separated from plant cost structures and clearly visible.
* Consolidated results at the group branch reconcile to the sum of plants plus central overheads.
* Capacity, margin and cash patterns are believable to both operations and finance stakeholders.
## Troubleshooting
Plants look much more or less profitable than actuals
Check that revenue, cost and overhead allocations align with your accounting view, and calibrate plant level assumptions using latest actuals.
Inventory or working capital appears double counted
Ensure you model inventory at one level per plant and avoid representing the same stock in multiple branches or variables.
The model feels unwieldy with many plants and SKUs
Group smaller plants or product families into aggregate buckets and reserve detailed modelling for the largest or most strategic ones.
## Related guides
* [Build a Consolidated Forecast Model](/how-tos/core-modelling/build-a-consolidated-forecast-model)
* [Build a Multi Division Model](/how-tos/core-modelling/build-a-multi-division-model)
* [Data Library Mapping](/help/xero-integration/data-library-mapping)
* [How to Enter Values](/syntax/how-input-fields-work/how-to-enter-values)
# ๐๏ธ eCommerce & D2C Brands
# SKU Margin & Contribution Modelling
This use case explains how to model SKU level margin and contribution for eCommerce and direct to consumer brands in Model Reef.
You will:
* Group products into SKUs or product families with clear economics.
* Define selling price, discounts and unit cost per SKU.
* Include fulfilment, shipping, payment fees and returns in contribution.
* Roll SKU level results into channel, country and brand views.
Model Reef is not an order management or warehouse system. The focus is on planning level SKU economics that flow into P\&L, cash and valuation.
## When to use this pattern
Use this pattern when:
* You sell multiple SKUs or bundles online or through direct channels.
* You want to understand margin per SKU, per basket and per channel.
* You need to test price changes, cost changes or mix shifts on margin.
* You want to tie SKU economics directly into a full three statement model.
It is usually combined with:
* **Paid Ads CAC Forecasting**
* **Inventory Purchases and Reorders**
* **Multi Channel Revenue Forecasting**
## Architecture overview
You will build four layers:
{% stepper %}
{% step %}
### SKU and product family structure
* SKUs or families defined in the Data Library.
* Price, cost and unit attributes per SKU.
{% endstep %}
{% step %}
### Unit economics drivers
* Selling price and discounts.
* Unit cost, fulfilment, shipping and payment fees.
* Returns and refund assumptions.
{% endstep %}
{% step %}
### Volume drivers
* Units sold per SKU by channel and period.
{% endstep %}
{% step %}
### Outputs
* Contribution margin per SKU and channel.
* Aggregated margin by brand, channel and country.
* Integration with full P\&L and cashflow.
{% endstep %}
{% endstepper %}
## Step 1: Define SKUs and product families
Decide whether you will model at:
* Individual SKU level (for example size and colour variants).
* Product family level (for example product line or collection).
* Bundle level (kits, subscription bundles).
In the Data Library, create entries such as:
* `SKU - Hoodie Classic`.
* `SKU - Hoodie Premium`.
* `SKU - T Shirt Basic`.
* Or product families such as `Product Family - Hoodies` if you want less granularity.
Include attributes as metadata or tags, for example:
* Category (tops, bottoms, accessories).
* Brand or collection.
* Primary channel or region.
These entries will be reused across pricing, cost and volume drivers.
## Step 2: Create selling price and discount drivers
For each SKU or product family, create drivers for:
* `List Price per Unit`.
* `Average Discount Percentage`.
* `Net Realised Price per Unit`.
Net price can be computed as:
* `Net Price = List Price ร (1 minus Discount Percentage)`.
Store these drivers as periodic series so you can:
* Model promotional periods with deeper discounts.
* Model annual price changes or repositioning.
You may also split price and discounts by channel if relevant, for example:
* `Net Price - Hoodie Classic - Direct Web`.
* `Net Price - Hoodie Classic - Marketplace`.
## Step 3: Create unit cost and fulfilment drivers
Use **BOM and Unit Cost Modelling** if you manufacture your own products, or define unit cost directly if you purchase finished goods from suppliers.
For each SKU or product family, define drivers for:
* `Product Cost per Unit` (ex factory or landed cost).
* `Fulfilment Cost per Order` or per unit.
* `Shipping Cost per Order` or per unit.
* `Payment Fees Percentage` (for card, PayPal, BNPL, etc.).
* `Platform Fees` for marketplaces.
In many cases it is helpful to separate:
* Costs that scale with orders (pick, pack, ship, packaging).
* Costs that scale with revenue (payment fees, platform commissions).
You can then create derived drivers such as:
* `Variable Cost per Unit = Product Cost per Unit plus Variable Fulfilment and Shipping per Unit plus Payment Fees per Unit`.
## Step 4: Model returns, refunds and failed payments
Returns are a major driver of economics for many D2C brands. For each SKU or product family, set drivers for:
* `Return Rate Percentage`.
* `Refund Rate Percentage` (some returns may not be refunded in full).
* `Resale Percentage` for returned stock that can be resold.
Implement this using variables or drivers:
* Effective units kept by customers:
* `Net Units Kept = Units Sold ร (1 minus Return Rate)`.
* Lost revenue due to refunds:
* `Refunds = Units Sold ร Net Price ร Refund Rate`.
* Recoverable cost of returned goods if they can be resold or refurbished.
These assumptions help you move from top line revenue to net contribution after returns.
## Step 5: Define volume drivers per SKU and channel
Next, define units sold per SKU and channel. Options include:
* Direct volume drivers per SKU and channel, for example:
* `Units Sold - Hoodie Classic - Direct Web`.
* `Units Sold - Hoodie Classic - Marketplace`.
* Conversions from traffic and conversion drivers, in combination with **Paid Ads CAC Forecasting** and traffic from organic or other sources.
You can model volumes as:
* Time series based on growth assumptions and seasonality.
* Output of a funnel where traffic ร conversion rate ร basket composition produce unit volumes.
Store these as drivers or variables in the relevant channel branches so they feed both revenue and inventory planning.
## Step 6: Build SKU level revenue, COGS and contribution variables
For each SKU and channel, create:
* `Revenue - SKU - Channel` variables of type **Revenue**.
* `COGS - SKU - Channel` variables of type **COGS**.
* Optional Opex variables for SKU specific marketing or promotions.
Example formulas:
* `Revenue - Hoodie Classic - Direct Web = Units Sold - Hoodie Classic - Direct Web ร Net Price per Unit - Hoodie Classic`.
* `COGS - Hoodie Classic - Direct Web = Units Sold - Hoodie Classic - Direct Web ร Product Cost per Unit - Hoodie Classic`.
* Add variables for variable fulfilment, shipping and payment fees if you want them visible as separate lines, or include them in COGS.
Define a `Contribution Margin - SKU - Channel` variable via custom formula as:
* `Contribution = Revenue minus COGS minus variable fulfilment, shipping and payment fees`.
You can keep contribution as a derived metric (chart or report formula) rather than a separate variable if you prefer.
## Step 7: Aggregate contribution by channel, brand and country
Use branch structure and categories to roll up SKU level results:
* Branches per channel (for example Direct Web, Marketplace, Wholesale).
* Sub branches per region or country if needed.
Create variables or report lines for:
* Total contribution per channel.
* Contribution per product family or brand.
* Contribution per market.
Use dashboards to show:
* Contribution per SKU, per channel and per order.
* Contribution per customer or per cohort (when linked to CAC and retention models).
* Mix shifts between high and low contribution SKUs or channels.
This allows you to see which SKUs and channels drive value and which are diluting margin.
## Check your work
* SKUs or product families reflect how the brand actually groups and reports products.
* Selling price, discount and cost assumptions are grounded in real data.
* Contribution patterns by SKU and channel look plausible compared to historical analysis.
* Net revenue and COGS in the model reconcile broadly to recent financial statements when volumes and prices are calibrated.
## Troubleshooting
SKU list is too long to manage
Group low volume SKUs into product families or representative SKUs and only model top SKUs individually.
Margins look higher or lower than expected
Check that all relevant variable costs have been captured, including fulfilment, shipping, payment fees and returns.
Channel results are difficult to interpret
Ensure branch structure mirrors how the business thinks about channels and that SKUs are consistently mapped to channels.
## Related guides
* [Build a Board Reporting Pack](/how-tos/dashboards-and-reporting/build-a-board-reporting-pack)
* [Build a Bottom Up Forecast](/how-tos/core-modelling/build-a-bottom-up-forecast)
* [Date Column Detection](/help/importing-and-data-inputs/date-column-detection)
* [KPI Cards](/syntax/chart-and-table-syntax/kpi-cards)
# Paid Ads CAC Forecasting
This use case explains how to model paid advertising, customer acquisition cost (CAC) and new customers for eCommerce and direct to consumer brands in Model Reef.
You will:
* Define ad spend by channel and campaign group.
* Model traffic, click through and conversion rates.
* Compute CAC, new customers and revenue from acquired customers.
* Connect CAC and customer flows to unit economics and cashflow.
Model Reef is not an ad platform or attribution system. It consumes summary metrics from those systems and projects them forward within a financial model.
***
## When to use this pattern
Use this pattern when:
* Paid acquisition is a significant driver of growth.
* You want to understand how ad spend, CAC and LTV interact.
* You need to allocate budget across channels or campaigns.
* You want advertising decisions reflected in P\&L and cash forecasts.
It is commonly paired with:
* **SKU Margin and Contribution Modelling**
* **Multi Channel Revenue Forecasting**
* Retention or cohort modelling in the Use Cases section for SaaS and subscriptions.
***
## Architecture overview
{% stepper %}
{% step %}
### Spend and funnel drivers
* Ad spend by channel and campaign.
* Impressions, clicks and traffic.
* Conversion rates and average order value.
{% endstep %}
{% step %}
### Customer and order flows
* New customers and orders per channel and period.
* CAC per customer or per order.
* Repeat order behaviour if you choose to include it.
{% endstep %}
{% step %}
### Financial outputs
* Opex for marketing spend.
* Revenue from acquired customers.
* CAC payback and contribution.
{% endstep %}
{% endstepper %}
***
## Step 1: Define channels and campaigns
Decide how you want to group paid acquisition, for example:
* Channels:
* Google Search.
* Google Shopping.
* Meta (Facebook and Instagram).
* TikTok.
* Other paid social.
* Campaign groups within channels:
* Brand versus non brand.
* Prospecting versus retargeting.
* Upper, mid and lower funnel.
In the branch tree, you can create branches such as:
* `Channel - Paid Search`.
* `Channel - Paid Social`.
* `Channel - Other Paid`.
Or keep branches at customer or revenue channel level and track ad spend by driver per channel.
***
## Step 2: Create ad spend drivers
In the Data Library, create drivers for ad spend per channel or campaign, for example:
* `Ad Spend - Paid Search`.
* `Ad Spend - Paid Social`.
* `Ad Spend - Other Paid`.
Enter or import planned spend per period. You can represent budgets as:
* Fixed amounts per period.
* A percentage of revenue with caps and floors.
* A ramp up schedule as you open new markets or products.
Attach these drivers to Opex variables in the appropriate branches, typed as **Opex**, for example:
* `Opex - Paid Search Spend`.
* `Opex - Paid Social Spend`.
This ensures ad spend flows into P\&L and cashflow correctly.
***
## Step 3: Define funnel efficiency drivers
For each channel or campaign, create drivers for funnel performance, for example:
* `Cost per Click (CPC)`.
* `Click Through Rate (CTR)` if modelling from impressions.
* `Traffic Conversion Rate` (visitors to orders).
* `New Customer Share` (what proportion of orders are from new customers).
You can either:
* Derive these from historical data and assume future stability.
* Or set them up as scenario driven drivers that change under different budget and strategy assumptions.
These drivers allow you to translate spend into traffic, orders and customers.
***
## Step 4: Compute clicks, traffic, orders and new customers
Create variables that compute:
* `Clicks = Ad Spend รท CPC`.
* `Traffic = Clicks` (or Traffic = Impressions ร CTR if you model impressions explicitly).
* `Orders = Traffic ร Conversion Rate`.
* `New Customers = Orders ร New Customer Share`.
You may want to separate:
* First orders from new customers.
* Repeat orders from existing customers (handled in a separate retention model).
Store these as operational drivers and variables that can be reused in revenue and cohort models.
***
## Step 5: Calculate CAC and link to revenue
Calculate CAC per channel as:
* `CAC per New Customer = Ad Spend รท New Customers`.
* Or, if you prefer per order:
* `CAC per Order = Ad Spend รท Orders`.
Use these outputs to:
* Feed into a unit economics view that compares CAC to first order contribution and LTV.
* Inform budget and bidding strategy.
Then connect customer or order flows to revenue, for example:
* `Revenue from Paid Search = Orders from Paid Search ร Average Order Value`.
* Average order value can be a driver per channel or shared across channels.
Ensure these revenue variables are typed as **Revenue** and flow into P\&L and cash.
***
## Step 6: Build CAC and paid media dashboards
Create dashboards that show:
* Ad spend per channel over time.
* New customers and orders per channel over time.
* CAC per customer and per order.
* Revenue and contribution generated per channel.
* CAC payback period when combined with contribution and retention models.
You can add simple rules such as highlighting channels where CAC exceeds target thresholds or where contribution or LTV to CAC ratios are weak.
***
## Step 7: Use scenarios for budget and efficiency changes
Clone your model into scenario models that reflect different paid media strategies, for example:
* Increased spend across all channels with stable efficiency.
* Higher spend with diminishing returns on conversion rates.
* Reallocated spend from one channel to a more efficient one.
* Tighter budgets with an efficiency focus.
For each scenario, adjust:
* Ad spend drivers.
* Funnel efficiency drivers.
* Conversion and repeat behaviour if needed.
Compare scenarios using:
* CAC and new customers.
* Revenue from paid acquisition.
* Contribution and LTV to CAC metrics.
* Cashflow impact of advertising investments.
***
## Check your work
* Ad spend drivers tie back to realistic budget planning or historical spending patterns.
* CPC, conversion and new customer share metrics reflect actual channel performance.
* CAC values are in line with what marketing teams see in platform dashboards.
* Revenue and contribution from paid acquisition look sensible relative to overall sales.
***
## Troubleshooting
CAC is highly volatile between periods
Smooth input drivers or model at a slightly higher aggregation level to avoid noise that is not meaningful for planning.
Modelled CAC does not match platform reported CAC
Check whether you are measuring CAC per new customer or per order and ensure attribution windows are conceptually aligned.
Hard to attribute revenue between organic and paid
Agree a simple rule of thumb for planning (for example last click or blended cost) and keep the model focused on financial decisions rather than exact attribution debates.
***
## Related guides
* [Build a Budget vs Actuals Model](/how-tos/scenarios-and-planning/build-a-budget-vs-actuals-model)
* [Build a Capex & Depreciation Model](/how-tos/operations-and-unit-economics/build-a-capex-and-depreciation-model)
* [Debt Service Logic](/help/financial-outputs-and-valuation/debt-service-logic)
* [Linking Drivers to Variables](/syntax/drivers-syntax/linking-drivers-to-variables)
# Inventory Purchases & Reorders
{% hint style="info" %}
Model Reef provides a planning layer for inventory: it helps determine how much to order and when, and how that flows into COGS, working capital and cashflow. It does not implement full inventory accounting.
{% endhint %}
## Inventory Purchases and Reorders
This use case explains how to plan inventory purchases and reorders for eCommerce and direct-to-consumer brands using Model Reef.
You will:
* Use demand and sales forecasts to infer required stock levels.
* Model supplier lead times and minimum order quantities.
* Plan purchase orders by SKU or product family.
* See the impact of inventory decisions on cash and working capital.
***
### When to use this pattern
Use this pattern when:
* Inventory and purchasing decisions are a major use of cash.
* You need to plan ahead for long lead times or seasonal peaks.
* You want a simple, visual way to see how stock policy affects cash and risk of stock out.
You will typically connect this with:
* **SKU Margin and Contribution Modelling**
* **Multi Channel Revenue Forecasting**
* **Inventory Turnover and Working Capital** (manufacturing use case adapted for D2C)
***
### Architecture overview
{% stepper %}
{% step %}
#### Demand and sales drivers
* Units sold per SKU and channel over time.
* Seasonality and campaign effects.
{% endstep %}
{% step %}
#### Stock policy and lead time drivers
* Target days of cover or stock on hand per SKU or family.
* Supplier lead times and order frequency.
* Minimum order quantities and pack sizes.
{% endstep %}
{% step %}
#### Purchase and receipt variables
* Planned purchase quantities.
* Arrival timing of stock.
* Cash outflows for purchases.
{% endstep %}
{% step %}
#### Working capital and cash outputs
* Approximate stock levels and changes.
* Cash impact of inventory investments.
{% endstep %}
{% endstepper %}
***
### Step 1: Start from volume and unit cost assumptions
Ensure you already have:
* Sales volume drivers per SKU or family from **Multi Channel Revenue Forecasting** or SKU level models.
* Unit cost per SKU or family from **SKU Margin and Contribution Modelling** or **BOM and Unit Cost Modelling**.
These will be used to determine how much stock is needed and what it will cost.
***
### Step 2: Define stock policy and lead times
In the Data Library, create drivers per SKU or family for:
* `Target Days of Cover` or `Target Weeks of Cover`.
* `Supplier Lead Time in Days or Weeks`.
* `Order Frequency` (weekly, monthly, or at fixed thresholds).
* `Minimum Order Quantity` or `Order Multiple` (for example cases or pallets).
Simpler models can use one set of stock policy drivers per product family. More detailed models can use per SKU assumptions.
These drivers describe how much stock you aim to hold and how early you must order to avoid stock out.
***
### Step 3: Approximate required stock levels
Using volume forecasts, approximate required stock levels. For example:
* If using days of cover:
* Required Stock Level at Period End = Next Period COGS per Day ร Target Days of Cover.
* If using weeks of cover:
* Required Stock Level = COGS per Week ร Target Weeks of Cover.
Create Asset type variables such as:
* `Inventory - Product Family A`.
* `Inventory - Product Family B`.
These represent the value of stock you intend to hold, based on demand and policy.
***
### Step 4: Translate required stock into purchase orders
Changes in stock between periods tell you how much to purchase, before factoring in lead time, for example:
* Purchase Quantity this Period = Required Stock Level plus COGS for this Period minus Opening Stock Level.
Convert that into units or value per SKU or family.
Then, adjust for lead times by:
* Shifting purchase timing earlier, so that stock arrives before it is needed.
* Using schedules or delays to represent when purchase orders are placed versus when goods arrive.
You may also apply:
* Minimum order quantities by rounding up to the nearest pack size.
* Order batching by grouping purchases into monthly or quarterly orders.
Represent purchases as COGS or Asset related variables with appropriate timing so that:
* Cash outflows occur when suppliers are paid.
* Inventory assets increase when goods are received.
***
### Step 5: Model supplier payment timing
For purchases, use timing rules to represent supplier payment terms, for example:
* 30 days from invoice date.
* 60 or 90 days for key suppliers.
Costs for purchases can be modelled as COGS variables with delays that reflect payment terms, or as Asset related variables if you want to split recognition of inventory value from cash movement.
The key is that:
* Cash leaves when payments are due.
* Inventory value increases when goods are received.
Model Reefโs AR and AP mechanics will reflect these timing differences in the Balance Sheet and Cashflow Statement.
***
### Step 6: Build inventory and purchasing dashboards
Create dashboards that show:
* Planned purchases per period by SKU, family or supplier.
* Inventory levels and days of cover over time.
* Cash outflows related to purchases.
* Periods where purchases and other cash demands coincide and risk cash strain.
Use these views to:
* Shift orders earlier or later.
* Change stock policy for certain products.
* Adjust campaign and promotion timing to better match stock and cash availability.
***
### Step 7: Use scenarios for policy, supply and demand shocks
Clone the model into scenario models representing:
* Leaner inventory strategy (lower days of cover).
* Higher safety stock for key items.
* Longer supplier lead times due to supply chain disruption.
* Faster or slower demand growth.
In each scenario, adjust:
* Stock policy drivers.
* Lead times and minimum order quantities.
* Volume forecasts.
Compare scenarios using:
* Inventory investment and working capital.
* Cash requirements and minimum cash.
* Stock out risk and revenue loss risk (approximate).
***
### Check your work
* Stock policy assumptions are realistic for your category and supply chain.
* Inventory levels and cash outflows match your expectations for historical periods when calibrated.
* The seasonality of purchases matches major product and campaign cycles.
* Purchase volumes are attainable from suppliers and consistent with minimum order constraints.
***
### Troubleshooting
Inventory looks too high despite modest days of cover
Check that COGS per period is correct and that you are not double counting units in multiple families or branches.
Cash dips severely at odd times
Confirm that purchase timing and payment delays are correctly applied and not stacked unintentionally with other big cash events.
Model is too granular to maintain
Aggregate SKUs into families for inventory planning and reserve SKU detail for margin analysis only.
***
### Related guides
* [Build an Inventory Timing Model](/how-tos/operations-and-unit-economics/build-an-inventory-timing-model)
* [Build a Capital Structure Model](/how-tos/investment-and-transactions/build-a-capital-structure-model)
* [Default Valuation Assumptions](/help/stock-ticker-fundamentals/default-valuation-assumptions)
* [Manual Time Series Editing](/syntax/variables-syntax/manual-time-series-editing)
# Multi-Channel Revenue Forecasting
This use case describes how to forecast revenue across multiple channels for eCommerce and direct to consumer brands using Model Reef.
You will:
* Represent sales channels such as direct web, marketplaces and wholesale.
* Forecast traffic, conversion and average order value where appropriate.
* Model units and revenue per SKU or product family per channel.
* Roll channel level revenue into consolidated P\&L, cash and valuation.
The aim is to make channel performance explicit rather than hiding everything in a single aggregate revenue line.
## When to use this pattern
Use this pattern when:
* You sell across multiple channels with different economics, for example direct web, Amazon, retail partners and wholesale.
* Channel mix is strategic for margin and brand control.
* You want to see channel contributions to revenue and profit separately.
It is usually combined with:
* **SKU Margin and Contribution Modelling**
* **Paid Ads CAC Forecasting**
* **Inventory Purchases and Reorders**
***
## Architecture overview
Multi channel forecasting includes:
* Branch structure
* Branches per channel (Direct, Marketplace, Wholesale, Retail, etc.).
* Optional child branches for region or major partners.
* Volume and funnel drivers
* Traffic and conversion drivers for direct channels.
* Order volumes and sell-in volumes for wholesale and retail.
* Price and discount drivers
* Selling price and discount per SKU or family per channel.
* Different economics at retail versus wholesale versus marketplace.
* Revenue variables and outputs
* Revenue per SKU per channel.
* Channel level revenue and margin.
* Consolidated brand or group revenue.
***
{% stepper %}
{% step %}
### Define channel branches
In the branch tree, create a structure such as:
* `Brand`
* `Channel - Direct Web`
* `Channel - Marketplaces`
* `Channel - Wholesale`
* `Channel - Retail Stores`
If you operate multiple brands, have a parent branch per brand under a group level root branch.
Each channel branch will hold its own revenue, discount and sometimes cost variables.
{% endstep %}
{% step %}
### Set up volume and funnel drivers per channel
For direct web and app channels, use funnel drivers:
* `Sessions or Visits`.
* `Conversion Rate`.
* `Average Basket Size in Units`.
* `Average Order Value`.
Compute orders and units sold as:
* `Orders = Visits ร Conversion Rate`.
* `Units Sold = Orders ร Units per Order`.
For marketplaces, wholesale and retail, you may use:
* Order volumes in units per customer or partner.
* Sell-in volume to retailers and distributors.
* Sell-out volume if you receive reports on downstream sales.
Store these as drivers or variables in the relevant channel branches.
{% endstep %}
{% step %}
### Define pricing and discount per channel
For each SKU or family and channel, define drivers for:
* `List Price per Unit - Channel`.
* `Average Discount per Channel`.
* `Net Price per Unit - Channel`.
Examples:
* `Net Price - Hoodie Classic - Direct Web`.
* `Net Price - Hoodie Classic - Marketplace`.
* `Net Price - Hoodie Classic - Wholesale`.
Note: Marketplaces may also have platform commission percentages which you can model either as a reduction in effective net price or as a separate cost line.
{% endstep %}
{% step %}
### Build revenue variables per SKU and channel
Combine volume and price to create Revenue variables per SKU and channel, for example:
* `Revenue - Hoodie Classic - Direct Web`.
* `Revenue - Hoodie Classic - Marketplace`.
* `Revenue - Hoodie Classic - Wholesale`.
Typical formula:
* `Revenue = Units Sold per Channel ร Net Price per Unit per Channel`.
Ensure all revenue variables are typed as **Revenue** so they flow into P\&L, Cashflow and Cash Waterfall.
Create channel level roll up variables or use reports and dashboards to aggregate across SKUs within each channel branch.
{% endstep %}
{% step %}
### Include channel specific variable costs where relevant
Channel economics often differ in variable costs, for example:
* Marketplace commissions and fulfilment fees.
* Wholesale discounts and marketing contributions.
* Retail rent, staffing and store operating costs.
Create COGS or Opex variables such as:
* `COGS - Marketplace Fees`.
* `Opex - Retail Store Rent`.
* `Opex - Wholesale Slotting Fees`.
Attach these to the relevant channel branches. Combined with SKU level contribution modelling, they give a comprehensive view of channel profitability.
{% endstep %}
{% step %}
### Build channel and consolidated dashboards
Create dashboards that show:
* Revenue per channel and per SKU over time.
* Channel mix as a share of total revenue.
* Gross margin and contribution per channel.
* Key KPIs such as revenue per visit for Direct, revenue per customer, or revenue per store.
At the root branch, view:
* Total brand or group revenue across channels.
* Margin and cash metrics that aggregate all channels.
This supports discussion about growth priorities, channel investment and channel mix management.
{% endstep %}
{% step %}
### Use scenarios for channel strategy and mix
Clone the model into scenario models to reflect different channel strategies, for example:
* Aggressive marketplace expansion.
* Direct first strategy with reduced marketplace reliance.
* Wholesale expansion with new retail partners.
* Store roll out and new retail geographies.
For each scenario, adjust:
* Volume, funnel and pricing drivers per channel.
* Channel specific cost assumptions.
* Marketing and CAC assumptions in connected paid media models.
Compare scenarios on:
* Revenue and margin per channel.
* Channel mix and dependency.
* Cash requirements and risk.
{% endstep %}
{% endstepper %}
***
{% hint style="info" %}
Check your work
* Channels and branches reflect how the business actually operates and reports.
* Volume, price and discount assumptions per channel are grounded in data or well informed estimates.
* Channel revenue and margin patterns look plausible when compared to historical results.
* Consolidated revenue aligns with company level planning when calibrated.
{% endhint %}
***
Troubleshooting
* Channel results do not reconcile to total sales\
Check for double counting between channels and ensure that volumes are partitioned correctly.
* Mix shifts create unexpected swings in margin\
Verify that unit cost and channel specific costs are correctly allocated and that price differences are correctly applied.
* Model becomes too complex with many channels and partners\
Group smaller channels or partners into aggregate buckets and only model the largest or most strategically important ones in detail.
***
## Related guides
* [Build a Multi Entity Group Model](/how-tos/core-modelling/build-a-multi-entity-group-model)
* [Build a Multi Period Comparison Dashboard](/how-tos/dashboards-and-reporting/build-a-multi-period-comparison-dashboard)
* [Revenue Variables: what is, rules, what it affects](/help/drivers-variables-and-timing/revenue-variables)
* [Modifier Driver Fields](/syntax/drivers-syntax/modifier-driver-fields)
# ๐ Logistics, Transport & Fleet
# Fleet Utilisation & Cost Modelling
This use case explains how to model fleet utilisation and operating cost for logistics, transport and fleet based businesses in Model Reef.
You will:
* Represent vehicles and fleets in the branch structure.
* Define utilisation drivers such as kilometres, hours, drops or loads.
* Build cost models covering fuel, maintenance, tyres, tolls, drivers and overheads.
* Connect fleet utilisation and cost into P\&L, Cashflow and Cash Waterfall.
Model Reef is not a telematics or route planning system. It sits above those tools as a planning and financial modelling layer.
## When to use this pattern
Use this pattern when:
* You operate a fleet of trucks, vans, buses or specialist vehicles.
* Vehicle utilisation and operating cost are major drivers of profitability.
* You want to compare routes, contracts, depots or customer groups on a consistent economic basis.
* You need a full three statement view of fleet operations, not just unit metrics.
You will often combine this pattern with:
* **Route or Region Profitability**
* **Fuel and Maintenance Forecasting**
* **Asset Replacement Planning**
## Architecture overview
Fleet utilisation and cost modelling uses four main layers:
* Fleet structure
* Branches per region, depot or fleet segment.
* Optional sub branches for vehicle types or contracts.
* Utilisation drivers
* Kilometres, hours, loads or drops per vehicle or fleet group.
* Load factors and empty running assumptions.
* Cost drivers
* Fuel burn per kilometre or hour.
* Maintenance, tyres and tolls.
* Driver wages and oncosts.
* Insurance and registration.
* Financial outputs
* Cost per kilometre, per hour, per drop or per tonne.
* Fleet cost and margin per route, depot, contract or customer.
* Integration with P\&L, Cashflow and valuation.
{% stepper %}
{% step %}
### Set up branches for fleet and depots
Start by deciding how you want to view performance. Common approaches are:
* Branches per depot or operating centre.
* Branches per region (for example North, South, Metro, Regional).
* Branches per fleet type (linehaul, last mile, refrigerated, bulk).
For example:
* `Group`
* `Region - North`
* `Region - South`
* `Region - Metro`
Within each region, you can add sub branches for depots or specific fleets if needed.
Keep branch structure aligned with how operations and finance think about accountability and reporting.
{% endstep %}
{% step %}
### Define utilisation drivers
In the Data Library, create drivers that describe how your fleet is used, for example:
* `Kilometres per Period - Linehaul Fleet - North`.
* `Kilometres per Period - Last Mile Fleet - Metro`.
* `Operating Hours per Period - Bus Fleet`.
* `Drops per Period - Last Mile Fleet`.
* `Tonne Kilometres per Period` where relevant.
You may also define:
* Load factors (for example average trailer fill percentage).
* Empty running percentage (how many kilometres are unproductive).
These drivers can be created from:
* Historical telematics or odometer data.
* Forecast route volumes and network plans.
* Contract commitments.
Store them as time series so they can grow, shrink or respond to scenario changes.
{% endstep %}
{% step %}
### Build fuel and variable operating cost per kilometre or hour
For each fleet group, define unit cost drivers such as:
* `Fuel Burn per 100 km - Linehaul Fleet`.
* `Fuel Price per Litre`.
* `Maintenance Cost per km`.
* `Tyre Cost per km`.
* `Tolls per km` where toll roads are used heavily.
Compute a composite variable cost per kilometre or hour, for example:
* `Variable Cost per km - Linehaul Fleet = Fuel Burn per km ร Fuel Price per Litre plus Maintenance Cost per km plus Tyre Cost per km plus Tolls per km`.
Then create COGS or Opex variables such as:
* `COGS - Variable Fleet Cost - Linehaul North = Kilometres per Period - Linehaul North ร Variable Cost per km - Linehaul Fleet`.
Typing these as **COGS** ensures they reduce gross margin correctly and flow through to the Cashflow Statement and Cash Waterfall when timing is applied.
{% endstep %}
{% step %}
### Model fixed and semi fixed fleet costs
In addition to variable costs, fleets incur fixed or semi fixed costs, for example:
* Vehicle lease or finance payments.
* Depreciation if you own vehicles, modelled as Asset variables.
* Insurance and registration.
* Driver base salaries (often Staff variables).
* Depot rent and overheads (Opex).
For each region or depot, create variables such as:
* `Staff - Drivers - North`.
* `Opex - Insurance and Registration - Fleet`.
* `Opex - Depot Rent - North`.
* `Asset - Vehicles - North` for capitalised vehicles with depreciation.
Ensure timing rules reflect when cash actually leaves the bank (for example monthly lease payments, annual insurance or registration).
{% endstep %}
{% step %}
### Compute fleet unit economics
With utilisation and cost variables in place, build unit economic metrics such as:
* `Cost per km` by fleet type and region.
* `Cost per hour` where relevant.
* `Cost per drop` for last mile operations.
* `Cost per tonne kilometre` for bulk freight.
You can implement these as:
* Custom chart formulas, or
* Variables that divide total cost by total utilisation drivers.
For example:
* `Cost per km - North = Total Fleet Cost - North รท Total Kilometres - North`.
Connect these to route or region level revenue where you have **Route or Region Profitability** configured, so you can view:
* Margin per km.
* Margin per trip or route.
* Margin per contract or lane.
{% endstep %}
{% step %}
### Link fleet modelling to P\&L, cashflow and valuation
Because all fleet costs are represented as variables with correct types and timing:
* P\&L will show fleet cost lines in COGS, staff and Opex.
* Balance Sheet will capture vehicles as Assets and associated debt as Liabilities.
* Cashflow and Cash Waterfall will show fuel, maintenance, lease, debt and capex payments over time.
You can then:
* Test different utilisation and cost assumptions in scenarios.
* See how fleet decisions affect overall cash requirements and valuation.
* Compare the economics of owning versus leasing or outsourcing routes.
{% endstep %}
{% step %}
### Use scenarios to test fleet strategies
Clone the model into scenario models to represent different fleet strategies, for example:
* Higher utilisation of existing fleet with minimal growth in fleet size.
* Fleet expansion to support new contracts or geographies.
* Increased outsourcing of certain routes to third party carriers.
* Electrification or alternative fuels with different capex and operating cost profiles.
In each scenario, adjust:
* Utilisation drivers (kilometres, hours, drops).
* Variable cost per kilometre or hour (fuel, maintenance, tyres).
* Fixed cost structures (leases, assets, staff).
* Revenue per route or region in the connected route profitability models.
Compare scenarios using:
* Fleet cost and margin per route, region or customer.
* Required capex and financing.
* Cashflow and funding needs.
* Valuation and risk metrics.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
### Check your work
* Fleet groupings in branches match how operations view the network.
* Kilometre, hour and drop drivers align with historical patterns when calibrated.
* Unit cost assumptions for fuel, maintenance and other running costs are realistic.
* P\&L and cashflow outputs look plausible relative to recent financial results.
{% endhint %}
## Troubleshooting
Cost per km looks too high or too low
Check that you have captured all relevant cost components and that you are dividing by the correct utilisation driver for that fleet.
Fleet looks over utilised in the model
Compare kilometres and hours per vehicle to realistic limits and adjust utilisation or fleet size assumptions.
Difficult to maintain at individual vehicle level
Aggregate vehicles into homogeneous fleets and only model individual units where they are unusually large or important.
## Related guides
* [Build a Staffing Cost Model](/how-tos/operations-and-unit-economics/build-a-staffing-cost-model)
* [Build a Central Assumption Library](/how-tos/data-workflows-and-automation/build-a-central-assumption-library)
* [Differences vs Ticker Fundamentals Import](/help/importing-from-google-finance-and-yahoo-apis/differences-vs-ticker-fundamentals-import)
* [Operational Driver Fields](/syntax/drivers-syntax/operational-driver-fields)
# Route/Region Profitability
This use case explains how to analyse route and region level profitability for logistics, transport and fleet based businesses using Model Reef.
You will:
* Represent routes, lanes or regions in the branch structure or driver layer.
* Allocate revenue and cost to routes or regions.
* Compute margin per lane, corridor, region or contract.
* Connect route economics to fleet utilisation, fuel, maintenance and asset planning.
The goal is to move beyond fleet wide averages and see which parts of the network generate or destroy value.
## When to use this pattern
Use this pattern when:
* You run scheduled or frequent services on defined routes or lanes.
* Different regions or corridors have materially different economics.
* You want to identify unprofitable segments, customers or routes.
* You need a clean link between pricing, utilisation, cost and margin.
You will often use this in combination with:
* **Fleet Utilisation and Cost Modelling**
* **Fuel and Maintenance Forecasting**
* **Asset Replacement Planning**
## Architecture overview
Route and region profitability uses four elements:
* Structural representation
* Branches per region, route group or contract.
* Drivers per lane or corridor where very detailed.
* Revenue allocation
* Revenue per route, lane, corridor or region.
* Customer or contract specific pricing.
* Cost allocation
* Direct costs such as fuel, maintenance, tolls and drivers.
* Shared costs allocated between routes or regions.
* Profitability outputs
* Margin per route, lane, corridor or region.
* Comparison dashboards and scenario views.
{% stepper %}
{% step %}
### Choose route and region granularity
Decide at what level you want profitability:
* Regions (for example North, South, East, West).
* Corridors (for example City A to City B).
* Key contracts or customers.
* Some combination of the above.
Use branches for the main reporting level, for example:
* `Group`
* `Region - North`
* `Region - South`
* `Region - Metro`
Within each region, you can use:
* Sub branches for key corridors or contracts, or
* Drivers that allocate revenue and cost across lanes within a region.
Avoid modelling every minor route individually unless your network is small or highly concentrated.
{% endstep %}
{% step %}
### Allocate revenue to routes or regions
Define revenue variables that belong to the relevant region or route branch, for example:
* `Revenue - Linehaul - Region North`.
* `Revenue - Last Mile - Region Metro`.
* `Revenue - Contract Customer X - Region South`.
You can build these variables from drivers such as:
* Tonnage or pallets per lane.
* Price per tonne kilometre or per pallet.
* Fixed contract fees plus variable components.
Alternatively, if your revenue forecast is built at a higher level, you can allocate total revenue down to regions or routes using allocation drivers, for example:
* `Share of Revenue - Region North`.
* `Share of Revenue - Region South`.
Then compute:
* `Revenue - Region North = Total Revenue ร Share of Revenue - Region North`.
Ensure revenue variables are typed as **Revenue** so they flow correctly through P\&L and cash.
{% endstep %}
{% step %}
### Allocate direct operating costs by route or region
Where possible, allocate direct costs to the same branches as revenue. For example, in the `Region - North` branch, include:
* `COGS - Fuel - Region North`.
* `COGS - Maintenance - Region North`.
* `Staff - Drivers - Region North`.
* `Opex - Tolls and Parking - Region North`.
If you use **Fleet Utilisation and Cost Modelling**, you can:
* Compute total fleet cost per region or fleet group.
* Split that total across routes within the region based on utilisation drivers such as kilometres or hours per route.
The aim is to ensure that each region or route bears the direct costs that arise from the activity it generates.
{% endstep %}
{% step %}
### Allocate shared costs where necessary
Some costs are shared across multiple regions or routes, for example:
* Central dispatch and planning staff.
* Shared depots or hubs.
* Head office costs.
You can allocate these using drivers such as:
* Proportion of revenue per region.
* Proportion of kilometres per region.
* Proportion of vehicles or fleet cost per region.
Implement this either by:
* Creating allocation variables in each region branch that draw from central cost drivers, or
* Using custom report formulas that allocate shared costs when reporting profitability.
The level of sophistication should match your decision needs. For many fleets, a simple revenue or kilometre based allocation is sufficient for planning.
{% endstep %}
{% step %}
### Compute margin per route or region
For each region or route branch, create variables or report rows for:
* `Gross Margin = Revenue minus Direct Fleet Costs`.
* `Contribution after Regional Overheads`.
* `Operating Profit after Allocations` where you choose to include allocated central costs.
Use dashboards to present:
* Margin per region over time.
* Margin per route or corridor where you model at that level.
* Ranking of routes or regions by margin or margin percentage.
* Heatmaps of profitability by region and product or service type.
This reveals which routes, customers or geographies are structurally strong and which require action.
{% endstep %}
{% step %}
### Connect to pricing and fleet decisions
Because route and region profitability sits on top of the same fleet and cost structures used elsewhere, you can:
* Test price increases or discounts on specific routes or contracts.
* See how changes in fuel price or utilisation affect route margins.
* Evaluate the economics of adding or removing services in a region.
* Support decisions about moving work to contract carriers where they can perform more efficiently.
This connection helps move pricing and network design conversations from anecdote to modelled evidence.
{% endstep %}
{% step %}
### Use scenarios for network optimisation
Clone the model into scenario models that represent alternative network designs, for example:
* Rationalising unprofitable routes or depots.
* Opening new depots or entering new regions.
* Shifting particular customers or corridors to different fleet types.
* Outsourcing selected lanes to third party carriers.
In each scenario, adjust:
* Branch structure where necessary.
* Revenue allocation and pricing assumptions.
* Cost and utilisation drivers per region and route.
* Fleet size and composition in the connected fleet models.
Compare scenarios using:
* Margin per route or region.
* Total profitability and valuation.
* Fleet capex and utilisation implications.
* Cashflow and risk metrics.
{% endstep %}
{% endstepper %}
## Check your work
* Regions or routes in the model reflect how management actually thinks about the network.
* Revenue attribution to routes or regions is based on credible data or consistent rules.
* Cost allocations are transparent and simple enough to explain.
* Profitability patterns align directionally with the business narrative and available reports when calibrated.
## Troubleshooting
Some routes appear impossibly profitable or unprofitable
Check that both revenue and cost are being allocated consistently and that no major cost categories are missing or double counted.
Shared cost allocations dominate the picture
Start by analysing contribution margin before allocations, then layer on allocations separately so you can see both direct and fully loaded views.
Model is too granular to maintain
Aggregate minor routes into corridor or region level views and keep detailed route modelling for only the most important flows.
## Related guides
* [Build a DCF Model (FCFF)](/how-tos/valuation/build-a-dcf-model-fcff)
* [Build a Debt Schedule & Covenants Model](/how-tos/investment-and-transactions/build-a-debt-schedule-and-covenants-model)
* [Dividend Variables: what is, rules, what it affects](/help/drivers-variables-and-timing/dividend-variables)
* [Overriding Drivers](/syntax/scenario-syntax/overriding-drivers)
# Fuel & Maintenance Forecasting
This use case explains how to forecast fuel and maintenance costs for logistics, transport and fleet based businesses using Model Reef.
You will:
* Use utilisation drivers such as kilometres or hours to drive fuel and maintenance.
* Separate price and volume effects on fuel cost.
* Model routine and major maintenance events.
* Connect fuel and maintenance to route profitability, asset planning and cashflow.
The aim is to move fuel and maintenance from a single line guess to a driver based, transparent structure that can be stress tested in scenarios.
## When to use this pattern
Use this pattern when:
* Fuel and maintenance are major cost categories.
* You want to understand sensitivity to fuel price, efficiency and utilisation.
* You need to plan major services, overhauls or rebuilds.
* You want fuel and maintenance decisions visible in P\&L, cash and valuation.
You will usually combine this with:
* **Fleet Utilisation and Cost Modelling**
* **Route and Region Profitability**
* **Asset Replacement Planning**
***
## Architecture overview
Fuel and maintenance forecasting uses:
1. Utilisation drivers
* Kilometres or hours per fleet group, region or vehicle type.
2. Fuel cost structure
* Fuel burn per kilometre or hour.
* Fuel price and taxes.
* Efficiency improvements or deterioration.
3. Maintenance cost structure
* Routine maintenance cost per kilometre or hour.
* Major services or overhauls based on intervals.
* Tyres and other wear items.
4. Financial integration
* COGS and Opex variables for fuel and maintenance.
* Cashflow impact through payment timing.
* Scenario analysis for price and utilisation shocks.
***
{% stepper %}
{% step %}
### Define utilisation drivers
Ensure your model already has utilisation drivers from fleet modelling, for example:
* `Kilometres per Period - Linehaul Fleet`.
* `Kilometres per Period - Last Mile Fleet`.
* `Operating Hours per Period - Bus Fleet`.
If not, create these based on:
* Historical odometer or telematics data.
* Planned schedule and route patterns.
* Contract commitments and forecasts.
These drivers will be the base for both fuel and maintenance calculations.
{% endstep %}
{% step %}
### Build fuel burn and price drivers
In the Data Library, define fuel related drivers such as:
* `Fuel Burn per 100 km - Linehaul Fleet`.
* `Fuel Burn per 100 km - Last Mile Fleet`.
* `Fuel Price per Litre` by region or country.
* `Fuel Efficiency Modifier` to capture improvements or deterioration over time.
Calculate fuel cost per kilometre as:
* `Fuel Cost per km = (Fuel Burn per 100 km รท 100) ร Fuel Price per Litre ร Fuel Efficiency Modifier`.
You can vary fuel price over time to reflect known or expected changes in fuel markets or tax regimes.
{% endstep %}
{% step %}
### Create fuel cost variables
For each fleet group or region, create COGS variables such as:
* `COGS - Fuel - Linehaul North`.
* `COGS - Fuel - Last Mile Metro`.
Define formulas such as:
* `COGS - Fuel - Linehaul North = Kilometres per Period - Linehaul North ร Fuel Cost per km - Linehaul Fleet`.
Set appropriate timing:
* Occurrence when kilometres are driven.
* Payment delay based on supplier terms (for example 14 or 30 days).
This ensures that:
* Fuel expense hits P\&L when utilisation occurs.
* Cash outflows follow supplier payment terms.
* AP and cash effects are visible in Balance Sheet and Cashflow outputs.
{% endstep %}
{% step %}
### Model routine maintenance cost
Routine maintenance often scales with utilisation. In the Data Library, define drivers such as:
* `Routine Maintenance Cost per km - Linehaul Fleet`.
* `Routine Maintenance Cost per km - Last Mile Fleet`.
* Or per hour where that is more appropriate.
Then create COGS or Opex variables such as:
* `COGS - Routine Maintenance - Linehaul North`.
* `COGS - Routine Maintenance - Last Mile Metro`.
Formulas typically look like:
* `Routine Maintenance Cost = Kilometres per Period ร Maintenance Cost per km`.
Again, use timing to reflect payment terms with workshops or internal recharge arrangements.
{% endstep %}
{% step %}
### Model major maintenance, overhauls and tyres
Major maintenance events and tyres do not always scale linearly. To capture these, you can:
* Schedule major services at intervals based on utilisation, for example every X kilometres.
* Use schedules or seasonality style drivers to reflect expected timing.
* Represent costs as one off or lumpy variables in the periods where major work is expected.
Examples:
* `COGS - Major Overhaul - Truck Group A` scheduled every three to five years.
* `COGS - Tyres - Linehaul Fleet` based on expected tyre life in kilometres.
You can approximate this by:
* Averaging major costs into a cost per kilometre if you want a smooth view.
* Or explicitly scheduling major events if you want to see lumpy cash outflows.
{% endstep %}
{% step %}
### Integrate with route profitability and asset planning
Once fuel and maintenance costs are driven by utilisation:
* Route and region level profitability can include realistic running costs.
* You can compare routes with different distance, speed and road conditions.
* Asset Replacement Planning can incorporate the rising cost of maintaining older vehicles.
For example, use a driver such as:
* `Maintenance Escalation for Vehicles Over X Years Old`.
Apply this modifier to maintenance cost per kilometre as the fleet ages to reflect higher maintenance costs for older units.
{% endstep %}
{% step %}
### Use scenarios for fuel price and utilisation shocks
Clone your base model into scenario models to explore:
* Fuel price spikes or reductions.
* Efficiency improvements from newer vehicles or driver training.
* Changes in utilisation due to new contracts, lost work or network redesign.
* Accelerated or deferred major maintenance.
In each scenario, adjust:
* Fuel price and efficiency drivers.
* Maintenance cost per kilometre and major event schedules.
* Utilisation drivers per fleet group and region.
Compare scenarios using:
* Total fuel and maintenance cost.
* Cost per kilometre or per route.
* Margin and cash impacts.
* Required pricing changes to maintain profitability.
{% endstep %}
{% endstepper %}
***
{% hint style="info" %}
### Check your work
* Utilisation drivers align with historical data when the model is calibrated.
* Fuel burn and unit cost assumptions are based on real fleet performance and current fuel prices.
* Maintenance cost patterns and major events roughly match workshop records or fleet manager expectations.
* The split between routine and major maintenance is useful for planning but not unnecessarily complex.
{% endhint %}
***
## Troubleshooting
Fuel cost in the model is much higher or lower than actuals
Review fuel burn, price and utilisation assumptions and confirm that distance units are consistent across all drivers and variables.
Maintenance cost appears too smooth or too lumpy
Adjust the balance between cost per kilometre and explicit major events to reflect the level of detail you need.
Scenario results are hard to interpret
Use dashboards that separate fuel and maintenance from other costs and focus on unit cost metrics such as cost per kilometre to clarify patterns.
***
## Related guides
* [Build a Dilution / Cap Table Impact Model](/how-tos/investment-and-transactions/build-a-dilution-cap-table-impact-model)
* [Build a Discount Rate Scenario Model](/how-tos/valuation/build-a-discount-rate-scenario-model)
* [Divisional Structures](/help/building-your-model/divisional-structures)
* [Overriding Variables](/syntax/scenario-syntax/overriding-variables)
# Asset Replacement Planning
This use case explains how to plan asset replacement, capex and lifecycle cost for fleets in logistics, transport and similar asset intensive businesses using Model Reef.
You will:
* Represent vehicles and major equipment as Assets and Liabilities where financed.
* Model acquisition, depreciation and disposal.
* Plan replacement cycles and capex.
* Connect replacement strategies to operating cost, cashflow and valuation.
The aim is to support decisions about when to replace or refurbish vehicles, how large the fleet should be and how to fund replacements.
## When to use this pattern
Use this pattern when:
* You manage a fleet of trucks, buses, vans or specialist vehicles.
* Replacement timing has a major impact on maintenance cost, downtime and safety.
* You need to plan capex and funding requirements over multiple years.
* You want replacement strategies reflected in P\&L, Balance Sheet, Cashflow and valuation.
You will normally combine this with:
* **Fleet Utilisation and Cost Modelling**
* **Fuel and Maintenance Forecasting**
* **Route and Region Profitability**
## Architecture overview
{% stepper %}
{% step %}
### Fleet asset register
* Groups of vehicles by type, age and specification.
* Opening balances and remaining life.
{% endstep %}
{% step %}
### Lifecycle and replacement rules
* Target replacement age or kilometres.
* Refurbishment or mid life upgrade rules.
* Residual value assumptions.
{% endstep %}
{% step %}
### Capex and funding variables
* New asset purchases.
* Lease or loan funding.
* Depreciation and interest.
{% endstep %}
{% step %}
### Operating cost integration
* Maintenance, fuel and downtime changes with age.
* Cashflow and valuation impacts.
{% endstep %}
{% step %}
### Build a simple fleet asset register
In the model, represent vehicles at a level of aggregation that is easy to maintain, for example:
* By vehicle type (prime movers, rigid trucks, vans, buses).
* By age band (0 to 3 years, 4 to 7 years, 8 plus years).
* By region or depot where necessary.
Create Asset variables such as:
* `Assets - Vehicles - Prime Movers - North`
* `Assets - Vehicles - Vans - Metro`
Set opening balances based on current fleet book value or replacement cost and set useful life and residual value assumptions for each group.
If you wish, you can keep a separate off-model register spreadsheet and import totals into Model Reef.
{% endstep %}
{% step %}
### Define replacement and lifecycle drivers
In the Data Library, create drivers that describe lifecycle policies, for example:
* `Target Replacement Age - Prime Movers` (in years)
* `Target Replacement Kilometres - Linehaul Units`
* `Residual Value Percentage at Replacement`
* `Refurbishment Cost per Vehicle at Mid Life`
You can also define:
* Replacement rate per year as a percentage of fleet size.
* Different policies by region or duty cycle if relevant.
These drivers give structure to when and how assets are replaced or refurbished.
{% endstep %}
{% step %}
### Plan replacement volumes and timing
Using the asset register and lifecycle drivers, estimate how many vehicles need replacement each period, for example:
* `Vehicles to Replace - Prime Movers - Year N` based on age or kilometres.
* `Vehicles to Replace - Vans - Metro` using a replacement rate per year.
You can compute this analytically within Model Reef using drivers and formulas or prepare a replacement schedule externally and import it as a driver.
Create Asset and Capex variables such as:
* `Capex - New Vehicles - Prime Movers`
* `Capex - New Vehicles - Vans - Metro`
These should reflect purchase cost and purchase timing.
{% endstep %}
{% step %}
### Model funding, depreciation and disposal
For each capex variable, decide how the purchase is funded:
* Direct cash purchase.
* Lease agreements.
* Bank loans or asset finance.
Implement:
* Asset variables for the new vehicles with appropriate useful life and depreciation method.
* Liability variables for loans or leases where relevant, with drawdowns, interest and repayments.
* Optional disposal variables to remove old vehicles, including any cash received for sale and residual book value impact.
Because all of this uses the standard Asset and Liability logic in Model Reef:
* P\&L will show depreciation and interest.
* Balance Sheet will show asset and loan balances.
* Cashflow will show capex, loan flows and lease or repayment cash outflows.
* Cash Waterfall will show capex and financing flows below EBITDA.
{% endstep %}
{% step %}
### Link age and replacement to operating cost
To connect replacement planning to operating cost:
* Use age or lifecycle drivers to adjust maintenance cost per kilometre or per vehicle, as described in **Fuel and Maintenance Forecasting**.
* Apply higher maintenance cost and potentially higher fuel consumption to older vehicle bands.
* Reduce maintenance cost and fuel consumption for new vehicles.
This allows you to see:
* The operating cost benefit of renewing the fleet earlier.
* The cost of running older vehicles for longer.
* Trade offs between capex and operating cost.
You can implement this using modifiers such as:
* `Maintenance Cost Modifier - Vehicles Over X Years`
* `Fuel Efficiency Modifier - New Vehicles`
{% endstep %}
{% step %}
### Build dashboards for fleet age, capex and cost
Create dashboards that show:
* Fleet size and age profile over time.
* Annual capex for replacement and any growth capex.
* Maintenance cost and downtime proxies by age band.
* Total cost of ownership per vehicle type (capex plus operating cost).
You can also show:
* Differences between regions or depots.
* Impact of replacement strategies on cash and debt.
* Contribution of fleet changes to valuation via the Valuation Engine.
{% endstep %}
{% step %}
### Use scenarios for replacement strategies
Clone your base model into scenario models representing different replacement strategies, for example:
* Replace vehicles earlier (shorter lifecycle, higher capex, lower maintenance).
* Run vehicles longer (lower capex in the short term, higher maintenance and potential risk).
* Accelerated fleet renewal for safety, compliance or brand reasons.
* Transition to alternative fuel vehicles with different cost structures.
In each scenario, adjust:
* Lifecycle and replacement drivers.
* Capex volumes and timing.
* Funding mix between cash, leases and loans.
* Operating cost modifiers for maintenance and fuel.
Compare scenarios using:
* Total cost of ownership and cost per kilometre.
* Capex and funding requirements.
* P\&L and cashflow patterns.
* Valuation and risk metrics.
{% endstep %}
{% endstepper %}
## Check your work
* The fleet asset register is at a level of detail you can maintain without excessive effort.
* Replacement drivers reflect realistic fleet policies or the policies you wish to test.
* Capex and depreciation patterns align broadly with historical behaviour when calibrated.
* Maintenance and fuel cost changes with age reflect fleet manager expectations.
## Troubleshooting
Capex spikes are unmanageable in some years
Smooth replacement schedules where possible, or test alternative strategies that stagger replacements while remaining realistic.
Model shows a shrinking or expanding fleet unexpectedly
Make sure replacement volumes and any growth capex are set in a way that preserves or deliberately changes fleet size.
Difficult to reconcile model asset balances with accounting figures
Treat the model as a planning tool. Focus on forward looking profiles and major trends, and calibrate opening balances and depreciation rules to approximate current book values.
## Related guides
* [Scenarios & Planning](/how-tos/scenarios-and-planning)
* [Build a Driver Based Forecast](/how-tos/core-modelling/build-a-driver-based-forecast)
* [Driver Escalation Rules](/help/drivers-variables-and-timing/driver-escalation-rules)
* [Payment Terms UI](/syntax/timing-syntax/payment-terms-ui)
# ๐ฅ Healthcare, Clinics & Allied Health
# Practitioner Utilisation Model
This use case explains how to model practitioner utilisation for healthcare, clinics and allied health practices in Model Reef.
You will:
* Represent clinicians and teams in the branch structure or driver layer.
* Define capacity in hours, sessions or appointments per practitioner.
* Model booked time, no shows and billable utilisation.
* Connect utilisation to revenue, staffing cost and clinic profitability.
Model Reef is not a practice management or booking system. It operates above those tools as a planning and financial modelling engine.
***
## When to use this pattern
Use this pattern when:
* Revenue is driven primarily by clinician time.
* You want to understand capacity, utilisation and throughput per practitioner or per clinic.
* You need to test scenarios such as adding or removing clinicians, changing hours or shifting case mix.
* You want clinical activity wired cleanly into P\&L, cashflow and valuation.
It is often combined with:
* **Clinic Level Profitability**
* **Medicare or Private Billing Forecast**
* **Multi Clinic Consolidation**
***
## Architecture overview
The practitioner utilisation model has four layers:
* **Structure**
* Branches per clinic, service line or team.
* Practitioner counts and mix as drivers.
* **Capacity drivers**
* Available hours or sessions per practitioner.
* Working days, weeks and holidays.
* Non clinical time assumptions.
* **Utilisation and booking drivers**
* Booked time percentage.
* No show and cancellation rates.
* Paid time, bulk billed time and gap time.
* **Financial outputs**
* Billable hours and sessions.
* Revenue per practitioner and per clinic.
* Staff and overhead cost per practitioner.
* Margin per clinic and for the group.
***
{% stepper %}
{% step %}
### Decide how to represent practitioners
Choose a level of detail that is easy to maintain:
* Individual practitioners for small clinics or key personnel.
* Practitioner types (GP, physio, psychologist, specialist) for larger organisations.
* FTE groups by clinic and discipline.
In the Data Library, create drivers such as:
* `FTE Practitioners - GP - Clinic A`.
* `FTE Practitioners - Physio - Clinic B`.
* `FTE Practitioners - Psychologist - Group`.
These will be used to drive capacity and cost.
{% endstep %}
{% step %}
### Define capacity drivers
For each practitioner type and clinic, define capacity assumptions, for example:
* `Clinical Hours per FTE per Week`.
* `Weeks Worked per Year`.
* `Sessions per Hour` (for example short consults versus long consults).
* `Non Clinical Time Percentage` (admin, meetings, training).
Calculate:
* `Gross Available Hours = FTE ร Hours per Week ร Weeks per Year รท Number of Periods`.
* `Clinical Hours = Gross Available Hours ร (1 minus Non Clinical Time Percentage)`.
Store these as drivers or variables at clinic or practitioner type level, depending on how you want to report.
{% endstep %}
{% step %}
### Model bookings, no shows and utilisation
Define utilisation drivers for each practitioner type and clinic, for example:
* `Booking Rate Percentage` (share of clinical hours that are booked).
* `No Show Percentage`.
* `Cancellation Fill Rate` (how much of cancelled time is refilled).
Approximate billable hours as:
* `Booked Hours = Clinical Hours ร Booking Rate`.
* `Lost Hours to No Shows = Booked Hours ร No Show Percentage ร (1 minus Cancellation Fill Rate)`.
* `Billable Hours = Booked Hours minus Lost Hours to No Shows`.
If you prefer sessions rather than hours, use:
* `Sessions = Billable Hours ร Sessions per Hour`.
These utilisation outputs will drive revenue.
{% endstep %}
{% step %}
### Connect utilisation to revenue
For each practitioner type and billing stream, define revenue drivers such as:
* `Average Fee per Session - Private`.
* `Average Rebate per Session - Medicare or Insurer`.
* `Average Gap Payment per Session`.
Create Revenue type variables per clinic and practitioner group, for example:
* `Revenue - GP - Clinic A`.
* `Revenue - Physio - Clinic B`.
Formulas might look like:
* `Revenue - GP - Clinic A = Billable Sessions - GP - Clinic A ร Average Fee per Session - GP - Clinic A`.
If you split bulk billed, private and gap payments, create separate revenue variables per stream and sum them for total revenue.
Because these variables are typed as Revenue, they will flow into P\&L, Balance Sheet timing and Cashflow automatically when you set payment delays.
{% endstep %}
{% step %}
### Link practitioner utilisation to staffing cost
Create Staff type variables for practitioners, for example:
* `Staff - GP Salaries - Clinic A`.
* `Staff - Physio Salaries - Clinic B`.
* `Staff Oncosts - Super, Pension and Payroll Tax`.
* `Locum or Contractor Costs` if you use external clinicians.
Use FTE and salary drivers, for example:
* `Average Salary per FTE - GP`.
* `Average Contract Rate per Hour - Locum`.
* `Oncost Percentage`.
Formulas might look like:
* `Staff Cost - GP - Clinic A = FTE GPs ร Salary per FTE ร (1 plus Oncost Percentage)`.
This creates a clear view of practitioner revenue and cost that can be used for margin per FTE or per hour analysis.
{% endstep %}
{% step %}
### Build utilisation and margin dashboards
Create dashboards that show:
* Clinical hours versus booked and billable hours per clinic and practitioner type.
* Utilisation percentages and no show rates.
* Revenue and margin per FTE or per billable hour.
* Comparison of performance across clinics or practitioner types.
These dashboards help identify:
* Under utilised practitioners or clinics.
* High performing teams.
* Opportunities to improve booking practices, case mix or scheduling.
{% endstep %}
{% step %}
### Use scenarios for staffing and demand changes
Clone the base model into scenario models to test different utilisation strategies, for example:
* Adding new practitioners or FTE to a clinic.
* Changing hours of operation or session lengths.
* Improving booking and no show rates with reminders or process changes.
* Shifting case mix between low and high fee services.
In each scenario, adjust:
* FTE and capacity drivers.
* Booking, no show and fill rate assumptions.
* Fee schedules and payer mix if relevant.
Compare scenarios using:
* Revenue and margin per practitioner and per clinic.
* Cash requirements and funding needs.
* Valuation changes, especially for multi clinic groups.
{% endstep %}
{% endstepper %}
***
## Check your work
* FTE counts and capacity assumptions align with real rosters and working patterns.
* Utilisation and no show rates look plausible against historical data.
* Revenue per practitioner and per clinic matches recent experience when calibrated.
* The level of detail is sustainable for your team to maintain over time.
***
## Troubleshooting
Utilisation appears unrealistically high or low
Double check that non clinical time is correctly specified and that booking and no show rates are not overlapping or double counted.
Revenue per FTE is far from historical results
Review average fee, payer mix and utilisation assumptions, and reconcile against recent billing reports.
Model is too detailed for a large group
Aggregate practitioners into types or FTE bands by clinic and only model key individuals explicitly where they significantly affect results.
***
## Related guides
* [Build a Forecast from Ticker Fundamentals](/how-tos/data-workflows-and-automation/build-a-forecast-from-ticker-fundamentals)
* [Build a Forward Valuation Using Ticker Fundamentals](/how-tos/valuation/build-a-forward-valuation-using-ticker-fundamentals)
* [Driver Overview](/help/drivers-variables-and-timing/driver-overview)
* [Period Toggle Rules](/syntax/chart-and-table-syntax/period-toggle-rules)
# Clinic-Level Profitability
This use case explains how to model and analyse clinic level profitability for healthcare, clinics and allied health practices using Model Reef.
You will:
* Represent each clinic as a branch in the model.
* Attach practitioner utilisation, revenue and staffing cost to each clinic.
* Add rent, utilities, admin staff and other clinic overheads.
* Produce P\&L and cash views per clinic and in total.
The objective is to understand which clinics are strong, which need improvement, and how changes in staffing, hours or pricing will affect clinic performance.
***
## When to use this pattern
Use this pattern when:
* You operate one or more clinics or practices.
* You want clear P\&L and cash views per clinic.
* You need to assess new clinic openings, closures or relocations.
* You want practitioner and clinic performance aligned in one model.
It is usually combined with:
* **Practitioner Utilisation Model**
* **Medicare or Private Billing Forecast**
* **Multi Clinic Consolidation**
***
## Architecture overview
Clinic level profitability uses:
* Branch structure
* One branch per clinic.
* Optional group and regional branches above.
* Clinic level revenue
* Practitioner revenue per clinic.
* Medicare or insurer rebates and patient gap payments.
* Other income such as room hire or diagnostics.
* Clinic level cost
* Practitioner staffing cost.
* Non clinical staff and admin.
* Rent, utilities, consumables and other overheads.
* Outputs
* P\&L per clinic.
* Cashflow and Cash Waterfall per clinic and for the group.
* Margin comparison across clinics.
***
{% stepper %}
{% step %}
### Step 1: Build a branch tree with one branch per clinic
In the branch tree, create a structure such as:
* `Group`
* `Clinic - City A`
* `Clinic - City B`
* `Clinic - Suburb C`
* `Central Overheads`
If you have regions, insert regional branches between the group and clinics.
Each clinic branch will hold its own revenue and cost variables. The group and any regional branches simply aggregate outputs and can hold central costs.
{% endstep %}
{% step %}
### Step 2: Attach practitioner utilisation and revenue per clinic
Using the **Practitioner Utilisation Model**, ensure each clinic branch has:
* FTE or practitioner count drivers per discipline.
* Capacity and utilisation drivers per clinic.
* Revenue variables per practitioner type and payer type.
Examples of clinic level revenue variables:
* `Revenue - GP - Clinic City A`.
* `Revenue - Physio - Clinic City A`.
* `Revenue - Psychology - Clinic City A`.
* `Revenue - Other Services - Clinic City A`.
All of these should be of type **Revenue** so they flow into P\&L and downstream statements automatically.
{% endstep %}
{% step %}
### Step 3: Add clinic level staffing and overhead cost
Within each clinic branch, create Staff and Opex variables such as:
* `Staff - GP Salaries - Clinic City A`.
* `Staff - Nurses - Clinic City A`.
* `Staff - Admin Team - Clinic City A`.
* `Opex - Rent - Clinic City A`.
* `Opex - Utilities - Clinic City A`.
* `Opex - Medical Consumables - Clinic City A`.
* `Opex - Cleaning and Security - Clinic City A`.
Use drivers such as:
* FTE and salary per FTE.
* Rent per month or per square metre.
* Consumables cost per visit or as a percentage of revenue.
Make sure payment timing reflects actual behaviour:
* Staff paid weekly, fortnightly or monthly.
* Rent and utilities on monthly or quarterly cycles.
* Consumables on supplier terms.
{% endstep %}
{% step %}
### Step 4: Add clinic level capex where relevant
If clinics have significant assets such as:
* Fit outs and refurbishments.
* Diagnostic equipment.
* IT and medical devices.
Create Asset variables per clinic, for example:
* `Assets - Fit Out - Clinic City A`.
* `Assets - Equipment - Clinic City A`.
Set useful life and depreciation assumptions, and link capex and financing using standard Asset and Liability variables where required.
This ensures that each clinic bears its share of depreciation and financing costs in P\&L and cashflow.
{% endstep %}
{% step %}
### Step 5: Represent central overheads separately
Create a `Central Overheads` branch for costs that should not sit with any single clinic, for example:
* Group leadership and administration.
* Central marketing and branding.
* Corporate systems, HR and finance.
* Group debt and equity.
You can later allocate some or all of these overheads to clinics when reporting if desired, but keeping them in a separate branch maintains transparency.
{% endstep %}
{% step %}
### Step 6: Build clinic level and group dashboards
Create dashboards that show, for each clinic:
* Revenue by practitioner type or service line.
* Staff cost and overheads by category.
* Clinic level EBITDA and margin percentage.
* Contribution after central overheads, if you choose to allocate them.
At group level, display:
* Total revenue and EBITDA across all clinics.
* Clinic comparison charts ranked by revenue, EBITDA or margin.
* Simple traffic light or threshold views for underperforming clinics.
These dashboards support operational reviews and strategy discussions.
{% endstep %}
{% step %}
### Step 7: Use scenarios for clinic openings, closures and turnarounds
Clone the base model into scenario models to test situations such as:
* Opening a new clinic in a new location.
* Closing or consolidating underperforming clinics.
* Turning around a clinic with new staff, hours or services.
* Changing central overhead allocation policies.
In each scenario, adjust:
* Branch structure (adding or removing clinics).
* Practitioner and revenue assumptions per clinic.
* Cost, staffing and capex per clinic.
* Central overhead assumptions and allocations if used.
Compare scenarios based on:
* Clinic level and group level profit and cash.
* Payback for new clinics and refurbishments.
* Valuation effects for the group.
{% endstep %}
{% endstepper %}
***
## Check your work
{% hint style="info" %}
* Clinics in the model align with how the organisation reports and manages performance.
* Revenue, staff and overhead cost per clinic reflect recent actuals when calibrated.
* Central overheads are clearly separated and not double counted in clinic branches.
* Scenario results make sense to both finance and operational leaders.
{% endhint %}
***
## Troubleshooting
Some clinics appear implausibly profitable or loss making
Reconcile model revenue and cost assumptions for those clinics to actuals and check that central overheads are not misallocated or omitted.
It is difficult to see the impact of central functions on clinics
Use reports that show both clinic level profit before allocations and profit after allocations, with a clear explanation of allocation drivers.
The model feels too detailed
Group smaller clinics into a combined branch where appropriate and maintain detail for only the largest or most important sites.
***
## Related guides
* [Build a Full Financial Model from Scratch](/how-tos/core-modelling/build-a-full-financial-model-from-scratch)
* [Build a KPI Dashboard](/how-tos/dashboards-and-reporting/build-a-kpi-dashboard)
* [Driver Scenario Interactions](/help/drivers-variables-and-timing/driver-scenario-interactions)
* [Picking Chart Types](/syntax/chart-and-table-syntax/picking-chart-types)
# Medicare/Private Billing Forecast
This use case explains how to forecast Medicare and private billing for healthcare, clinics and allied health practices using Model Reef.
You will:
* Split activity between public scheme rebates and private billing.
* Model schedule fees, rebates and gap payments.
* Represent bulk billed versus privately billed activity.
* Apply claim and payment delays to capture cash timing.
Model Reef does not connect directly to Medicare or private insurer systems. It uses aggregated assumptions and imported billing data to drive a financial forecast.
## When to use this pattern
Use this pattern when:
* You bill a mix of public scheme rebates and private fees.
* You want to understand the impact of payer mix on revenue and cash.
* You need to plan around claim processing times and payment delays.
* You want payer mix wired directly into clinic and group financials.
It is commonly combined with:
* **Practitioner Utilisation Model**
* **Clinic Level Profitability**
* **Multi Clinic Consolidation**
## Architecture overview
{% stepper %}
{% step %}
### Activity and payer mix
* Sessions or consults per practitioner type.
* Split between public scheme billed and private billed activity.
{% endstep %}
{% step %}
### Fee and rebate structure
* Schedule fee or standard fee per service.
* Rebate per service.
* Gap payment per service where applicable.
{% endstep %}
{% step %}
### Claim and cash timing
* Time between service and claim submission.
* Time between claim submission and payment.
* Patient payment timing for gap fees.
{% endstep %}
{% step %}
### Financial outputs
* Revenue from public scheme and private components.
* Receivables where payment is delayed.
* Cashflow and working capital impacts.
{% endstep %}
{% step %}
### Start from practitioner utilisation and sessions
Using the **Practitioner Utilisation Model**, ensure you have:
* Billable sessions or consults per practitioner type and clinic.
* These sessions available as drivers or variables by period.
For each practitioner type and clinic, create drivers for payer mix, for example:
* `Public Scheme Share of Sessions - GP - Clinic A`.
* `Private Billing Share of Sessions - GP - Clinic A`.
* `Gap Eligible Share of Public Scheme Sessions` where relevant.
These shares should sum appropriately across payers.
{% endstep %}
{% step %}
### Define fee and rebate drivers
In the Data Library, create drivers such as:
* `Schedule Fee per Session - GP`.
* `Public Scheme Rebate per Session - GP`.
* `Private Fee per Session - GP`.
* `Average Gap Payment per Session - GP`.
You may vary these by:
* Practitioner type.
* Clinic or region.
* Service category (standard consult, long consult, procedure).
These drivers can be updated when schedule fees change or when you adjust private fee policies.
{% endstep %}
{% step %}
### Build revenue variables per payer and clinic
For each clinic and practitioner type, create Revenue variables for each billing stream, for example:
* `Revenue - Public Scheme - GP - Clinic A`.
* `Revenue - Private Billing - GP - Clinic A`.
* `Revenue - Gap Payments - GP - Clinic A`.
Define formulas such as:
* `Sessions - Public Scheme - GP - Clinic A = Total GP Sessions - Clinic A ร Public Scheme Share`.
* `Revenue - Public Scheme - GP - Clinic A = Sessions - Public Scheme - GP - Clinic A ร Public Scheme Rebate per Session - GP`.
* `Revenue - Private Billing - GP - Clinic A = Sessions - Private Billing - GP - Clinic A ร Private Fee per Session - GP`.
* `Revenue - Gap Payments - GP - Clinic A = Sessions - Public Scheme Gap Eligible - GP - Clinic A ร Average Gap Payment per Session - GP`.
Ensure all variables are typed as **Revenue**.
You can then create aggregate variables or rely on reports to sum:
* Public scheme revenue per clinic and in total.
* Private billed revenue per clinic and in total.
* Gap revenue per clinic and in total.
{% endstep %}
{% step %}
### Apply timing to represent claim and payment delays
Use timing settings on revenue variables to reflect:
* Delay between service date and claim submission.
* Delay between claim submission and payment from the public scheme or private insurer.
* Patient payment timing for gap and private fees.
Examples:
* Public scheme rebates paid 7 to 14 days after claim submission.
* Private insurer payments on 30 day cycles.
* Gap fees collected on the day of service for most clinics.
Set delays in the variable timing modal so that:
* P\&L recognises revenue when the service occurs.
* Balance Sheet records receivables where payment is delayed.
* Cashflow and Cash Waterfall show cash inflows when payments are received.
{% endstep %}
{% step %}
### Integrate billing into clinic and group views
Because billing variables sit within clinic branches:
* Clinic level P\&L will show public scheme, private and gap revenue.
* Group level P\&L will aggregate across clinics.
* Cashflow and Cash Waterfall will show payer specific timing effects when segmented.
Use dashboards and reports to display:
* Revenue by payer type per clinic and for the group.
* Payer mix trends over time.
* Receivables related to public scheme and private billing.
* Cashflow sensitivity to changes in claim timing or payer mix.
{% endstep %}
{% step %}
### Use scenarios for policy and pricing changes
Clone the base model into scenario models that represent:
* Changes in public scheme rebates or schedule fees.
* Adjustments to private fee schedules or gap policies.
* Shifts in payer mix between public, private and self pay.
* Changes in claim processing times or bad debt assumptions.
In each scenario, adjust:
* Fee, rebate and gap drivers.
* Payer mix drivers per clinic and practitioner type.
* Timing assumptions for claims and payments.
Compare scenarios on:
* Revenue and margin per clinic and for the group.
* Cashflow and working capital requirements.
* Valuation effects for the group or network.
{% endstep %}
{% endstepper %}
## Check your work
* Session volumes and payer mix align with historical billing data when calibrated.
* Fee and rebate assumptions match current policy and fee schedules.
* Receivables and cash timing profiles resemble actual patterns.
* Scenario changes behave as expected when you simulate policy or pricing shifts.
## Troubleshooting
Modelled public scheme revenue does not match historical claims
Check session counts, payer mix percentages and the rebate per session assumptions, and reconcile against actual billing extracts.
Gap revenue appears too high or too low
Confirm that gap eligibility and average gap per session assumptions reflect real practice, and that you are not double counting private and gap streams.
Cashflow looks too smooth or too volatile
Refine timing assumptions for claim batching and payment cycles and use realistic delay distributions if necessary.
## Related guides
* [Build a Recurring Revenue Forecast](/how-tos/core-modelling/build-a-recurring-revenue-forecast)
* [Build a Rolling Forecast](/how-tos/scenarios-and-planning/build-a-rolling-forecast)
* [How Forecast Logic Is Generated](/help/stock-ticker-fundamentals/how-forecast-logic-is-generated)
* [Scenario Selector](/syntax/understanding-the-interface/scenario-selector)
# Multi-Clinic Consolidation
This use case explains how to consolidate multiple clinics into group level forecasts for healthcare and allied health groups using Model Reef.
You will:
* Represent each clinic as a branch under a group structure.
* Attach practitioner, billing and cost models to each clinic.
* Model central overheads and group level financing.
* Produce consolidated P\&L, Balance Sheet, Cashflow and valuation.
The goal is a single model that supports both clinic level management and group level decision making.
## When to use this pattern
Use this pattern when:
* You operate multiple clinics, practices or locations.
* You want both clinic level and group level financial visibility.
* You need to make decisions about opening, closing, relocating or investing in clinics.
* You plan to raise capital or sell a group and need investor quality outputs.
It brings together:
* Clinic Level Profitability
* Practitioner Utilisation Model
* Medicare or Private Billing Forecast
## Architecture overview
Multi clinic consolidation uses:
* Branch tree
* Group branch at the top.
* One branch per clinic under regions if needed.
* A separate branch for central overheads and group level items.
* Clinic level models
* Practitioner utilisation and billing per clinic.
* Clinic specific staffing and overheads.
* Clinic level capex and assets where appropriate.
* Central functions and group structure
* Central management and administration.
* Shared marketing and systems.
* Group level debt, equity and investment flows.
* Outputs
* P\&L per clinic and for the group.
* Consolidated Balance Sheet and Cashflow.
* Valuation and scenario analysis.
{% stepper %}
{% step %}
### Create branches for each clinic and central overheads
In the branch tree, build a structure such as:
* `Group`
* `Region - North`
* `Clinic - North 1`
* `Clinic - North 2`
* `Region - South`
* `Clinic - South 1`
* `Central Overheads`
Use regions if you want regional reporting, or place clinics directly under the group if the network is small.
Central Overheads is used for group level costs and financing that should not sit within any single clinic.
{% endstep %}
{% step %}
### Attach clinic level profitability models
Within each clinic branch, implement:
* Practitioner utilisation drivers and variables.
* Billing models for public scheme, private and gap revenue.
* Staff, overhead and consumables cost.
* Capex and depreciation where the clinic holds assets.
These follow the Practitioner Utilisation Model and Clinic Level Profitability patterns.
Ensure that variable names and categories are consistent across clinics so reports can aggregate correctly.
{% endstep %}
{% step %}
### Add central overheads and group financing
In the `Central Overheads` branch, include:
* Group leadership, finance, HR and IT staff costs.
* Central marketing, brand and campaigns.
* Corporate systems, licences and other shared services.
At the group branch, or in `Central Overheads` if you prefer, add:
* Group debt and interest.
* Equity injections and shareholder distributions.
* Group level capex that is not tied to a specific clinic.
Keep central items separate from clinic branches so you can view clinic performance before and after group level costs.
{% endstep %}
{% step %}
### Build consolidated reports and dashboards
Use reports and dashboards to show:
Clinic level views
* Revenue and EBITDA per clinic.
* Margin per clinic by practitioner type or service line.
* Trend views for each clinic individually.
Group and region views
* Consolidated P\&L by region and for the group.
* Consolidated Balance Sheet including clinic assets and group debt.
* Cashflow and Cash Waterfall for the entire group.
* Regional or clinic comparison charts.
Because branches roll up automatically in Model Reef, group level outputs will always reflect the sum of all enabled clinics plus central structures.
{% endstep %}
{% step %}
### Apply clinic and region filters
Use branch filters in reports and dashboards to:
* Focus on a single clinic or region.
* Compare clinics within a region side by side.
* View group totals including or excluding specific clinics.
This makes it easy to drill from group numbers down to an individual clinic and back again without manual consolidation work.
{% endstep %}
{% step %}
### Use scenarios for network growth and consolidation
Clone the model into scenario models representing network strategies, for example:
* Opening new clinics in new locations.
* Closing underperforming clinics.
* Relocating or merging clinics.
* Changing central overheads or support structures.
* Acquiring additional practices and integrating them into the group.
For each scenario, adjust:
* Branch structure (adding or removing clinic branches).
* Practitioner and billing assumptions per clinic.
* Cost and capex per clinic.
* Central overhead and financing assumptions.
Compare scenarios using:
* Group and clinic level profit and cash.
* Capital requirements for expansion.
* Valuation and risk metrics for investors or lenders.
{% endstep %}
{% step %}
### Tie consolidation to strategic and investor reporting
Once the multi clinic model is in place, you can:
* Generate investor ready P\&L, Balance Sheet and Cashflow outputs.
* Build Cash Waterfall views that show operational performance and financing flows in one place.
* Produce dashboards and packs for boards, lenders and acquirers.
* Support discussions about clinic portfolio optimisation with quantitative evidence.
Because the same model underpins both clinic level operations and group level strategy, you reduce reconciliation work and maintain a single source of truth.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
### Check your work
* Clinic list and structure match the real network.
* Key clinics are modelled at sufficient detail, and smaller sites are grouped only where appropriate.
* Revenue and cost totals by clinic and for the group reconcile broadly to recent actuals when calibrated.
* Scenario comparisons are intuitive and match leadership expectations about how changes should behave.
{% endhint %}
## Troubleshooting
Group numbers do not match consolidated accounting figures
Check that all clinics are enabled, that central costs are fully represented, and that opening balances for assets and debt are correct.
It is hard to see which clinics drive group performance
Use comparison dashboards that rank clinics by revenue, EBITDA and margin percentage, and segment by region or service mix where helpful.
The model is becoming too complex
Group very small clinics or satellite locations into a combined branch, and focus detailed modelling on the core or flagship sites.
## Related guides
* [Build a Multi Scenario Comparison](/how-tos/scenarios-and-planning/build-a-multi-scenario-comparison)
* [Build a Multi Scenario Valuation Pack](/how-tos/valuation/build-a-multi-scenario-valuation-pack)
* [Drivers, Variables & Timing](/help/drivers-variables-and-timing)
* [Scenario Syntax](/syntax/scenario-syntax)
# ๐ Real Estate & Property
# Property Cash Flow (Rental/Lease)
This use case explains how to model rental and lease cashflows for income producing real estate in Model Reef.
You will:
* Represent each property or asset as its own branch.
* Model rent schedules, indexation, lease up and vacancy.
* Add operating expenses, outgoings and capex.
* Layer in debt service and produce a full property level cashflow and Cash Waterfall.
Model Reef is not a property management system. It is a driver based forecasting engine that consumes summary assumptions for rent, occupancy, expenses and financing and converts them into three statement outputs.
## When to use this pattern
Use this pattern when:
* You own or manage income producing properties.
* You want a forward view of rental income, net operating income and cash.
* You need to see the impact of changes in occupancy, rent levels or funding costs.
* You want a property level view that can also roll into a portfolio model.
You will typically combine this with:
* **Multi Property Portfolio Reporting**
* **Loan or Interest Sensitivity Planning**
* **Development Feasibility Model** for assets under development.
## Architecture overview
The property cashflow model uses four layers. Use the following to design the overall structure and data inputs for each property.
{% stepper %}
{% step %}
### Structure
* One branch per property or per building.
* Optional sub branches per major tenant or space type.
* A portfolio branch above to consolidate.
{% endstep %}
{% step %}
### Rental income drivers
* Rent per square metre or per unit by tenant or space.
* Lease terms, start dates and expiries.
* Indexation and rent review assumptions.
* Vacancy, lease up and free period assumptions.
{% endstep %}
{% step %}
### Operating cost drivers
* Outgoings, repairs and maintenance, utilities, insurance and rates.
* Recoverable versus non recoverable expenses where needed.
{% endstep %}
{% step %}
### Financing and capex
* Debt balances, interest and amortisation.
* Property capex, refurbishments and tenant incentives.
* Equity flows at acquisition, refinance or sale.
{% endstep %}
{% endstepper %}
All of this flows into the standard P\&L, Balance Sheet, Cashflow and Cash Waterfall outputs.
***
{% stepper %}
{% step %}
### Set up branches per property
In the branch tree, create a structure such as:
* `Portfolio`
* `Property - Office A`
* `Property - Retail B`
* `Property - Industrial C`
* `Central Overheads` (if relevant)
Each property branch will hold rent, operating costs, capex and debt for that asset. The portfolio branch is used for consolidated reporting.
If you have many small assets, you can group them into buckets such as `Small Residential` and model them as a pooled asset.
{% endstep %}
{% step %}
### Build rental income drivers
For each property, define rental income using drivers in the Data Library, for example:
* `Net Lettable Area` or number of units.
* `Rent per Square Metre per Year` or rent per unit.
* `Occupancy Rate` or leased area percentage.
* `Vacancy Loss Percentage` for structural vacancy or downtime between leases.
You can either:
* Model at tenant level with explicit leases, or
* Model at property level using average rent and vacancy.
Example revenue variables in a property branch:
* `Revenue - Base Rent - Office A`.
* `Revenue - Car Parking Income - Office A`.
* `Revenue - Other Income - Office A` (signage, storage, etc.).
Formulas might be:
* `Base Rent = Net Lettable Area ร Rent per Square Metre ร Occupancy Rate`.
* `Vacancy Loss = Potential Rent ร Vacancy Loss Percentage`.
* `Net Rent = Base Rent minus Vacancy Loss`.
Set these variables as type **Revenue** so they flow into P\&L and cash.
{% endstep %}
{% step %}
### Add indexation, rent reviews and free periods
To reflect common lease structures, create drivers for:
* `Annual Indexation Rate` (for example CPI or fixed percentage).
* `Market Review Years` or specific review dates.
* `Rent Free Periods` at the start of leases or on renewal.
Implement this with:
* Indexation drivers that step up rent each year or according to schedule.
* Schedules that reduce rent in specific periods for rent free incentives.
* Optional separate variables for incentives that are amortised over the lease for internal analysis.
The level of detail can be adjusted:
* Simple indexation and vacancy only for a quick view.
* Full lease by lease schedules for a single asset transaction model.
{% endstep %}
{% step %}
### Model property operating expenses and outgoings
In each property branch, create Opex variables for:
* `Opex - Repairs and Maintenance`.
* `Opex - Utilities`.
* `Opex - Insurance`.
* `Opex - Council Rates`.
* `Opex - Property Management Fees`.
* `Opex - Cleaning and Security`.
Link these to drivers such as:
* Cost per square metre.
* Percentage of rent.
* Fixed cost per period with occasional steps for known increases.
If some outgoings are recoverable from tenants:
* Either net them into rent by using net rent assumptions, or
* Represent recoveries as separate Revenue variables (for example `Revenue - Outgoings Recovery`) and keep the gross cost visible in Opex.
Set timing to reflect actual billing and payment cycles so cash outflows and payables are realistic.
{% endstep %}
{% step %}
### Add capex, tenant incentives and refurbishment
Use Asset variables to represent major property investments, for example:
* `Assets - Base Building Capex - Office A`.
* `Assets - Refurbishment - Office A`.
* `Assets - Tenant Incentives - Office A` where incentives are capitalised.
Define:
* Capex amounts and timing.
* Useful lives and depreciation rules where appropriate.
* Any residual value assumptions if you want to approximate book values.
Capex will drive:
* Investing cash outflows in the Cashflow Statement and Cash Waterfall.
* Depreciation in the P\&L where relevant.
* Asset balances on the Balance Sheet.
This allows you to see how planned refurbishments and fit outs affect cash and profit.
{% endstep %}
{% step %}
### Layer in debt and financing
If the property is funded by debt, create Liability variables such as:
* `Debt - Senior Loan - Office A`.
* `Debt - Mezzanine Facility - Office A` if applicable.
Specify:
* Opening balance if already drawn.
* Drawdown schedule if funding acquisition or capex.
* Interest rate assumptions (fixed, floating or blended).
* Amortisation or interest only periods.
* Covenants you wish to monitor (typically done in valuation or reporting views).
Because Model Reef handles debt using standard Liability logic:
* Interest will appear in P\&L.
* Loan balances will appear on the Balance Sheet.
* Drawdowns and repayments will be visible in the Cashflow Statement and Cash Waterfall.
{% endstep %}
{% step %}
### Build property level dashboards and metrics
Create dashboards at the property branch level showing:
* Gross rent, vacancy loss and net rent.
* Operating expenses and net operating income.
* Debt service, net cashflow before and after financing.
* Key metrics such as net yield, interest cover and cashflow coverage.
* Capex timing and impact.
At the portfolio branch, you can see:
* Total rental income and NOI across all assets.
* Aggregate capex and debt service.
* Cashflow capacity for distributions or further investment.
{% endstep %}
{% step %}
### Use scenarios for rent, vacancy and financing changes
Clone the model into scenario models to test assumptions such as:
* Higher or lower rent growth.
* Changes in vacancy and lease up periods.
* Alternative capex and refurbishment strategies.
* Different interest rate paths or refinancing structures.
* Disposal or acquisition of properties in the portfolio.
Adjust the relevant drivers and variables in each scenario and compare using:
* Property level and portfolio level P\&L.
* Cashflow capacity under different cases.
* Debt service metrics.
* Valuation outputs from the Valuation Engine.
{% endstep %}
{% endstepper %}
## Check your work
* Rent levels, vacancy and expense ratios match recent evidence when the model is calibrated.
* Lease structures and indexation behaviour are captured at an appropriate level of detail.
* Debt terms and covenants reflect actual or proposed financing documents.
* Property level results aggregate logically into portfolio views.
## Troubleshooting
Net operating income looks inconsistent with history
Check occupancy, rent per square metre and expense assumptions. Reconcile against historical statements and adjust drivers accordingly.
Cashflow is too volatile or too smooth
Refine timing of rent receipts, expense payments and capex, and check that you are not double counting or omitting large items such as incentives.
Too many minor tenants or small properties to model individually
Aggregate into representative groups or pooled assets and only model major assets or anchor tenants individually.
## Related guides
* [Build a Live Actuals Model Using Xero](/how-tos/data-workflows-and-automation/build-a-live-actuals-model-using-xero)
* [Build a Machine Readable Model for Automation](/how-tos/data-workflows-and-automation/build-a-machine-readable-model-for-automation)
* [EBITDA Logic](/help/financial-outputs-and-valuation/ebitda-logic)
* [Scenario Toggle Behaviour](/syntax/scenario-syntax/scenario-toggle-behaviour)
# Development Feasibility Model
This use case explains how to build a development feasibility model for real estate projects in Model Reef.
You will:
* Represent a property development as its own branch or model.
* Model land acquisition, planning and construction costs over time.
* Forecast sales or leasing revenue and associated costs.
* Layer in debt and equity funding and compute project and equity returns.
Model Reef is not a CAD or project management system. It focuses on financial feasibility, funding and return analysis.
***
## When to use this pattern
Use this pattern when:
* You are assessing a new development or redevelopment project.
* You need to understand cash requirements, drawdowns and returns over the project life.
* You want to test multiple scenarios quickly without rebuilding the model.
* You need investor or lender ready cashflow and return outputs.
You will typically use this as a standalone model per project, and optionally roll selected projects into portfolio views.
***
## Architecture overview
{% stepper %}
{% step %}
### Project structure
* A single branch or model per project, with optional sub branches for stages or uses.
{% endstep %}
{% step %}
### Cost side
* Land acquisition costs and timing.
* Soft costs such as planning, design and fees.
* Hard construction costs and contingencies.
* Marketing, sales and leasing costs.
* Ongoing holding costs such as rates, insurance and interest if capitalised.
{% endstep %}
{% step %}
### Revenue side
* Sales revenue per lot, apartment or area.
* Leasing revenue if the project is held after completion.
* Settlement timing and any staged payments or pre sales.
{% endstep %}
{% step %}
### Funding and returns
* Debt, equity and possibly mezzanine funding.
* Drawdown, interest and repayment profiles.
* Project and equity IRR, NPV and money multiple via the Valuation Engine.
{% endstep %}
{% endstepper %}
***
{% stepper %}
{% step %}
### Set up a project branch or model
Create either:
* A dedicated model for the project, or
* A branch such as `Project - Development A` within a broader model.
If the project is large or needs many scenarios, a separate model is often simpler to manage.
Within the project, you can optionally create sub branches for:
* Stages (Stage 1, Stage 2).
* Uses (Residential, Retail, Office).
{% endstep %}
{% step %}
### Model land and acquisition costs
Create Asset and Opex variables for acquisition related items, for example:
* `Assets - Land Acquisition`.
* `Opex - Stamp Duty and Transaction Costs`.
* `Opex - Legal and Due Diligence Costs`.
Set amounts and timing according to the intended transaction schedule. You can fund land acquisition with equity, debt or a mix:
* Equity contributions as Equity type variables.
* Land loans as Liability variables with drawdowns and interest.
This will drive early cash outflows and asset balances.
{% endstep %}
{% step %}
### Build construction and soft cost schedules
Define drivers and variables for:
* `Hard Construction Cost` per square metre, per unit or per stage.
* `Soft Costs` such as design, consultants, approvals and project management.
* `Contingency` as a percentage of hard or total cost.
* `Holding Costs` such as rates and insurance during development.
Create Opex or Asset variables as appropriate, for example:
* `Capex - Construction - Stage 1`.
* `Capex - Construction - Stage 2`.
* `Opex - Professional Fees`.
* `Opex - Marketing and Presales`.
Spread costs over the construction period using schedules so that:
* P\&L and Cashflow reflect the timing of actual cash outflows.
* Assets on the Balance Sheet represent work in progress where relevant.
{% endstep %}
{% step %}
### Forecast sales or leasing revenue and timing
For build to sell projects, define variables for:
* `Number of Lots or Units`.
* `Average Selling Price per Unit` or price bands.
* `Sales Programme` over time (presales, construction period sales, post completion sales).
* `Settlement Timing` and staged payments if applicable.
Create Revenue variables such as:
* `Revenue - Unit Sales - Stage 1`.
* `Revenue - Unit Sales - Stage 2`.
For build to hold projects, instead:
* Implement a rental cashflow structure similar to **Property Cash Flow (Rental or Lease)** once the asset is complete.
Set timing so that:
* Revenue is recognised when sales or leases occur.
* Cash inflows match expected settlement or lease cash timing.
{% endstep %}
{% step %}
### Add funding structure and interest
Create Liability variables for:
* `Debt - Development Facility`.
* `Debt - Land Facility` if separate.
* `Mezzanine Facility` if used.
Define:
* Maximum facility limits or gearing rules as drivers.
* Drawdowns linked to a share of project costs or to a schedule.
* Interest rates (base plus margin) and whether interest is capitalised.
* Repayment triggers such as sales, completion or refinance.
You can also represent:
* Equity contributions from sponsors or investors as Equity type variables.
* Preferred distributions or waterfalls in reporting or in a simple Equity variable schedule.
Model Reef will then:
* Calculate interest expense and capitalised interest where appropriate.
* Track loan balances and repayments.
* Show funding flows in the Cashflow Statement and Cash Waterfall.
{% endstep %}
{% step %}
### Compute project and equity returns
Use the Valuation Engine to derive return metrics:
* Project level FCFF based on unlevered cashflows.
* Equity level FCFE based on levered cashflows to equity.
From these, Model Reef can produce:
* Project IRR and NPV.
* Equity IRR and NPV.
* Money multiple and payback period.
You can present these via:
* Dashboards for each project.
* Comparison views across projects where the model includes multiple developments.
{% endstep %}
{% step %}
### Use scenarios for pricing, cost and timing risk
Clone the project model into scenario models to test sensitivities such as:
* Changes in sales prices or rental levels.
* Construction cost overruns.
* Delays in approvals or construction.
* Changes in funding terms or availability.
* Different exit strategies (sell down, partial hold, complete hold).
In each scenario, adjust:
* Price and sales drivers.
* Cost and schedule assumptions.
* Funding structure and interest rates.
Compare scenarios using:
* Project and equity IRR and NPV.
* Peak funding and drawdown requirements.
* Cashflow timing and risk.
* Portfolio impact where projects feed into a larger group model.
{% endstep %}
{% step %}
### Check your work
* Cost and revenue assumptions reflect independent data, recent projects or feasibility studies.
* Timing of construction, sales and funding follows a realistic programme.
* Debt limits and covenants align with lender expectations.
* Return metrics are comparable to other feasibility work for the same project.
{% endstep %}
{% endstepper %}
***
## Troubleshooting
Model shows unrealistic returns or losses
Double check cost, price and timing inputs against external references and ensure that you are not missing major categories such as contingency or marketing.
Peak funding appears much higher than expected
Review the timing of land acquisition, construction and sales, and ensure that funding draw rules match how facilities are expected to operate.
Difficult to maintain multiple projects in one model
Use one model per project during feasibility and create a separate consolidation model for portfolio level reporting.
***
## Related guides
* [Build a Seasonality Adjusted Forecast](/how-tos/scenarios-and-planning/build-a-seasonality-adjusted-forecast)
* [Build a Sensitivity Analysis Pack](/how-tos/scenarios-and-planning/build-a-sensitivity-analysis-pack)
* [Editor Permissions](/help/permissions-and-collaboration/editor-permissions)
* [Seasonality Inputs](/syntax/timing-syntax/seasonality-inputs)
# Multi-Property Portfolio Reporting
This use case explains how to consolidate and report across multiple properties in a real estate portfolio using Model Reef.
You will:
* Represent each property as a branch under a portfolio structure.
* Attach rental or development cashflow models per property.
* Add central overheads, group debt and equity where relevant.
* Produce property level and portfolio level P\&L, Cashflow, Cash Waterfall and valuation outputs.
The aim is to have a single model that supports both asset level and portfolio level decision making.
## When to use this pattern
Use this pattern when:
* You own or manage multiple income producing or development properties.
* You want to compare performance and cash generation across assets.
* You need consolidated reporting for lenders, investors or boards.
* You plan to test acquisition, disposal or refinancing strategies at portfolio level.
It typically builds on:
* **Property Cash Flow (Rental or Lease)** for income assets.
* **Development Feasibility Model** for projects.
* **Loan or Interest Sensitivity Planning** for funding.
## Architecture overview
Multi property portfolio reporting uses:
1. **Branch tree**
* Portfolio root branch.
* One branch per property, grouped by region, sector or strategy.
* Central overhead and holding structure branches.
2. **Property level models**
* Rental cashflow models for stabilised assets.
* Development feasibility models for in flight projects.
3. **Central structures**
* Management and head office costs.
* Group level debt and equity.
* Shared capex or corporate assets.
4. **Reporting and dashboards**
* Property level metrics.
* Portfolio level roll ups.
* Scenario comparison views.
{% stepper %}
{% step %}
### Build a portfolio branch structure
Create a branch tree such as:
* `Portfolio`
* `Region - City A`
* `Property - Office A1`
* `Property - Retail A2`
* `Region - City B`
* `Property - Industrial B1`
* `Development Projects`
* `Project - Mixed Use C1`
* `Central Overheads`
This allows you to:
* View assets by region, sector or strategy.
* Keep development projects visible but distinct from stabilised income assets.
* Isolate central overheads from asset level performance.
{% endstep %}
{% step %}
### Attach property cashflow and development models
For each property branch:
* Implement a rental cashflow model using the **Property Cash Flow (Rental or Lease)** pattern for stabilised assets, or
* Implement a development feasibility structure for projects that are not yet stabilised.
Ensure consistent naming and categorisation across properties, for example:
* `Revenue - Base Rent`.
* `Opex - Outgoings`.
* `Debt - Senior Loan`.
* `Capex - Refurbishment`.
Consistency makes portfolio level reporting straightforward.
{% endstep %}
{% step %}
### Add central overheads and group financing
Create a `Central Overheads` branch for costs and financing that support the portfolio as a whole, for example:
* Portfolio management fees.
* Central asset management and operations staff.
* Corporate legal, tax and compliance.
* Shared IT and systems.
At the portfolio branch or within `Central Overheads`, include:
* Group debt facilities that are not ring fenced to individual assets.
* Equity injections and distributions at holding company level.
* Corporate capex such as head office fit outs or systems.
This setup keeps asset level performance distinct from group level structuring and costs.
{% endstep %}
{% step %}
### Build property and portfolio level reports
Use reports and dashboards to show:
Property level views:
* Net operating income per property.
* Yield and margin metrics per asset.
* Debt service and cashflow before and after financing.
* Simple valuation metrics where desired.
Portfolio level views:
* Total rental income, NOI and EBITDA across all assets.
* Aggregate debt, LVR and interest cover.
* Portfolio level Cashflow Statement and Cash Waterfall.
* Regional or sector breakdowns.
You can also create custom reports such as:
* Top and bottom performing properties by NOI or yield.
* Cash contribution by property.
* Exposure by region or sector.
{% endstep %}
{% step %}
### Implement allocation and management fee structures if needed
If the portfolio manager charges fees or allocates costs to assets:
* Represent base and performance fees as Opex at portfolio or asset level.
* Use allocation drivers (for example by asset value, NOI or revenue) to distribute central costs to properties in reporting views.
You can also create separate views:
* Before allocations, to show pure asset performance.
* After allocations, to show net performance after management layers.
{% endstep %}
{% step %}
### Use scenarios for acquisitions, disposals and refinancing
Clone the portfolio model into scenario models to test strategic moves, for example:
* Acquiring or disposing of specific properties.
* Changing leverage levels or debt structures.
* Executing capex programmes or refurbishments.
* Bringing development projects into the stabilised portfolio.
In each scenario, adjust:
* Branch structure (add or remove property branches).
* Asset level cashflow assumptions.
* Central overheads and financing.
Compare scenarios using:
* Portfolio NOI, EBITDA and cash.
* Debt metrics and covenant headroom.
* Portfolio valuation metrics from the Valuation Engine.
* Distribution capacity and growth.
{% endstep %}
{% endstepper %}
## Check your work
* Property list and structure match the real portfolio.
* Asset level models reconcile to recent performance once calibrated.
* Central costs and financing are neither double counted nor omitted.
* Portfolio metrics behave as expected when you add, remove or change assets.
## Troubleshooting
Portfolio results do not match existing consolidated reports
Reconcile property level and central assumptions against existing consolidation models and adjust mappings and opening balances as needed.
Difficult to compare properties with very different sizes or types
Use normalised metrics such as yield, NOI per square metre or debt per unit to complement absolute metrics.
Model is becoming too large
Group smaller properties into pools and reserve detailed individual modelling for larger or more strategic assets.
## Related guides
* [Dashboards & Reporting](/how-tos/dashboards-and-reporting)
* [Build a Stress Test / Downside Case](/how-tos/scenarios-and-planning/build-a-stress-test-downside-case)
* [Equity](/help/financial-outputs-and-valuation/equity)
* [Selecting Driver Type](/syntax/drivers-syntax/selecting-driver-type)
# Loan/Interest Sensitivity Planning
This use case explains how to plan and stress test loan and interest rate scenarios for real estate assets and portfolios using Model Reef.
You will:
* Represent loans and facilities as Liability variables.
* Link debt drawdowns and repayments to property cashflows or project costs.
* Model fixed and floating rate structures, margins and amortisation.
* Test sensitivity to changes in interest rates, covenants and leverage.
Model Reef is not a trading or hedging platform. It provides a planning view of how funding structures and rate paths affect profit, cash and valuation.
## When to use this pattern
Use this pattern when:
* Real estate assets or portfolios are meaningfully leveraged.
* You need to understand sensitivity of cashflows and covenants to interest rate changes.
* You are comparing different funding structures, such as fixed versus floating, amortising versus interest only or multiple tranches.
* You want lenders and investors to see funding risk within the same model as asset cashflows.
It is typically applied on top of:
* **Property Cash Flow (Rental or Lease)**
* **Development Feasibility Model**
* **Multi Property Portfolio Reporting**
## Architecture overview
Loan and interest sensitivity planning uses:
1. Loan representation
* Liability variables for each facility or tranche.
* Drawdown schedules or utilisation rules.
* Amortisation and bullet repayment profiles.
2. Interest rate structure
* Base rate curves or drivers.
* Margins per facility.
* Fixed versus floating proportions.
* Interest capitalisation rules where applicable.
3. Covenants and metrics
* Interest cover ratios.
* Debt service cover ratios.
* Loan to value and loan to cost metrics.
4. Scenarios and stress tests
* Different interest rate paths.
* Alternative leverage and repayment structures.
* Breach and remedy analysis in reporting views.
{% stepper %}
{% step %}
### Create loan variables per facility
For each property or portfolio level facility, create Liability variables, for example:
* `Debt - Senior Loan - Office A`
* `Debt - Portfolio Facility`
* `Debt - Mezzanine Loan - Development Project B`
Specify in each:
* Opening balance or initial draw.
* Maximum facility limit (stored as a driver).
* Drawdown timing (linked to acquisition or project spending).
* Amortisation schedule (for example straight line or annuity).
* Bullet repayment at maturity where applicable.
This defines the nominal debt profile before interest and rate structure are applied.
{% endstep %}
{% step %}
### Build interest rate and margin drivers
In the Data Library, create drivers for:
* `Base Rate Curve` per currency or scenario, for example one driver per period.
* `Margin per Facility`, representing lender margin over base.
* `Fixed Rate Share` if part of the exposure is fixed via swaps or fixed rate loans.
Compute an effective rate per facility, for example:
* `Effective Interest Rate = Base Rate ร Floating Share + Fixed Rate ร Fixed Share + Margin`.
You can represent multiple scenarios by storing different rate curves and selecting the appropriate one per scenario model.
{% endstep %}
{% step %}
### Link interest to loan balances and cashflows
Within each debt variable, configure:
* Interest calculation based on opening or average balance per period.
* Whether interest is expensed or capitalised (for example during development).
* Payment timing (monthly, quarterly or semi annually).
Model Reef will then:
* Record interest expense in P\&L.
* Adjust loan balances if interest is capitalised.
* Show interest paid in the Cashflow Statement and Cash Waterfall.
* Reflect accrued but unpaid interest in Balance Sheet liabilities.
This links interest behaviour directly to both asset cashflows and funding decisions.
{% endstep %}
{% step %}
### Compute covenants and coverage ratios
Using variables or report formulas, compute metrics such as:
* `Interest Cover Ratio (ICR) = EBITDA or NOI รท Interest Expense`.
* `Debt Service Cover Ratio (DSCR) = Cash Available for Debt Service รท Debt Service`.
* `Loan to Value Ratio (LVR) = Debt รท Property Value`.
* `Loan to Cost (LTC) = Debt รท Total Project Cost` for developments.
You can display these metrics per asset, per facility and at portfolio level, and compare them to covenant thresholds stored as drivers.
Highlight periods where ratios fall below target levels to support risk monitoring.
{% endstep %}
{% step %}
### Build sensitivity and scenario views
Clone the model into scenario models that represent different interest and leverage environments, for example:
* Base case interest rate path.
* Upward shocks (for example plus 100 basis points or more).
* Reduced or increased leverage.
* Alternative amortisation structures.
In each scenario, adjust:
* Base rate curves.
* Facility margins and fixed versus floating shares.
* Drawdown and repayment schedules.
* Any associated changes in asset cashflows, such as slowed development or altered capex.
Compare scenarios using:
* Interest expense and cash interest over time.
* DSCR, ICR and LVR versus covenant thresholds.
* Equity cashflows and valuation metrics from the Valuation Engine.
* Breach risk and headroom analysis.
{% endstep %}
{% step %}
### Integrate with portfolio and investor reporting
Because loans are represented as standard Liability variables:
* P\&L, Balance Sheet, Cashflow and Cash Waterfall already include interest and debt flows.
* Portfolio level reports can show both asset level and funding level performance.
* Investor and lender packs can be generated directly from the same model.
Use dashboards to show:
* Debt maturity profiles and repayment schedules.
* Interest cost by facility and in total.
* Key covenant ratios and whether they are in or out of range.
* Sensitivity charts for rate and leverage changes.
{% endstep %}
{% endstepper %}
## Check your work
* Loan balances and terms reconcile to facility documentation and existing debt schedules.
* Base rate and margin assumptions reflect current and expected market conditions.
* Coverage ratios behave sensibly when you stress interest or cash generation.
* Scenario results make sense in the context of lender and investor conversations.
## Troubleshooting
Interest cost jumps unexpectedly between periods
Review drawdowns, amortisation and rate changes in the same periods, and confirm that timing of rate resets is correctly represented.
Covenant ratios do not match external models
Ensure you are using the same definition of EBITDA, NOI and debt service as lenders and auditors, and adjust the formulas accordingly.
Model feels complex for a small amount of debt
Simplify by modelling one blended facility instead of multiple tranches, and only add tranches where it is necessary for decision making.
## Related guides
* [Build a Valuation Sensitivity Model](/how-tos/valuation/build-a-valuation-sensitivity-model)
* [Build a Synergy & Integration Model](/how-tos/investment-and-transactions/build-a-synergy-and-integration-model)
* [Equity Distribution Logic](/help/financial-outputs-and-valuation/equity-distribution-logic)
* [Selecting Drivers in Sidebar](/syntax/formula-syntax/selecting-drivers-in-sidebar)
# ๐ Not-for-Profit & Education
# Grant Funding Models
This use case explains how to model grant funding for not-for-profit and education organisations in Model Reef.
You will:
* Represent grants as structured revenue streams linked to specific programs or cost centres.
* Model award amounts, tranches, milestones and acquittal conditions.
* Distinguish between income recognition and cash receipt timing.
* Connect grant funding to program costs, cashflow and multi year planning.
Model Reef does not replace your grant management system. It consumes high level assumptions about grants and converts them into full three statement forecasts.
## When to use this pattern
Use this pattern when:
* Your organisation depends on grants from government, foundations or donors.
* Grants fund specific programs, projects or cohorts.
* You need to understand how grant timing affects program viability and cash.
* You want grant assumptions wired into your P\&L, Balance Sheet and Cashflow forecasts.
It is often combined with:
* Program Cost Modelling
* Donor or Revenue Stream Forecasting
* Multi Program Consolidated Reporting
## Architecture overview
{% stepper %}
{% step %}
### Structure
* Branches for each program, campus or cost centre.
* Optional branch for organisation wide overheads.
{% endstep %}
{% step %}
### Grant definitions
* Award amount, term and purpose.
* Tranches, milestones and conditions.
* Recognition rules and allowable cost types.
{% endstep %}
{% step %}
### Timing and compliance
* Timing of award, invoicing and cash receipts.
* Acquittal timing and under or overspend rules.
* Multi year roll forward behaviour.
{% endstep %}
{% step %}
### Financial outputs
* Grant income per program and in total.
* Cash inflows and receivables.
* Funding gaps relative to program costs.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
This architecture maps from organisational structure through grant definition and timing into financial outputs used in forecasting and reporting.
{% endhint %}
## Setup and modelling steps
{% stepper %}
{% step %}
### Set up branches for programs and overheads
In the branch tree, create a structure that reflects how you manage delivery, for example:
* Organisation
* Program - Youth Services
* Program - Education Outreach
* Program - Research
* Central Overheads
Each program branch will hold the program's grant funding and program costs. Central Overheads holds shared staff and overheads that are not tied to a single program.
This allows you to see grant coverage at program level and in aggregate.
{% endstep %}
{% step %}
### Define each grant as a structured funding line
For each grant, create a Revenue type variable in the branch that delivers it, for example:
* Revenue - Grant - Youth Mental Health 2025
* Revenue - Grant - Outreach Pilot 2024 to 2026
* Revenue - Grant - Research Fellowship A
Attach metadata as tags or notes for:
* Funder name.
* Grant agreement identifier.
* Purpose and restrictions.
* Key milestones and reporting requirements.
If a single grant funds multiple programs, choose between:
* One grant variable at a parent branch plus allocation drivers, or
* Separate grant variables per program linked to a common driver for the total award.
{% endstep %}
{% step %}
### Model award amount, tranches and term
Use drivers in the Data Library to capture grant structure, for example:
* Total Award Amount.
* Start Date and End Date.
* Annual or period based allocation percentages.
* Tranche schedule, for example 40 percent up front, 30 percent at milestone 1, 30 percent at milestone 2.
Based on these drivers, set the Revenue variable's accrual path:
* Evenly across the grant term.
* Match to planned program delivery expenditure.
* Match to agreed tranche schedule.
As a starting point, many organisations recognise grant income in line with allowable expenditure, especially where unspent funds must be returned. You can approximate this by linking grant recognition to program cost variables in the same branch.
{% endstep %}
{% step %}
### Separate income recognition from cash timing
In the variable timing settings, define cash timing rules distinct from accrual, for example:
* Up front payment on award date for a portion of the grant.
* Subsequent payments on milestone dates.
* Final reconciliation payment or clawback after acquittal.
Examples:
* 50 percent of grant cash received at start of year 1, remaining 50 percent at mid year.
* Quarterly payments in arrears based on expenditure reports.
* One off payment after reporting is accepted.
Set delays or explicit schedules so that:
* P\&L shows grant income in the period it is recognised.
* Balance Sheet shows a receivable where income is recognised but cash is outstanding, or deferred income where cash is received ahead of recognition.
* Cashflow and Cash Waterfall show when cash actually arrives.
If you need to approximate deferred income, you can use Liability variables to represent unearned grant income and link them to grant recognition and cash receipts.
{% endstep %}
{% step %}
### Connect grants to program costs
To see whether grants fully fund program activity, create program cost variables in the same branch, for example:
* Staff - Program Team - Youth Mental Health.
* Opex - Travel and Supplies - Outreach Program.
* Opex - Venue and Equipment - Education Workshops.
Model these costs using Program Cost Modelling, then compare:
* Grant income from all sources per program.
* Total program costs.
* Net surplus or funding gap.
This comparison is easiest via custom reports and dashboards that show:
* Grant funding coverage percentage (grant income divided by program costs).
* Amount of unfunded program cost that must be supported by other revenue streams.
* Multi year view of coverage ratios.
{% endstep %}
{% step %}
### Model grant pipelines and future funding risk
Beyond contracted grants, you may want to model a grant pipeline, including:
* Probability weighted pipeline of potential opportunities.
* Renewal risk for expiring grants.
* Targeted new funding for existing programs.
Use drivers such as:
* Probability of success per grant proposal.
* Expected award date and term.
* Best case, base case and downside views for key funders.
Represent pipeline items as separate Revenue variables with lower certainty and use scenarios to turn them on or off. This keeps base forecasts conservative while allowing board or leadership to see upside potential and funding risk.
{% endstep %}
{% step %}
### Use scenarios for grant risk and strategy
Clone the model into scenario models to represent different grant environments, for example:
* Loss of a major grant for a core program.
* Successful renewal of time limited funding.
* Expansion of programs with multiple new grants.
* Adverse funding environment with delays or reductions.
In each scenario, adjust:
* Grant award amounts and terms.
* Payer mix between grants, donations and earned income.
* Program cost structures and staffing.
Compare scenarios using:
* Net funding position per program.
* Cash runway and funding gaps.
* Ability to maintain, expand or wind down specific programs.
* Impact on group level reserves and valuation metrics where relevant.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
### Check your work
* Grant amounts, terms and cash timing match signed agreements or current expectations.
* Income recognition policies in the model mirror accounting policies used for reporting.
* Program level comparisons between grant income and costs match management views.
* Scenario results align directionally with discussions about funding risk and strategy.
{% endhint %}
## Troubleshooting
Grant income appears too smooth or does not match internal reporting
Refine recognition rules and ensure you are not simply smoothing total awards when actual practice links recognition to expenditure or milestones.
Cashflow shows unexpected spikes or troughs
Check timing assumptions for initial payments, milestone payments and reconciliations, and confirm whether any grants are paid in advance.
Difficult to manage many small grants
Group similar, small grants into pooled funding lines with a single set of assumptions per program and maintain higher detail only for the largest or riskiest grants.
## Related guides
* [Build a Unified Forecast from Multiple Inputs](/how-tos/core-modelling/build-a-unified-forecast-from-multiple-inputs)
* [Build a Unit Economics Model](/how-tos/operations-and-unit-economics/build-a-unit-economics-model)
* [Equity Variables: what is, rules, what it affects](/help/drivers-variables-and-timing/equity-variables)
* [Selecting Variables in Sidebar](/syntax/formula-syntax/selecting-variables-in-sidebar)
# Program Cost Modelling
This use case explains how to model program level costs for not-for-profit and education organisations in Model Reef.
You will:
* Represent programs, projects or services as separate branches.
* Attach staffing, direct costs and allocated overheads to each program.
* Link program costs to grant income, donations and earned revenue.
* Produce P\&L and cash views per program and in total.
The goal is to understand the true cost of delivering each program and to support funding, pricing and prioritisation decisions.
## When to use this pattern
Use this pattern when:
* You run multiple programs, services or projects with distinct objectives.
* You want to know which programs are fully funded, partially funded or cross subsidised.
* You need to justify funding requests or report program economics to stakeholders.
* You want program economics stitched into group level reporting.
It is commonly combined with:
* Grant Funding Models
* Donor or Revenue Stream Forecasting
* Multi Program Consolidated Reporting
## Architecture overview
Program cost modelling uses:
1. Branch structure
* One branch per program or project.
* Optional regional or thematic parent branches.
* Central overhead branch for shared costs.
2. Staff and direct cost variables
* Program staff, contractors and volunteers.
* Direct costs such as materials, venues, travel and equipment.
3. Overhead allocation structures
* Central administration and support functions.
* Allocation drivers by FTE, revenue, headcount or other metrics.
4. Financial outputs
* Program level P\&L and cash.
* Contribution after direct and allocated overheads.
* Coverage ratios relative to funding.
{% stepper %}
{% step %}
### Step 1: Create branches for each program
In the branch tree, define a structure that reflects how you run and monitor your work, for example:
* Organisation
* Program - Youth Services
* Program - Adult Education
* Program - Research and Evaluation
* Central Overheads
If you manage programs by region or thematic area, insert intermediate branches such as `Region - North` or `Theme - Health`, then add program branches underneath.
Each program branch will contain its own revenue and cost variables.
{% endstep %}
{% step %}
### Step 2: Add program staff cost structures
Within each program branch, create Staff variables, for example:
* Staff - Program Manager - Youth Services.
* Staff - Case Workers - Youth Services.
* Staff - Tutors - Adult Education.
* Staff - Researchers - Research Program.
Define drivers for:
* FTE per role.
* Average salary per FTE.
* Oncost percentages for super, pension, payroll tax and other benefits.
Formulas typically look like:
* Staff Cost - Case Workers - Youth Services\
\= FTE Case Workers ร Salary per FTE ร (1 plus Oncost Percentage).
Use timing settings to reflect pay cycles and delays, so that P\&L, Balance Sheet and Cashflow outputs align with how staff are actually paid.
{% endstep %}
{% step %}
### Step 3: Add direct program costs
Still within each program branch, create Opex variables for direct costs, for example:
* Opex - Venue Hire - Youth Workshops.
* Opex - Materials and Supplies - Adult Education.
* Opex - Travel and Outreach - Youth Services.
* Opex - Participant Support Costs - Research Program.
Link these to drivers such as:
* Cost per participant or per group.
* Cost per workshop or per term.
* Cost per kilometre of travel.
* Fixed baseline cost per period with growth.
This ensures direct costs scale appropriately with program activity in different scenarios.
{% endstep %}
{% step %}
### Step 4: Model central overheads and allocation choices
In a `Central Overheads` branch, represent organisation wide costs, for example:
* Staff - Executive and Leadership Team.
* Staff - Finance, HR and IT.
* Opex - Office Rent and Utilities.
* Opex - Central Systems, Subscriptions and Insurance.
Decide whether to:
* Leave these costs unallocated and show program contribution before central overheads, or
* Allocate some or all overheads to programs for a fully loaded view.
If you allocate overheads, define drivers such as:
* Share of FTE per program.
* Share of program direct costs.
* Share of revenue or funding per program.
Implement allocation through:
* Additional Opex variables in program branches that reference central cost pools and allocation drivers, or
* Custom reports that apply allocation formulas when presenting results.
Make allocation logic transparent and easy to adjust.
{% endstep %}
{% step %}
### Step 5: Link program costs to funding and revenue
With program costs in place, connect them to funding streams by:
* Using Grant Funding Models to represent grants in each program branch.
* Using Donor or Revenue Stream Forecasting to represent donations, membership fees or earned income by program.
* Keeping central or general funds in a separate branch if they are not program specific.
Create dashboards and reports that show for each program:
* Total funding from grants, donations and earned revenue.
* Total staff and direct costs.
* Program contribution before and after overhead allocations.
* Funding coverage ratios and any funding gaps.
This provides a clear picture of which programs are constrained, which are well funded and where flexible funding is most needed.
{% endstep %}
{% step %}
### Step 6: Use scenarios for program changes and prioritisation
Clone the base model into scenario models to assess options such as:
* Scaling successful programs up or extending them to new regions.
* Restructuring or winding down underperforming programs.
* Adjusting delivery models (for example more group sessions, hybrid or digital delivery).
* Responding to changes in grant funding or donor income.
In each scenario, adjust:
* Program staff and direct cost drivers.
* Funding levels and mix per program.
* Overhead allocation rules and central cost structures.
Compare scenarios using:
* Program and group level surplus or deficit.
* Cash requirements and reserve usage.
* Ability to protect core programs under stress cases.
* Clarity for boards and funders about trade offs.
{% endstep %}
{% endstepper %}
## Check your work
* Program list and structure match how work is managed and reported internally.
* Staff and cost assumptions reconcile to recent budgets or actuals when calibrated.
* Overhead allocations are understandable and not overly complex.
* The model can be maintained as programs start, scale, pause or end.
## Troubleshooting
Some programs appear more or less expensive than expected
Revisit staff and direct cost assumptions and check that all relevant costs are captured within the correct program branch.
Central overheads dominate program level results
Show both pre and post allocation views and clearly explain allocation drivers. Consider whether some central costs should be treated as strategic rather than allocated.
The model is difficult to keep updated when programs change
Use consistent naming and structure, and consider a template pattern for programs so that adding or removing a program is straightforward.
## Related guides
* [Build a Variance Analysis Model](/how-tos/dashboards-and-reporting/build-a-variance-analysis-model)
* [Build an Acquisition Case vs Base Case](/how-tos/investment-and-transactions/build-an-acquisition-case-vs-base-case)
* [Excel Import](/help/importing-and-data-inputs/excel-import)
* [Start & End Dates](/syntax/timing-syntax/start-and-end-dates)
# Donor/Revenue Stream Forecasting
This use case explains how to forecast donations, membership income and other revenue streams for not-for-profit and education organisations in Model Reef.
You will:
* Segment income streams by donor type, product or channel.
* Model donor counts, retention, upgrade and acquisition.
* Forecast memberships, events and earned revenue.
* Connect income streams to programs and group level reporting.
Model Reef is not a donor CRM. It sits above CRM and fundraising tools, using aggregated metrics and imported data to drive financial forecasts.
## When to use this pattern
Use this pattern when:
* You rely on a mix of grants, donations, memberships, events and earned income.
* You want to understand how donor behaviour drives revenue.
* You need to test campaigns, pricing and retention strategies.
* You want fundraising and earned income assumptions integrated with program costs and cash planning.
It is often used alongside:
* Grant Funding Models
* Program Cost Modelling
* Multi Program Consolidated Reporting
## Architecture overview
Donor and revenue stream forecasting uses:
1. Income stream segmentation
* Individual donors, major donors, corporates, trusts and foundations.
* Memberships, events, courses or products.
* Channels such as digital, mail, face to face or corporate partnerships.
2. Donor and customer drivers
* Donor or member counts by segment.
* Retention, upgrade and acquisition rates.
* Average gift or spend per donor, member or transaction.
3. Revenue variables
* Revenue per segment and channel.
* One off versus recurring streams.
* Timing of receipts.
4. Financial outputs
* Income by source and program.
* Channel performance metrics.
* Cashflow and volatility patterns.
{% stepper %}
{% step %}
### Step 1: Define revenue segments and channels
Create a list of income streams that matter for planning, such as:
* Individual regular giving.
* Individual one off donations.
* Major donors.
* Corporate giving and sponsorship.
* Trusts and foundations.
* Memberships or subscriptions.
* Events and campaigns.
* Course fees or tuition.
* Merchandise or other earned income.
For each stream, decide whether it will live in:
* A program branch, where it is directly linked to a program, or
* A central fundraising or revenue branch, where it supports multiple programs.
{% endstep %}
{% step %}
### Step 2: Create donor and customer drivers
In the Data Library, create time series drivers such as:
* `Number of Regular Givers`.
* `Average Monthly Gift - Regular Givers`.
* `Number of One Off Donors per Campaign`.
* `Average One Off Gift`.
* `Number of Members` and `Average Membership Fee`.
* `Event Attendees` and `Average Ticket Price`.
Where relevant, also define behavioural drivers:
* `Retention Rate - Regular Givers`.
* `Upgrade Rate - Regular Givers`.
* `Acquisition Rate` or new donor counts.
* `Churn Rate - Members`.
You can implement these as direct level drivers (counts and amounts per period) or as transition drivers that change the counts over time.
{% endstep %}
{% step %}
### Step 3: Build revenue variables per stream
For each segment, create Revenue type variables, for example:
* Revenue - Regular Giving.
* Revenue - One Off Giving.
* Revenue - Major Donors.
* Revenue - Membership Fees.
* Revenue - Events.
* Revenue - Course Fees.
Define formulas such as:
* Revenue - Regular Giving\
\= Number of Regular Givers ร Average Monthly Gift ร 12 for annual models, or times the number of periods in each period.
* Revenue - Membership Fees\
\= Number of Members ร Average Membership Fee per Period.
For events and campaigns, you can model:
* Number of events.
* Average attendees per event.
* Average revenue per attendee.
These variables will flow into P\&L and cash once timing is configured.
{% endstep %}
{% step %}
### Step 4: Apply timing and payment methods
For each revenue variable, define timing rules that reflect how cash arrives, for example:
* Regular giving debits at the start or end of each month.
* Online donations cleared within a few days.
* Direct debit batches with a small delay.
* Event ticket sales occurring ahead of the event date.
* Course fees collected up front or per term.
Set delays or schedules so that:
* Revenue is recognised when earned in P\&L.
* Receivables or deferred income appear on the Balance Sheet where appropriate.
* Cashflow and Cash Waterfall reflect actual inflows.
This allows you to see the impact of revenue seasonality and the lag between campaign activity and cash received.
{% endstep %}
{% step %}
### Step 5: Map revenue streams to programs and purposes
To understand how revenue supports program activity:
* Use branches to link revenue streams directly to programs where restricted.
* Represent unrestricted or general funds in a central branch and allocate them conceptually to programs in reporting views.
* Tag revenue variables with program or purpose where a single stream supports multiple areas.
Custom reports and dashboards can then show:
* Income by source per program.
* Share of restricted versus unrestricted funding.
* Dependence on particular donor types or channels.
This supports risk assessment and communication with funders and boards.
{% endstep %}
{% step %}
### Step 6: Use scenarios for campaigns and behaviour changes
Clone the base model into scenario models to explore situations such as:
* Increased investment in acquisition campaigns.
* Changes in retention or upgrade rates.
* Loss of a major donor or partner.
* Introduction of new revenue products, memberships or events.
* Macro shocks that reduce giving or course enrolments.
In each scenario, adjust:
* Donor and member counts.
* Behavioural drivers (retention, upgrade, churn).
* Average gift or spend per donor, member or customer.
* Campaign volumes and cost where linked to program or fundraising costs.
Compare scenarios using:
* Total income by stream and in aggregate.
* Volatility and concentration of income.
* Cash runway and reserves.
* Ability to fund program portfolios over time.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
### Check your work
* Donor, member and customer counts reflect recent history when the model is calibrated.
* Average gift and behavioural assumptions are realistic, based on internal data or benchmarks.
* Revenue timing assumptions match actual payment patterns.
* The model is segmented enough to be useful but not so granular that it is hard to maintain.
{% endhint %}
## Troubleshooting
Income appears too smooth compared with history
Introduce seasonality or campaign effects and adjust timing so that peaks align with typical fundraising or enrolment periods.
Scenario results are hard to interpret
Focus on a limited number of key segments for scenario analysis and keep minor streams grouped for simplicity.
Dependence on a small number of donors is not obvious
Use dashboards that highlight concentration, such as top ten donor or partner contributions, even if these are modelled at aggregated levels.
## Related guides
* [Build an Equity Valuation Model (FCFE)](/how-tos/valuation/build-an-equity-valuation-model-fcfe)
* [Build an Executive Dashboard](/how-tos/dashboards-and-reporting/build-an-executive-dashboard)
* [FCFE Calculation](/help/financial-outputs-and-valuation/fcfe-calculation)
* [Subcategory Selection](/syntax/variables-syntax/subcategory-selection)
# Multi-Program Consolidated Reporting
This use case explains how to consolidate financial forecasts across multiple programs, locations and funding streams for not-for-profit and education organisations in Model Reef.
You will:
* Represent programs, projects and central functions in a coherent branch structure.
* Attach program level funding and cost models to each branch.
* Add central overheads, reserves and balance sheet items.
* Produce program level and consolidated P\&L, Balance Sheet, Cashflow and Cash Waterfall outputs.
The objective is a single model that can serve operational leaders, finance teams, boards and funders.
## When to use this pattern
Use this pattern when:
* You run multiple programs or campuses with distinct funding and cost structures.
* You need consolidated reporting for leadership and governance.
* You want a single view of funding gaps, reserves and sustainability.
* You plan to test multiple funding and program mix scenarios.
It builds on:
* Grant Funding Models
* Program Cost Modelling
* Donor or Revenue Stream Forecasting
## Architecture overview
Multi program consolidated reporting uses:
* Branch tree
* Organisation root branch.
* Program branches, optionally grouped by region or theme.
* Branches for central overheads and shared structures.
* Program level models
* Program costs and staffing.
* Grant, donor and earned income per program.
* Central structure
* Organisation wide staff and overheads.
* Reserves, cash and investments.
* Debt or other liabilities if relevant.
* Reporting and dashboards
* Program level P\&L and contribution.
* Group level totals and ratios.
* Scenario comparisons across program portfolios.
***
{% stepper %}
{% step %}
### Design the branch structure
Define a branch tree that mirrors how the organisation is managed, for example:
* Organisation
* Theme - Youth
* Program - Youth Services
* Program - Youth Education
* Theme - Health
* Program - Health Outreach
* Region - Online
* Program - Digital Learning
* Central Overheads
* Reserves and Balance Sheet
Choose thematic, regional or program family groupings depending on internal practice. The key is that each program sits in exactly one branch and roll up paths are clear.
{% endstep %}
{% step %}
### Attach program level funding and cost models
Within each program branch, implement:
* Program Cost Modelling for staff and direct costs.
* Grant Funding Models where program specific grants apply.
* Donor or revenue stream variables for program specific donations or earned income.
Ensure consistent naming and category usage, for example:
* Revenue - Grants - Program X.
* Revenue - Donations - Program X.
* Revenue - Earned Income - Program X.
* Staff - Program Staff - Program X.
* Opex - Direct Costs - Program X.
Consistency simplifies consolidated reporting and cross program comparison.
{% endstep %}
{% step %}
### Model central overheads, reserves and other balance sheet items
In `Central Overheads`, represent organisation wide costs, such as:
* Leadership and governance staff.
* Finance, HR, IT and operations.
* Central premises and shared services.
* Organisation wide communications and fundraising.
In a separate branch or at the organisation root, create Asset and Liability variables for:
* Cash and reserves.
* Investments.
* Debt or other liabilities.
* Opening balances from the latest audited Balance Sheet.
This setup ensures all three statements can be produced at organisation level while keeping program economics visible.
{% endstep %}
{% step %}
### Build program and group level reports
Create reports and dashboards that show:
Program level views:
* P\&L per program, including funding and direct costs.
* Contribution before and after any allocated central overheads.
* Trends in program surplus or deficit over time.
Group level views:
* Consolidated P\&L across all programs and central functions.
* Balance Sheet including reserves and investments.
* Cashflow Statement and Cash Waterfall showing operating, investing and financing flows.
* Ratios such as share of funding by source and spend on programs versus overheads.
Use filters and branch selections so users can move from group level to individual program level and back.
{% endstep %}
{% step %}
### Implement allocation views where needed
If you need to show fully loaded program costs that include central overheads:
* Decide on allocation drivers, such as FTE, revenue, direct costs or activity metrics.
* Compute allocation factors in the Data Library.
* Apply these to central cost pools via:
* Additional Opex variables per program, or
* Custom report formulas that allocate central costs without altering program branches.
Provide both pre allocation and post allocation views so stakeholders can see direct program performance and fully loaded economics.
{% endstep %}
{% step %}
### Use scenarios for portfolio and funding strategy
Clone the consolidated model into scenario models that represent different strategic choices, for example:
* Scaling some programs and pausing or exiting others.
* Winning or losing major grants.
* Shifts in donor or membership income.
* Changes in central overhead levels or structure.
* Drawing down or building up reserves.
In each scenario, adjust:
* Program funding and cost assumptions.
* Central cost structures and allocation policies.
* Reserve and balance sheet strategies, such as minimum cash days.
Compare scenarios using:
* Program and group level surplus or deficit.
* Cash runway and reserve usage.
* Composition of funding by source and by restriction.
* Long term sustainability under different portfolios.
{% endstep %}
{% step %}
### Prepare governance and funder ready outputs
With the consolidated model in place, you can:
* Generate board packs with program and group views.
* Provide funders with forecasts for the programs they support in context of the wider organisation.
* Support internal planning cycles with a single model rather than multiple disconnected spreadsheets.
* Use the Valuation Engine, if relevant, to analyse the effect of long term commitments and reserves policies.
This supports better decision making and transparent communication with stakeholders.
{% endstep %}
{% endstepper %}
***
## Check your work
* Branch structure reflects how the organisation is actually run and reported.
* Program, central and balance sheet assumptions reconcile to latest budgets and audited figures when calibrated.
* Allocation logic is documented and not overly complex.
* Scenario results support the strategic conversations leaders are having.
## Troubleshooting
Group results do not match existing consolidation
Review opening balances, ensure all branches are enabled, and confirm that no major programs or central cost items are missing from the model.
Stakeholders are confused by allocation effects
Provide clear pre and post allocation views and keep allocation rules simple and aligned with internal policy.
Model feels hard to maintain as programs change
Use program templates, consistent naming and a clear approach for adding, scaling or closing programs, and periodically review structure for simplicity.
## Related guides
* [Build an Investor Update Pack](/how-tos/dashboards-and-reporting/build-an-investor-update-pack)
* [Build an LBO Model](/how-tos/investment-and-transactions/build-an-lbo-model)
* [FCFF Calculation](/help/financial-outputs-and-valuation/fcff-calculation)
* [Timing Modal](/syntax/understanding-the-interface/timing-modal)
# ๐ฑ Agriculture & Primary Production
# Crop Yield Forecasts
This use case explains how to forecast crop yields and the associated revenue and cost patterns for agriculture and primary production in Model Reef.
You will:
* Represent farms, regions or crop types in the branch structure.
* Build yield and area drivers for key crops.
* Connect yields to pricing, input costs and labour.
* Capture seasonality and timing of cash inflows and outflows.
Model Reef is not a farm management or agronomy system. It uses high level agronomic and commercial assumptions to generate financial forecasts, cashflow and valuation.
## When to use this pattern
Use this pattern when:
* Crop production is a core driver of business performance.
* You need to translate agronomic assumptions into P\&L and cash.
* You want to test pricing, yield and weather scenarios.
* You manage multiple farms, paddocks or regions and need consolidation.
It works well with:
* Seasonality and Commodity Pricing
* Farm Level Working Capital Planning
* Multi Entity Group Model
## Architecture overview
Crop yield forecasting uses four layers:
1. Structure
* Branches per farm, region or crop enterprise.
* Optional sub branches for paddocks, rotations or varieties.
2. Production drivers
* Area planted.
* Yield per hectare or per acre.
* Losses and quality adjustments.
3. Price and revenue drivers
* Commodity prices and basis adjustments.
* Grade or quality pricing tiers.
* Currency assumptions where relevant.
4. Cost and timing
* Inputs, labour, storage and logistics.
* Seasonal spend and receipt timing.
* Working capital and financing impacts.
{% stepper %}
{% step %}
### Set up branches for farms and crops
In the branch tree, create a structure that reflects how you manage operations, for example:
* Group
* Farm - North
* Crop - Wheat
* Crop - Canola
* Farm - South
* Crop - Barley
* Crop - Legumes
* Central Overheads
Each crop branch can hold yield, revenue and direct costs. Farm or group branches aggregate by location or portfolio.
If you prefer, you can instead structure by crop type at the top level with farms underneath. Choose the pattern that matches how you want to report.
{% endstep %}
{% step %}
### Define area and yield drivers
In the Data Library, create drivers such as:
* Area Planted - Wheat - Farm North (hectares or acres).
* Yield per Hectare - Wheat - Farm North (tonnes per hectare).
* Loss Percentage for weather, pests or operational losses.
* Quality Adjustment Percentage for downgraded grain or off grade product.
For each crop branch, calculate expected production, for example:
* Gross Production = Area ร Yield per Hectare.
* Net Production = Gross Production ร (1 minus Loss Percentage).
* Saleable Production = Net Production ร (1 minus Quality Adjustment Percentage) if you want to track a quality haircut separately.
These series will drive revenue and logistics.
{% endstep %}
{% step %}
### Connect yields to prices and revenue
Create price drivers for each crop, such as:
* Base Commodity Price per Tonne.
* Local Basis Adjustment.
* Quality Discount or Premium factors.
* Forward price for hedged proportions if you model hedging simply.
Then create Revenue variables per crop and farm, for example:
* Revenue - Wheat - Farm North.
* Revenue - Canola - Farm North.
* Revenue - Barley - Farm South.
Formulas might be:
* Net Price per Tonne = Base Price plus Basis Adjustment plus Quality Premium.
* Revenue - Wheat - Farm North = Saleable Production - Wheat - Farm North ร Net Price per Tonne - Wheat - Farm North.
You can also split revenue into different grades or contract types if needed, but ensure the granularity is maintainable.
Set variables as type **Revenue** so they feed directly into P\&L and cash when timing is added.
{% endstep %}
{% step %}
### Add input, labour and logistics costs
For each crop branch, create Opex and Staff variables for key cost categories, for example:
* Opex - Seed - Wheat - Farm North.
* Opex - Fertiliser - Wheat - Farm North.
* Opex - Chemicals - Wheat - Farm North.
* Opex - Fuel and Machinery Running.
* Staff - Seasonal Labour.
* Opex - Storage and Handling.
* Opex - Freight to Port or Buyer.
Link these to drivers such as:
* Cost per hectare.
* Cost per tonne produced.
* Labour hours per hectare or task.
* Freight cost per tonne per kilometre.
This ensures cost scales appropriately when area, yield and production change under different scenarios.
{% endstep %}
{% step %}
### Capture seasonality and timing
Use timing settings and schedules to reflect the agricultural calendar, for example:
* Input spend concentrated in planting and growing seasons.
* Harvest costs in a short window.
* Revenue receipts at delivery or at later settlement dates.
* Storage costs over off season periods.
Examples:
* Fertiliser spend in months leading into planting.
* Fuel and harvest labour costs in harvest months.
* Revenue delayed by 30 to 90 days from delivery if you offer terms or use pool structures.
Set timing so that:
* P\&L shows revenue and cost where they occur in the production cycle.
* Balance Sheet shows receivables, payables and inventory where relevant.
* Cashflow and Cash Waterfall capture seasonal working capital needs.
If you want to approximate inventory, you can use Asset and Liability variables to hold grain between harvest and sale and link them to production and sales schedules.
{% endstep %}
{% step %}
### Use scenarios for weather, yield and price risk
Clone the base model into scenario models to represent different conditions, for example:
* Base season with average yields and prices.
* Drought or poor season with reduced yields and additional costs.
* Good season with above average yields and strong prices.
* Commodity price shock scenarios while yields remain average.
In each scenario, adjust:
* Area planted, yield per hectare and loss percentages.
* Price drivers and basis adjustments.
* Input costs and labour requirements if you change cropping mix.
* Hedged proportions if you use simple forward pricing.
Compare scenarios using:
* Revenue and gross margin per crop and per farm.
* Cashflow volatility and funding needs.
* Impact on loan covenants and valuation if the business is leveraged.
{% endstep %}
{% step %}
### Tie crop forecasts into whole farm planning
Because crop branches sit within farm branches and a group branch:
* Farm level reports show combined crop performance and costs per farm.
* Group level reports show portfolio performance across all farms.
* You can integrate livestock, horticulture or other enterprises using separate use cases, all within the same model.
Dashboards can highlight:
* Contribution per crop, farm and region.
* Exposure to specific commodities or price benchmarks.
* Sensitivity of the whole business to changes in yield and price assumptions.
{% endstep %}
{% endstepper %}
## Check your work
* Yield and price assumptions are benchmarked against historical data or independent forecasts.
* Input and logistics cost assumptions align with real invoices or budgets.
* Seasonal patterns in cashflow match actual experience when calibrated.
* Scenario outcomes make intuitive sense to operational and finance stakeholders.
## Troubleshooting
Modelled production does not match historical tonnage
Check area and yield per hectare inputs, and ensure loss and quality adjustments are not double counted or omitted.
Cashflow looks too flat or too volatile
Refine timing of input spend, harvest and revenue receipts to match the actual agricultural calendar and contract terms.
Too many small fields or crops to model comfortably
Group similar paddocks or small crops into composite branches and maintain detailed modelling only for major crops and farms.
## Related guides
* [Convert a PDF to a Structured Forecast](/how-tos/data-workflows-and-automation/convert-a-pdf-to-a-structured-forecast)
* [Core Modelling](/how-tos)
* [Financing Cashflow](/help/financial-outputs-and-valuation/financing-cashflow)
* [Understanding the Interface](/syntax)
# Livestock Production Modelling
This use case explains how to model livestock enterprises, including herd or flock dynamics, production, sales and associated costs, for agriculture and primary production in Model Reef.
You will:
* Represent livestock enterprises in the branch structure.
* Model opening numbers, births, purchases, sales and deaths.
* Link livestock numbers to production, revenue and cost drivers.
* Capture seasonality, feeding, grazing and working capital effects.
Model Reef is not a livestock management system. It turns high level herd or flock assumptions into financial forecasts and cash plans.
## When to use this pattern
Use this pattern when:
* Livestock is a material part of farm income and risk.
* You need to understand how stocking decisions affect profit and cash.
* You want to test different growth, finishing or trading strategies.
* You manage multiple properties or enterprises and need consolidated views.
It works well with:
* Crop Yield Forecasts for mixed enterprises.
* Seasonality and Commodity Pricing.
* Farm Level Working Capital Planning.
## Architecture overview
{% stepper %}
{% step %}
### Structure
* Branches per enterprise, such as cattle, sheep, pigs or poultry.
* Optional sub branches per farm, breed, age class or production system.
{% endstep %}
{% step %}
### Herd or flock dynamics
* Opening numbers by class.
* Births, purchases, sales and deaths.
* Transfers between classes or locations.
{% endstep %}
{% step %}
### Production and revenue drivers
* Weight gain, carcass weight or product yield (for example milk, eggs or wool).
* Sale weights and prices.
* Cull and replacement rates.
{% endstep %}
{% step %}
### Cost and timing
* Feed, pasture, veterinary and husbandry costs.
* Labour, transport and processing.
* Seasonal cashflows and working capital.
{% endstep %}
{% endstepper %}
## Step 1: Set up branches for livestock enterprises
In the branch tree, create a structure such as:
* Farm Group
* Farm - North
* Enterprise - Beef Cattle
* Enterprise - Sheep
* Farm - South
* Enterprise - Dairy
* Central Overheads
Within each enterprise branch, you may create sub branches for age classes or systems if you want to separate breeding and trading operations, for example `Breeding Herd` and `Backgrounding or Finishing`.
## Step 2: Build herd or flock number drivers
In the Data Library, create drivers for the key number flows, for example for beef:
* Opening Cows.
* Opening Heifers.
* Opening Steers.
* Calving Rate Percentage.
* Mortality Rate Percentage.
* Purchase Numbers per period.
* Sales Numbers per period.
You can either:
* Model flows at annual or seasonal level in a higher level model, or
* Use more granular frequency where you have detailed plans.
Define derived drivers such as:
* Births = Opening Cows ร Calving Rate.
* Deaths = Opening Numbers ร Mortality Rate.
* Closing Numbers = Opening plus Births plus Purchases minus Sales minus Deaths.
These can be represented as variables if you want them visible in dashboards, or as intermediate drivers feeding revenue and cost.
## Step 3: Link numbers to production and revenue
For each enterprise, define production drivers, for example:
* Average Sale Weight per Head.
* Average Liveweight Gain per Day.
* Dressing Percentage to carcass weight.
* Milk Yield per Cow per Day.
* Wool Yield per Head per Shearing.
Then create Revenue variables, such as:
* Revenue - Cattle Sales - Farm North.
* Revenue - Wool Sales - Farm North.
* Revenue - Milk Sales - Farm South.
Formulas might look like:
* Sale Weight per Head ร Number Sold ร Price per Kilogram.
* Milk Yield per Cow ร Number of Cows ร Days in Period ร Price per Litre.
* Wool Yield per Head ร Number Shorn ร Price per Kilogram.
These variables should be typed as **Revenue** and can be segmented further by class or market if needed.
## Step 4: Add feed, husbandry and labour costs
Create Opex and Staff variables for key cost categories, for example:
* Opex - Purchased Feed.
* Opex - Pasture Fertiliser.
* Opex - Veterinary and Animal Health.
* Opex - Animal Handling, Tags and Equipment.
* Staff - Livestock Labour.
* Opex - Transport and Selling Costs.
Link these to drivers such as:
* Feed per head per day at different times of year.
* Vet cost per head or per treatment.
* Labour hours per head or per enterprise.
* Transport cost per head per kilometre.
Costs should scale with stocking rates, production intensity and strategy choices in scenarios.
## Step 5: Capture seasonality, grazing and finishing strategies
Use timing and scenario logic to reflect strategic choices, for example:
* Different turn off patterns by month or quarter.
* Choice of selling as store, feeder or finished stock.
* Use of supplementary feeding during dry periods.
* Decisions to increase or reduce herd size for seasonal conditions.
In each case, adjust:
* Sales and purchase numbers and weights.
* Feed and labour costs.
* Expected prices, using the Seasonality and Commodity Pricing pattern.
This allows you to compare strategies such as growing the herd versus trading more animals at lighter weights.
## Step 6: Integrate livestock into whole farm and portfolio views
Because livestock enterprises are branches within farms and the group:
* Farm level P\&L and cash views will include both livestock and other enterprises.
* Group level statements will aggregate across all farms and enterprises.
* You can compare enterprises on margin per hectare, per head or per unit of labour.
Dashboards can show:
* Numbers, production and revenue per enterprise.
* Cost structure breakdowns.
* Cash and working capital impacts across seasons.
* Contributions to debt service and valuation.
## Step 7: Use scenarios for climate, market and strategy risk
Clone the base model into scenario models to test:
* Drought or flood effects on stocking rates and production.
* Changes in sale prices, driven by commodity markets.
* Alternative strategies for destocking or rebuilding.
* Investment in improved genetics or feeding systems.
In each scenario, adjust number flows, production drivers, prices and cost structures and then compare:
* Enterprise and whole farm profitability.
* Cashflow resilience and funding needs.
* Impact on loan covenants and valuation metrics.
## Check your work
* Number flows and production estimates align with recent history or plans when calibrated.
* Costs per head and per unit of production are realistic against invoices and budgets.
* Seasonal patterns match expected grazing and feeding practice.
* Scenario outcomes are intuitive to both operations and finance stakeholders.
## Troubleshooting
Numbers or weights appear unrealistic
Check calving, mortality and sale assumptions and ensure you are not double counting head movements or using inconsistent units.
Cashflow is too spiky or too flat
Refine timing of feed purchases, sales and major events such as weaning, shearing or drying off.
Too much complexity for small enterprises
Group smaller operations into a single branch per enterprise type and keep detailed modelling only for the largest or most volatile components.
## Related guides
* [Data Workflows & Automation](/how-tos/data-workflows-and-automation)
* [Investment & Transactions](/how-tos/investment-and-transactions)
* [Fixing Merged Cells](/help/importing-and-data-inputs/fixing-merged-cells)
* [Units & Bounds Panel](/syntax/understanding-the-interface/units-and-bounds-panel)
# Seasonality & Commodity Pricing
This use case explains how to model seasonality and commodity pricing for agriculture and primary production in Model Reef.
You will:
* Build seasonal patterns for production and sales.
* Create price drivers and curves for key commodities.
* Link seasonal volumes and prices into revenue variables.
* Use scenarios to test price paths and hedging choices.
Model Reef does not pull live market prices by default. It uses imported or manually maintained price series as drivers for financial forecasts.
## When to use this pattern
Use this pattern when:
* Revenue is driven by commodities or seasonal products.
* You need to understand the impact of price and seasonal changes on cash.
* You want to connect agronomic or production plans to financial outcomes.
* You wish to explore hedging or contracting strategies at a high level.
It is used alongside:
* Crop Yield Forecasts
* Livestock Production Modelling
* Farm Level Working Capital Planning
## Architecture overview
Seasonality and commodity pricing modelling uses:
* Seasonal volume patterns
* Production or sales concentrated in specific periods.
* Different patterns for different products or channels.
* Price drivers and curves
* Historical or benchmark price series.
* Forward or scenario based price paths.
* Basis adjustments for local conditions or quality.
* Revenue integration
* Revenue variables per product and location.
* Blended prices where multiple contracts or grades exist.
* Scenario and sensitivity views
* Alternative price and basis paths.
* Different contracting or hedging shares.
{% stepper %}
{% step %}
### Step 1: Build seasonal weight or pattern drivers
In the Data Library, create seasonal pattern drivers for each product, for example:
* Seasonality Weights - Wheat Sales
* Seasonality Weights - Cattle Sales
* Seasonality Weights - Horticulture Product A
Each pattern distributes 100 percent of annual volume across periods (for example months or quarters). For example, you might have:
* 0 percent from January to August
* 20 percent in September
* 30 percent in October
* 30 percent in November
* 20 percent in December
Apply these weights to annual or total planned volumes to get per period volumes.
{% endstep %}
{% step %}
### Step 2: Create commodity price drivers
Import or define price series for key commodities, such as:
* Benchmark Price - Wheat - Export Port
* Benchmark Price - Beef - Grid
* Benchmark Price - Milk - per Litre
* Benchmark Price - Cotton - per Bale
You can represent prices as:
* Historical time series imported from CSV or external sources
* Forward curves based on current markets
* Scenario based curves constructed manually
Add basis or quality adjustment drivers where relevant, such as:
* Local Basis - Wheat - Farm North
* Quality Discount - Livestock - Lower Grade
These adjustments will produce an effective on-farm or realised price.
{% endstep %}
{% step %}
### Step 3: Link volume and price into revenue variables
For each commodity and location, create Revenue variables, for example:
* Revenue - Wheat Sales - Farm North
* Revenue - Cattle Sales - Farm North
* Revenue - Fruit Sales - Region A
Formulas might be:
* Volume per Period = Annual Volume ร Seasonality Weight per Period
* Effective Price = Benchmark Price plus Basis plus Quality Adjustment
* Revenue = Volume per Period ร Effective Price
If you have multiple contract types, you can:
* Create separate variables for contracted and spot volumes
* Apply different price series to each and combine them in reporting views
Set timing so that cash receipts align with delivery and contract terms.
{% endstep %}
{% step %}
### Step 4: Represent simple hedging or contracting strategies
To explore hedging at a planning level, define drivers such as:
* Hedged Proportion of Volume
* Fixed Contract Price
* Spot Volume Share = 1 minus Hedged Share
Implement revenue as the sum of:
* Hedged Revenue = Hedged Volume ร Fixed Price
* Spot Revenue = Spot Volume ร Spot Price Series
This keeps logic within Model Reef's arithmetic formula engine and avoids complex derivatives modelling while still capturing the main financial effect.
{% endstep %}
{% step %}
### Step 5: Use scenarios for price and basis paths
Clone the model into scenario models to represent different price environments, for example:
* Base case using current forward curves
* High price environment with favourable basis
* Low price environment with adverse basis
* Volatile environment with significant swings over time
In each scenario, adjust:
* Benchmark price series
* Basis and quality adjustment drivers
* Hedging proportions and fixed contract prices
Compare scenarios using:
* Revenue and margin per commodity and location
* Cashflow volatility and working capital requirements
* Debt servicing capacity and valuation changes
{% endstep %}
{% step %}
### Step 6: Integrate seasonality and pricing into whole farm planning
Because seasonal and pricing drivers feed revenue variables:
* Whole farm P\&L and Cashflow outputs will reflect commodity risk
* You can combine crop, livestock and other enterprises in the same model
* Dashboards can show revenue composition by commodity and region
This makes it easier to answer questions such as:
* How sensitive is the business to wheat prices versus livestock prices?
* How do different hedging strategies affect cash and debt risk?
* How does changing the enterprise mix alter exposure to specific commodities?
{% endstep %}
{% endstepper %}
## Check your work
* Seasonal patterns match historical delivery or sales profiles.
* Benchmarks and basis adjustments correspond to real market data or informed assumptions.
* Scenario price paths are plausible and grounded in current conditions or stress test requirements.
* Hedge and contract modelling remains at a level of detail that can be maintained.
## Troubleshooting
Revenue seasonality looks wrong
Check that seasonality weights sum to 100 percent for each product and that volume drivers align with production plans.
Price levels seem inconsistent with market data
Validate benchmark and basis settings against external sources and internal sales records.
Too many price series to manage
Group similar products and locations where possible and use shared price drivers with local basis adjustments rather than separate full curves.
## Related guides
* [Operations & Unit Economics](/how-tos/operations-and-unit-economics)
* [Valuation](/how-tos/valuation)
* [Folder Structure](/help/workspace-and-organisation/folder-structure)
* [Units & Display](/syntax/variables-syntax/units-and-display)
# Farm-Level Working Capital Planning
This use case explains how to plan farm level working capital needs for agriculture and primary production using Model Reef.
You will:
* Model seasonal patterns of receipts and payments.
* Track receivables, payables and inventory like effects.
* Understand cash draw, repayment and surplus periods.
* Plan working capital facilities and buffers.
Model Reef is not a banking system. It provides a planning view that connects enterprise forecasts to working capital and funding decisions.
{% hint style="info" %}
Model Reef provides a planning view (not a transaction banking system) that connects enterprise forecasts to working capital and funding decisions.
{% endhint %}
## When to use this pattern
Use this pattern when:
* Your farm or agribusiness has strong seasonality in cashflows.
* You use overdrafts, trade finance or supplier credit.
* You need to understand cash peaks and troughs across seasons and years.
* You want to connect enterprise level plans to funding requirements.
It is usually built on top of:
* Crop Yield Forecasts
* Livestock Production Modelling
* Seasonality and Commodity Pricing
## Architecture overview
Farm level working capital planning uses:
* Enterprise cashflows
* Revenue timing from crop and livestock sales.
* Input, labour and overhead spend timing.
* Working capital drivers
* Debtor days for customers or buyers.
* Creditor days for suppliers.
* Inventory like behaviour for stored product.
* Facilities and funding
* Overdrafts or seasonal working capital facilities.
* Term debt that interacts with cashflows.
* Equity contributions or drawings.
* Reporting
* Cashflow Statement and Cash Waterfall.
* Cash balance, headroom and covenant metrics.
{% stepper %}
{% step %}
### Ensure enterprise models have realistic timing
First, ensure crop and livestock models apply realistic timing settings for:
* When revenue is recognised versus when cash arrives.
* When inputs, feed and labour are paid for.
* When storage, freight and other costs fall in the calendar.
This timing will automatically create receivables and payables in the Balance Sheet and drive working capital needs.
{% endstep %}
{% step %}
### Define working capital drivers explicitly
In the Data Library, create drivers such as:
* Debtor Days for major buyer segments.
* Creditor Days for key suppliers.
* Average Storage Period before sale.
* Target Cash Buffer (for example minimum days of cash).
If you want to approximate inventory, you can:
* Use Asset variables to represent `Inventory - Grain` or `Inventory - Livestock` with inflows from production and outflows to sales.
* Use Liability variables for deferred payments or advances.
These variables will interact with revenue and cost timing to shape working capital.
{% endstep %}
{% step %}
### Add working capital facilities
Create Liability variables for working capital facilities, for example:
* Debt - Overdraft Facility.
* Debt - Seasonal Working Capital Line.
Decide on a representation:
* Simple planning: represent these as interest only facilities with balances that you set via drivers or scenarios.
* More detailed: link facility drawdowns and repayments to cash balance thresholds using manual schedules or scenario specific assumptions.
Set interest rates and payment timing so that:
* Interest expense appears in P\&L.
* Cashflow Statement and Cash Waterfall show draw and repay movements.
* Balance Sheet reflects facility balances at each period end.
{% endstep %}
{% step %}
### Build cash and headroom dashboards
Create dashboards focused on working capital, including:
* Cash balance over time at farm and group level.
* Net cash including overdrafts and working capital lines.
* Highest and lowest cash points per season or year.
* Utilisation of facilities versus limits.
* Simple covenant or threshold metrics, such as minimum cash days or maximum facility utilisation percentage.
Use these views to identify:
* Periods where additional funding or cost deferral may be required.
* Opportunities to deploy surplus cash to capex or debt reduction.
* The effect of operating changes on working capital needs.
{% endstep %}
{% step %}
### Use scenarios for seasonal and funding risk
Clone the model into scenario models for:
* Adverse seasons with lower yields or prices and similar fixed costs.
* Favourable seasons with strong production and prices.
* Changes in payment terms with buyers or suppliers.
* Changes in facility limits, interest rates or availability.
In each scenario, adjust:
* Enterprise production and price assumptions.
* Debtor and creditor day drivers.
* Facility limit and pricing assumptions.
* Any planned capex or equity movements.
Compare scenarios using:
* Cash balance and facility utilisation patterns.
* Periods where facilities are fully drawn or breached.
* Sensitivity of working capital to key drivers.
* Implications for discussions with lenders and investors.
{% endstep %}
{% step %}
### Integrate with whole farm and group planning
Because working capital facilities and drivers operate at farm and group branches:
* Farm level reports show cash and facility needs per farm.
* Group level reports show aggregate requirements and headroom.
* Boards, investors and banks can see a coherent picture from enterprise forecasts through to funding needs.
You can also connect working capital planning to:
* Capex and expansion decisions.
* Risk management and hedging choices.
* Long term strategy for gearing and resilience.
{% endstep %}
{% endstepper %}
## Check your work
{% hint style="info" %}
* Debtor and creditor day assumptions reflect actual terms and behaviour.
* Cashflow patterns make sense when compared to bank statements or historical cashflow summaries.
* Facility limits and terms align with actual banking arrangements.
* Scenario outputs line up with management experience of stress and recovery periods.
{% endhint %}
## Troubleshooting
Model shows more cash than expected in busy seasons
Revisit timing of input costs and ensure that you have not used overly optimistic creditor days.
Facilities appear insufficient or excessive
Adjust facility limit drivers based on scenario analysis and consider different strategies for drawdowns and repayments.
Difficult to trace working capital effects back to enterprises
Use reports and dashboards that show enterprise level cash contributions alongside facility utilisation and changes in receivables and payables.
## Related guides
* [Build a Working Capital Model](/how-tos/operations-and-unit-economics/build-a-working-capital-model)
* [Build a Capital Raise Model](/how-tos/investment-and-transactions/build-a-capital-raise-model)
* [Fundamental Data Mapping](/help/stock-ticker-fundamentals/fundamental-data-mapping)
* [Using Drivers in Formulas](/syntax/drivers-syntax/using-drivers-in-formulas)
# โ๏ธ Mining, Energy & Natural Resources
# Mine/Well Production Forecasts
This use case explains how to forecast production volumes and revenue for mines, wells and other resource assets in Model Reef.
You will:
* Represent mines, wells or fields as branches and sub-branches.
* Build drivers for ore mined, ore processed, grades, recoveries and product yields.
* Connect production to commodity prices, realisations and revenue.
* Capture timing, ramp-up, decline and shut-down behaviour.
Model Reef is not a geological or reservoir simulator. It consumes high-level mine plan or reservoir assumptions and transforms them into financial statements, cashflows and valuations.
## When to use this pattern
Use this pattern when:
* Production is driven by mining or extraction of a finite resource.
* You need a forward view of tonnes, grades, recoveries and saleable product.
* You want to link life-of-mine or field plans to P\&L, Balance Sheet and Cashflow.
* You need to test price, volume, recovery and cost scenarios.
It works well with:
* Capex & Equipment Lifecycle Model
* Commodity Price Sensitivity
* Multi-Site Resource Consolidation
* Valuation Engine Overview
## Architecture overview
{% stepper %}
{% step %}
### Structure
* Branches for sites, pits, seams or fields.
* Optional sub-branches for stages, benches or development areas.
{% endstep %}
{% step %}
### Production drivers
* Ore or fluid throughput.
* Grades and recoveries.
* Product yields for one or more saleable products.
{% endstep %}
{% step %}
### Price and revenue drivers
* Benchmark and realised prices.
* Payable percentages and penalties.
* Currency where relevant.
{% endstep %}
{% step %}
### Timing and life of asset
* Ramp-up, steady-state and decline phases.
* Scheduled shutdowns, maintenance and end-of-life.
{% endstep %}
{% endstepper %}
## Step 1: Set up branches for mines, wells and sites
In the branch tree, create a structure that matches how you report operationally, for example:
* Resources Group
* Mine - Open Cut A
* Pit - Stage 1
* Pit - Stage 2
* Mine - Underground B
* Field - Gas C
* Central Overheads
Each mine or field branch should hold that site's production, costs and, in many cases, site-specific capex and rehabilitation provisions. Central Overheads can hold group management, corporate functions and shared costs.
{% stepper %}
{% step %}
### Build ore or fluid throughput and grade drivers
In the Data Library, create time-series drivers for each producing asset, for example:
* Ore Mined - Mine A (tonnes per period).
* Ore Processed - Mine A (tonnes per period).
* Head Grade - Mine A (for example grams per tonne or percentage).
* Recovery Rate - Mine A (percentage).
* Fluid Production Rate - Well A (barrels or cubic metres per period).
For multi-product assets, create separate grade and recovery drivers per product where required.
Drivers can be:
* Imported from mine schedules or reservoir models.
* Smoothed from high-level annual plans.
* Scenario-specific for different ramp-up or depletion paths.
From these, define production quantities such as:
* Metal in Ore = Ore Processed ร Grade.
* Recovered Product = Metal in Ore ร Recovery Rate.
* Saleable Product after processing and losses.
{% endstep %}
{% step %}
### Connect production to revenue
Next, create Revenue variables per product and site, for example:
* Revenue - Copper Concentrate - Mine A.
* Revenue - Gold Bullion - Mine B.
* Revenue - Gas Sales - Field C.
For each, specify:
* Benchmark price driver (for example LME, index or contract reference).
* Realisation factors such as treatment and refining charges, payables and penalties.
* Currency drivers if you need to approximate foreign currency revenue.
Formulas might look like:
* Realised Price = Benchmark Price ร Payable Percentage - Treatment and Refining Charges per Unit.
* Revenue = Saleable Product Quantity ร Realised Price.
Where a site produces multiple products, repeat this process for each and let P\&L aggregate them via standard Revenue mapping.
{% endstep %}
{% step %}
### Represent ramp-up, steady-state and decline
Use production and grade drivers to reflect the asset life cycle, for example:
* Low volumes in early development and commissioning periods.
* Ramp-up to nameplate capacity over a defined period.
* Steady-state for a number of years.
* Decline as ore or reservoir quality decreases or volumes drop.
* Final shutdown at end-of-life with residual production.
You can:
* Shape throughput and grade drivers directly, or
* Apply modifiers that adjust base throughput and grade by phase.
Ensure that ramp-up and decline patterns align with your technical planning work, and use scenarios to capture uncertainty in ramp-up speed and ultimate recoveries.
{% endstep %}
{% step %}
### Capture operating cost structures linked to production
Create Opex and Staff variables that link to production drivers, for example:
* Opex - Mining Costs - per Tonne Mined.
* Opex - Processing Costs - per Tonne Processed.
* Opex - Power and Utilities - per Tonne or per Unit of Product.
* Opex - Royalties and Production Taxes - per Unit or Percentage of Revenue.
* Staff - Site Operations and Maintenance Teams.
Formulas can be:
* Mining Cost = Ore Mined ร Cost per Tonne Mined.
* Processing Cost = Ore Processed ร Cost per Tonne Processed.
* Royalties = Revenue ร Royalty Rate.
This keeps costs aligned with production volumes and makes margin sensitivity analysis more meaningful.
{% endstep %}
{% step %}
### Add shutdowns, maintenance and unscheduled downtime
Use timing and frequency settings or modifiers to represent:
* Planned shutdowns for major maintenance.
* Seasonal restrictions that limit production.
* Unplanned downtime allowances based on historical performance.
This is often implemented as:
* Uptime factors applied to throughput drivers.
* Additional Opex variables for major maintenance events.
* Adjustments to cost drivers when running at partial capacity.
The aim is to ensure that both production and cost patterns capture realistic operating schedules.
{% endstep %}
{% step %}
### Use scenarios for volume, grade and recovery risk
Clone the mine or portfolio model into scenario models to test:
* Different grade and recovery paths (for example optimistic, base and pessimistic).
* Higher or lower throughput rates.
* Different ramp-up durations and start dates.
* Changes in product mix or by-product credits.
In each scenario, adjust relevant drivers and examine:
* Revenue and margin patterns over time.
* Cashflow profiles and peak funding requirements.
* Life-of-mine or field valuation metrics from the Valuation Engine.
* Impact on debt capacity and covenant headroom.
{% endstep %}
{% endstepper %}
## Check your work
* Production profiles match mine plans or engineering outputs when calibrated.
* Revenue and cost structures reconcile to historical performance for operating assets.
* Ramp-up and decline behaviour looks realistic to operational and technical stakeholders.
* Scenario outcomes align qualitatively with risk narratives used internally.
## Troubleshooting
Production volumes do not match technical schedules
Check that you are using the same unit basis, time resolution and loss factors as your mine planning team and that you have not double counted recoveries.
Margins behave strangely at low throughput
Separate fixed and variable costs where helpful and ensure volume linked cost drivers are not applied to zero or minimal production periods unless that reflects real costs.
Model feels overly complex for early stage studies
Start with simple annual average grades and recoveries, then only add more detailed patterns when you have better information or the decision warrants it.
## Related guides
* [Build a Board Reporting Pack](/how-tos/dashboards-and-reporting/build-a-board-reporting-pack)
* [Build a Bottom Up Forecast](/how-tos/core-modelling/build-a-bottom-up-forecast)
* [Historical Fundamentals Imported](/help/stock-ticker-fundamentals/historical-fundamentals-imported)
* [Variable Type](/syntax/variables-syntax/variable-type)
# Capex & Equipment Lifecycle Model
This use case explains how to model capital expenditure, equipment fleets and lifecycle costs for mining, energy and natural resources organisations in Model Reef.
You will:
* Represent major capital items and projects as Asset variables.
* Plan initial capex, sustaining capex and replacement programmes over time.
* Model equipment operating costs and productivity links.
* Connect capex and lifecycle assumptions to depreciation, cashflows and valuation.
Model Reef is not a maintenance management system. It focuses on financial planning for capex and equipment, not detailed work order scheduling.
## When to use this pattern
Use this pattern when:
* Your business relies on heavy equipment, plants, pipelines or infrastructure.
* You need to understand timing and magnitude of capex and replacement cycles.
* You want to compare different fleet or plant strategies.
* You must show lenders and investors a coherent capex plan alongside production.
It is commonly paired with:
* Mine or Well Production Forecasts
* Commodity Price Sensitivity
* Multi-Site Resource Consolidation
## Architecture overview
{% stepper %}
{% step %}
### Asset representation
* Asset classes for fleets, plants, infrastructure and intangible assets.
* Existing assets with opening balances.
* Future capex projects.
{% endstep %}
{% step %}
### Lifecycle and replacement
* Useful lives and replacement triggers.
* Sustaining and growth capex.
* Decommissioning or rehabilitation where relevant.
{% endstep %}
{% step %}
### Operating cost and productivity links
* Operating cost patterns tied to equipment usage.
* Impact on production capacity or efficiency.
{% endstep %}
{% step %}
### Financial outputs
* Depreciation in P\&L.
* Asset and accumulated depreciation balances.
* Capex cashflows and valuation effects.
{% endstep %}
{% step %}
### Define asset classes and branches
In the branch tree, decide where to hold equipment and infrastructure capex, for example:
* Mine - Open Cut A
* Assets - Mobile Fleet
* Assets - Fixed Plant
* Mine - Underground B
* Assets - Mining Fleet
* Field - Gas C
* Assets - Well Infrastructure
* Central Infrastructure
* Assets - Shared Rail & Port
Alternatively, store all capex in the site branch without sub-branches and use categories to separate asset types. The choice depends on how you want to report and analyse.
{% endstep %}
{% step %}
### Set up opening balances for existing assets
For existing operations, import or enter:
* Opening asset balances by class, aligned with the latest Balance Sheet.
* Remaining useful life estimates or depreciation rules.
* Any major deferred projects already committed.
Represent these as Asset variables with:
* Opening balances.
* Depreciation methods (for example straight line).
* Remaining life inputs where supported or approximated.
This ensures the model starts from a realistic asset base.
{% endstep %}
{% step %}
### Plan initial, sustaining and growth capex
Create Asset variables for planned projects, for example:
* Capex - Replacement Trucks - Mine A.
* Capex - New Processing Line - Mine B.
* Capex - Pipeline Expansion - Field C.
* Capex - Control Systems Upgrade - Shared Infrastructure.
For each, specify:
* Total capex budget or unit cost per item.
* Timing profile across periods, such as upfront, phased or milestone based.
* Expected useful life and depreciation method.
* Whether the project is sustaining (replacing life expired assets) or growth (increasing capacity).
Use drivers to represent fleet strategies, for example number of units and replacement intervals, so scenarios can vary:
* Fleet size.
* Replacement timing.
* Mix of new versus refurbished assets.
{% endstep %}
{% step %}
### Link capex to production capacity where needed
Where production depends on equipment capacity, create drivers such as:
* Capacity per Truck.
* Capacity per Processing Line.
* Relating fleet size to maximum throughput.
Use these drivers in production models to ensure:
* Insufficient fleet or plant limits production.
* Additional capex unlocks higher throughput or reduces unit costs.
* Deferred capex may constrain volumes or increase operating risk.
Keep this linkage as simple as possible while still capturing the main relationships.
{% endstep %}
{% step %}
### Model operating costs and lifecycle impacts
Create Opex variables for equipment related operating costs, for example:
* Opex - Maintenance - Mobile Fleet.
* Opex - Fuel & Power - Plant A.
* Opex - Tyres & Wear Parts.
* Opex - External Repairs.
Link these to drivers such as:
* Hours used per period.
* Production volumes.
* Fleet size or age.
You can reflect lifecycle effects by:
* Higher maintenance cost factors for older fleets.
* Reduced availability or uptime multipliers.
* Step changes in cost structure when new equipment is commissioned.
This enables comparison of strategies such as run-to-failure versus systematic replacement.
{% endstep %}
{% step %}
### Include rehabilitation or decommissioning provisions
For mines and some energy assets, include:
* Asset or Liability variables for rehabilitation provisions.
* Cash outflows for rehabilitation activities near or after closure.
* Depreciation or unwinding of provisions depending on accounting policy.
While Model Reef does not perform full provision accounting, you can approximate expected cash and P\&L impacts at life-of-asset end.
{% endstep %}
{% step %}
### Use scenarios for capex strategy and timing
Clone the model into scenario models to test:
* Different fleet replacement intervals and sizes.
* Deferral or acceleration of major projects.
* Alternative processing routes or plant configurations.
* Changes in cost and productivity associated with new technology.
In each scenario, adjust:
* Timing and scale of capex variables.
* Operating cost and productivity drivers.
* Production forecasts where capacity is constrained or increased.
Compare scenarios using:
* Capex and operating cost per unit of production.
* Cashflow and funding requirements.
* Valuation outcomes from the Valuation Engine.
* Risk profiles associated with deferred maintenance and replacement.
{% endstep %}
{% endstepper %}
## Check your work
* Opening balances and depreciation reconcile to recent financial statements.
* Planned capex and lifecycle assumptions are aligned with internal maintenance and growth plans.
* Operating cost patterns are consistent with historical data.
* Scenario comparisons reflect realistic operational choices and constraints.
## Troubleshooting
Depreciation profiles do not match accounting schedules
Adjust asset lives, methods and opening balances to approximate accounting policies more closely while keeping the model manageable.
Capex timing appears too jagged or unrealistic
Smooth capex curves where appropriate and represent contingency or small projects in aggregated variables instead of modelling every minor item.
Difficult to link capex strategy to production
Start with simple capacity constraints and only introduce more detailed relationships when necessary for decision making.
## Related guides
* [Build a Capex & Depreciation Model](/how-tos/operations-and-unit-economics/build-a-capex-and-depreciation-model)
* [Build a Budget vs Actuals Model](/how-tos/scenarios-and-planning/build-a-budget-vs-actuals-model)
* [How Variables Are Created](/help/stock-ticker-fundamentals/how-variables-are-created)
* [Variables Syntax](/syntax/variables-syntax)
# Commodity Price Sensitivity
This use case explains how to model commodity price sensitivity for mining, energy and natural resources assets in Model Reef.
You will:
* Create benchmark and realised price drivers for key commodities.
* Apply price paths and scenarios to production volumes.
* Explore different contract, hedge and currency settings.
* See how price changes affect margin, cash and valuation.
Model Reef does not execute trades or hedges. It provides a planning layer on top of market assumptions and hedging policies.
***
## When to use this pattern
Use this pattern when:
* Revenue is materially dependent on commodity prices.
* You want to quantify upside and downside cases.
* You need to show lenders or investors sensitivity to price paths.
* You plan to compare different hedging or contracting strategies.
It is usually combined with:
* Mine or Well Production Forecasts
* Capex & Equipment Lifecycle Model
* Multi-Site Resource Consolidation
* Valuation Engine Overview
***
## Architecture overview
Commodity price sensitivity modelling uses:
1. Price drivers
* Benchmark indices or contract references.
* Basis, quality and location adjustments.
* Currency assumptions and FX modifiers.
2. Volume inputs
* Production forecasts from mine or well models.
* Sales volumes by product, grade or contract.
3. Revenue construction
* Realised price per product.
* Revenue per product, site and group.
4. Sensitivity and scenarios
* Systematic price shifts or curves.
* Different hedging and contracting proportions.
***
## Steps
{% stepper %}
{% step %}
### Define benchmark price series
In the Data Library, create or import time-series for:
* Benchmark Price - Product A (for example copper, gold, LNG).
* Benchmark Price - Product B.
* Benchmark Price - By-Product C where relevant.
These may be:
* Historical series used to calibrate the model.
* Forward curves or consensus forecasts.
* Scenario-specific paths for base, high and low price environments.
Keep series in consistent units with your production models.
{% endstep %}
{% step %}
### Add basis, quality and location adjustments
Realised prices often differ from benchmarks. Create drivers for:
* Payable Percentage (for example 95 percent of contained metal).
* Treatment and Refining Charges in the case of concentrates.
* Shipping and handling costs per unit.
* Location basis adjustments reflecting local market conditions.
* Penalties or premiums for specific quality attributes.
Combine these into effective realised price drivers, for example:
* Realised Price = Benchmark Price ร Payable Percentage - Treatment and Refining Charges - Shipping - Penalties + Premiums.
You can implement these in formulas within Revenue variables or as separate intermediate drivers.
{% endstep %}
{% step %}
### Link prices to production volumes
From your production models, bring through:
* Saleable production volumes per period per product and site.
* Sales splits by contract type if relevant.
Create Revenue variables such as:
* Revenue - Copper - Mine A.
* Revenue - Gold - Mine B.
* Revenue - LNG - Field C.
Set formulas like:
* Revenue - Copper - Mine A = Saleable Copper Volume - Mine A ร Realised Copper Price - Mine A.
Because volumes are already computed in production models, price changes will flow directly into revenue without changing those volumes.
{% endstep %}
{% step %}
### Represent simple hedging and contract structures
To incorporate basic hedging and contract strategies, define drivers for:
* Hedged Volume Share per commodity.
* Fixed Contract Prices for hedged volumes.
* Spot Volume Share = 1 minus Hedged Volume Share.
Implement revenue as the sum of:
* Hedged Revenue = Hedged Volume ร Fixed Contract Price.
* Spot Revenue = Spot Volume ร Spot Price Series.
Where you use collars or more complex instruments, approximate the effect by adjusting effective fixed and floating prices in scenarios rather than modelling instruments directly.
{% endstep %}
{% step %}
### Build price sensitivity and scenario views
Clone the base model into scenario models that represent:
* Base case prices (for example consensus or current forward curves).
* Downside case with lower prices for a period or across life of asset.
* Upside case with higher prices.
* Shock scenarios where prices fall sharply for a period then recover.
In each scenario, adjust benchmark price series, basis and contract settings. Then compare:
* Revenue and margin per asset and for the group.
* Cashflow and funding metrics.
* Valuation outcomes via the Valuation Engine.
* Headroom relative to debt covenants or investment hurdles.
You can also produce one off sensitivity tables by changing price drivers by a fixed percentage and inspecting key outputs.
{% endstep %}
{% step %}
### Integrate FX where required
If your commodity is priced in a foreign currency but financial statements are in a local currency, you can:
* Import or create FX rate series as drivers.
* Express benchmark prices in foreign currency and convert in formulas, for example:\
Local Price = Foreign Price ร FX Rate Driver.
Use scenarios to test combined commodity and FX risk by adjusting both price and FX series in different combinations.
{% endstep %}
{% endstepper %}
***
## Check your work
* Benchmark prices and adjustments reflect market data or agreed planning bases.
* Realised prices reconcile to historical realised revenue when volumes are held constant.
* Hedging and contracting assumptions can be explained to non technical stakeholders.
* Scenario results are consistent with risk appetite and external disclosures where relevant.
***
## Troubleshooting
Revenue does not reconcile with historical results
Revisit payables, treatment and refining charges, penalties and FX rates to ensure they are aligned with actual contracts and invoices.
Sensitivity results appear extreme or muted
Check that you are not double counting hedging effects or failing to apply price changes across all relevant products and sites.
Too many series to manage for small products
Group minor products into aggregated baskets and apply a single representative price and basis series rather than modelling each individually.
***
## Related guides
* [Build a Sensitivity Analysis Pack](/how-tos/scenarios-and-planning/build-a-sensitivity-analysis-pack)
* [Build a Valuation Sensitivity Model](/how-tos/valuation/build-a-valuation-sensitivity-model)
* [IRR Calculation](/help/financial-outputs-and-valuation/irr-calculation)
* [Vectorised Calculations](/syntax/formula-syntax/vectorised-calculations)
# Multi-Site Resource Consolidation
This use case explains how to consolidate production, costs, cashflows and valuations across multiple mines, wells and resource sites in Model Reef.
You will:
* Represent each asset as a branch with its own production and cost model.
* Group assets by commodity, region or business unit in the branch tree.
* Add central overheads, group funding and corporate structures.
* Produce consolidated P\&L, Balance Sheet, Cashflow, Cash Waterfall and valuation outputs.
The goal is to support portfolio level decision making while retaining site level transparency.
## When to use this pattern
Use this pattern when:
* You operate or invest in multiple mines, wells or resource projects.
* You need consolidated reporting at region, commodity and group level.
* You compare assets and portfolios in different price and volume scenarios.
* You need a single model for board, investor and lender communication.
It builds on:
* Mine or Well Production Forecasts
* Capex & Equipment Lifecycle Model
* Commodity Price Sensitivity
* Build a Multi Entity Group Model
## Architecture overview
Multi-site resource consolidation uses:
1. Branch structure
* Group root branch.
* Site branches for each mine, well or project.
* Optional intermediate branches for commodity or region.
* Central overhead and financing branches.
2. Site level models
* Production, revenue and cost structures per site.
* Site specific capex, rehabilitation and funding.
3. Central structures
* Group debt, cash and equity.
* Corporate overheads and shared services.
* Hedging policies represented at group level where relevant.
4. Reporting and dashboards
* Site, region and group level views.
* Scenario comparisons across the portfolio.
{% stepper %}
{% step %}
### Design the portfolio branch tree
Define a branch tree that reflects operating and reporting structures, for example:
* Resources Group
* Region - Americas
* Mine - Copper A
* Mine - Gold B
* Region - Asia Pacific
* Mine - Coal C
* Field - Gas D
* Projects
* Project - Lithium E
* Central Overheads
* Group Funding
Alternative structures might group by commodity first, then region. The key is to choose a layout that matches how performance is managed and reported.
{% endstep %}
{% step %}
### Attach site level production and financial models
Within each site branch, implement:
* Mine or Well Production Forecasts for that site.
* Capex & Equipment Lifecycle Model for site assets.
* Site specific Opex and staff structures.
* Site level rehabilitation provisions if appropriate.
Ensure consistency of naming and categories across sites, for example:
* Revenue - Product X - Site Y.
* Opex - Mining - Site Y.
* Opex - Processing - Site Y.
* Opex - Site G\&A.
* Debt - Site Level Facility - Site Y.
Consistency makes it easier to compare sites and consolidate across them.
{% endstep %}
{% step %}
### Model central overheads and group funding
Create branches or variables for:
* Corporate and regional overheads, such as head office, legal, finance and exploration teams.
* Group debt facilities that sit above individual sites.
* Equity injections, distributions and buy backs at group level.
* Group cash, investments and reserves.
This allows you to distinguish:
* Pure operating performance at site level.
* Impact of corporate structures and funding at group level.
You may also represent intercompany funding structures in a simplified way, while ensuring that consolidated outputs remain correct.
{% endstep %}
{% step %}
### Build consolidated reports and dashboards
Using Model Reef reporting and dashboard tools, create views that show:
Site level views
* P\&L per site, including production and cost breakdowns.
* Site level contribution to group EBITDA and cash.
* Operating metrics such as unit cash costs and margins.
Region or commodity level views
* Aggregated revenue and cost by region or commodity.
* Production tonnages and product mix.
* Regional or commodity level margins and cashflows.
Group level views
* Consolidated P\&L across all sites and corporate structures.
* Balance Sheet including group debt and equity.
* Cashflow Statement and Cash Waterfall.
* Valuation metrics for the group and optionally per site.
Filters and branch selections allow users to move from site to region to group views smoothly.
{% endstep %}
{% step %}
### Use scenarios for portfolio and capital allocation decisions
Clone the consolidated model into scenario models to test:
* Different asset portfolios, including acquisitions and divestments.
* Changes to capital allocation between sites and projects.
* Alternative production, price and cost environments.
* Different funding strategies at group level.
In each scenario, adjust:
* Which site branches are enabled, added or removed.
* Production and cost drivers per site.
* Capex, funding and hedging assumptions.
* Corporate overhead and structure assumptions.
Compare scenarios using:
* Group and site level cash and valuation metrics.
* Debt capacity and covenant headroom.
* Concentration of risk by commodity, region or asset type.
* Returns on capital for different portfolio configurations.
{% endstep %}
{% step %}
### Support board, investor and lender reporting
Because the same model underpins site, region and group views, you can:
* Provide consistent base, upside and downside scenarios across all stakeholders.
* Reuse charts and tables across internal and external presentations.
* Demonstrate how portfolio composition and funding choices drive group outcomes.
* Use the Valuation Engine to connect cashflows and capital allocation decisions to value.
Model Reef does not replace specialised reserve, resource or technical reporting, but it provides a compatible financial overlay.
{% endstep %}
{% endstepper %}
## Check your work
* Site models reconcile to local management forecasts or historical performance when calibrated.
* Central structures match the latest group financial statements.
* Branch structure supports the required management and governance views.
* Scenario results remain interpretable and explainable to non modelling stakeholders.
## Troubleshooting
Group results do not match external financial reports
Reconcile opening balances, central costs and financing, and confirm that all relevant site branches are enabled and correctly configured.
Portfolio comparisons are noisy or hard to interpret
Standardise key metrics across sites and use normalised measures such as margin per tonne or per unit of capacity in addition to absolute measures.
Model becomes too large or complex
Aggregate smaller or less material sites and keep detailed site level modelling for large or strategically important assets only.
## Related guides
* [Build a Multi Division Model](/how-tos/core-modelling/build-a-multi-division-model)
* [Build a Multi Entity Group Model](/how-tos/core-modelling/build-a-multi-entity-group-model)
* [Imported Variable Behaviour](/help/drivers-variables-and-timing/imported-variable-behaviour)
* [Viewing Scenario Differences](/syntax/scenario-syntax/viewing-scenario-differences)
# ๐ฆ Wholesale, Distribution & B2B Trade
# SKU & Margin Forecasting
This use case explains how to forecast SKU level revenue and margins for wholesale, distribution and B2B trade businesses in Model Reef.
You will:
* Represent product hierarchies and channels in the branch and category structure.
* Build drivers for volumes, prices, discounts and unit costs per SKU.
* Model gross margin by product, customer or channel.
* Connect SKU forecasts to P\&L, Cashflow and valuation outputs.
Model Reef is not an inventory planning system. It uses high level SKU and margin assumptions to produce financial statements, cash forecasts and scenarios.
## When to use this pattern
Use this pattern when:
* You sell many SKUs through multiple channels or customer segments.
* Gross margin and mix are critical to performance.
* You need to understand the impact of price, discount and cost changes.
* You want to link SKU economics to customer, warehouse or portfolio views.
It combines well with:
* Inventory Replenishment Cycles
* Warehouse Capacity and Logistics Model
* Customer Level Revenue Modelling
* Build a Unit Economics Model
## Architecture overview
SKU and margin forecasting uses:
1. Structure
* Branches for regions, business units or channels.
* Categories for product families and SKU groupings.
2. Volume and price drivers
* Units sold per SKU or SKU group.
* List prices, discounts and net prices.
* Channel or customer specific pricing where relevant.
3. Cost and margin drivers
* Unit cost of goods sold per SKU.
* Freight, handling and other variable costs.
* Gross margin targets and checks.
4. Financial outputs
* Revenue and COGS by SKU family.
* Gross margin by product, customer or channel.
* Cashflow and working capital impacts when combined with inventory logic.
{% stepper %}
{% step %}
### Step 1: Decide on SKU aggregation level
Modelling every SKU individually may be unnecessary and hard to maintain. Decide whether to model at the level of:
* Individual high value or high volume SKUs.
* Product families, lines or brands.
* Price bands or margin tiers.
* Customer or channel specific bundles.
As a rule of thumb:
* Model key SKUs that materially move the P\&L individually.
* Group long tail SKUs into aggregated buckets with average price and margin.
Define a simple product hierarchy that can be reflected in categories and naming.
{% endstep %}
{% step %}
### Step 2: Create product and SKU structures
Use categories and variable names to represent products, for example:
* Revenue - Product Family A - SKU Key 1.
* Revenue - Product Family A - SKU Group Tail.
* Revenue - Product Family B - SKU Key 2.
* COGS - Product Family A - SKU Key 1.
* COGS - Product Family B - SKU Key 2.
If you have channel specific pricing or mix, you can set up branches such as:
* Region - UK
* Channel - Direct
* Channel - Distributor
* Region - EU
* Channel - Direct
* Channel - Distributor
Then place SKU revenue variables in the appropriate branches.
{% endstep %}
{% step %}
### Step 3: Build volume and price drivers
In the Data Library, create drivers for each SKU or SKU group, such as:
* Units Sold per Period.
* List Price per Unit.
* Average Discount Percentage.
* Net Price per Unit = List Price ร (1 minus Discount Percentage).
Volume drivers can be:
* Imported from historical sales.
* Built from customer level models.
* Driven by growth, seasonality or campaign assumptions.
For each SKU revenue variable, define a formula like:
* Revenue - SKU Key 1 = Units Sold - SKU Key 1 ร Net Price per Unit - SKU Key 1.
This keeps price and volume assumptions separate and easy to adjust in scenarios.
{% endstep %}
{% step %}
### Step 4: Model unit costs and gross margin
Create COGS variables per SKU or SKU group, for example:
* COGS - SKU Key 1.
* COGS - SKU Group Tail.
* COGS - Product Family B.
Link them to drivers such as:
* Unit Cost per SKU (landed cost including freight and duties).
* Additional variable costs per order or per shipment.
* Supplier rebate or discount schemes expressed as effective cost reductions.
Formula examples:
* COGS - SKU Key 1 = Units Sold - SKU Key 1 ร Unit Cost per Unit - SKU Key 1.
Where you have supplier rebates based on volume or spend, approximate their effect as an adjustment to effective unit cost in the forecast.
Gross margin can then be analysed as:
* Gross Margin per SKU = Revenue per SKU minus COGS per SKU.
* Gross Margin Percentage per SKU = Gross Margin per SKU divided by Revenue per SKU.
Use dashboards and reports to view gross margin by product family, SKU, customer or channel.
{% endstep %}
{% step %}
### Step 5: Introduce mix and seasonality
To understand mix effects, create drivers that allocate total demand between SKUs or SKU groups, for example:
* Mix Percentage - Key SKUs vs Tail SKUs.
* Mix by Channel for each product family.
* Seasonal multipliers per month or quarter.
Implement total demand drivers such as:
* Total Units - Product Family A.
* Mix Split - Key 1, Key 2, Tail.
Then compute units per SKU using:
* Units - SKU Key 1 = Total Units - Family A ร Mix Percentage - SKU Key 1.
Apply seasonality via multiplicative factors that adjust units per period. This lets you see how product mix and seasonality interact in different scenarios.
{% endstep %}
{% step %}
### Step 6: Calibrate to historical data
To ensure the model is credible:
* Import historical revenue and COGS per SKU family or SKU where data is available.
* Use these to calibrate unit prices, discounts, unit costs and mix drivers.
* Reconcile historical periods so that model outputs align with reported P\&L.
This gives you a defensible starting point for forward looking SKU and margin forecasts.
{% endstep %}
{% step %}
### Step 7: Use scenarios for pricing, cost and mix strategies
Clone the base model into scenario models to test:
* Price increases by SKU family or region.
* Changes in discount policies.
* Cost inflation or changes in supplier terms.
* Shifts in product mix toward higher or lower margin SKUs.
* New product introductions or product retirements.
In each scenario, adjust:
* Unit price and discount drivers.
* Unit cost drivers.
* Mix and volume drivers.
Then compare scenarios using:
* Gross margin by product, customer or channel.
* Total gross profit and EBITDA.
* Cash and working capital when combined with inventory models.
* Valuation metrics where relevant.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
### Check your work
* SKU and product groupings balance precision with maintainability.
* Price, discount and cost assumptions reconcile with historical data and commercial plans.
* Gross margin profiles match internal expectations by product and customer.
* Scenario results are intuitive to both commercial and finance teams.
{% endhint %}
## Troubleshooting
Too much detail makes the model hard to use
Aggregate long tail SKUs into a small number of representative buckets and focus detail only on key profit drivers.
Margins do not match historical results
Check that unit costs include all relevant components, including freight, duties and rebates, and that discounts are applied correctly.
Difficult to explain margin changes
Use waterfall charts to separate the effect of price, cost, volume and mix changes on gross margin.
## Related guides
* [Build a Cashflow Early Warning System](/how-tos/dashboards-and-reporting/build-a-cashflow-early-warning-system)
* [Build a Central Assumption Library](/how-tos/data-workflows-and-automation/build-a-central-assumption-library)
* [Importing from Google Finance and Yahoo APIs](/help/importing-from-google-finance-and-yahoo-apis)
* [Timing Modal Overview](/syntax/timing-syntax/timing-modal-overview)
# Warehouse Capacity & Logistics Model
This use case explains how to model warehouse capacity, throughput and logistics costs for wholesale, distribution and B2B trade businesses in Model Reef.
You will:
* Represent warehouses, regions and logistics networks in the branch structure.
* Link SKU volumes to inbound, storage and outbound handling loads.
* Model capacity constraints, utilisation and cost structures.
* Connect warehouse and logistics assumptions to P\&L and Cashflow.
Model Reef is not a warehouse management or routing system. It uses operational assumptions to shape financial forecasts and scenarios.
## When to use this pattern
Use this pattern when:
* Warehousing and logistics are material cost or constraint drivers.
* You operate multiple warehouses or fulfilment centres.
* You need to understand capacity, utilisation and cost impacts of growth.
* You want to compare centralised vs regional or third party logistics strategies.
It complements:
* SKU and Margin Forecasting
* Inventory Replenishment Cycles
* Customer Level Revenue Modelling
## Architecture overview
{% stepper %}
{% step %}
### Structure
* Branches per warehouse, region or fulfilment node.
* Optional branches for third party logistics or cross dock facilities.
{% endstep %}
{% step %}
### Volume and load drivers
* Inbound units or pallets.
* Storage units or pallet positions.
* Outbound orders, lines, units or weight.
{% endstep %}
{% step %}
### Capacity and utilisation
* Storage capacity per warehouse.
* Throughput capacity per period.
* Utilisation metrics and thresholds.
{% endstep %}
{% step %}
### Cost drivers
* Fixed warehouse costs.
* Variable handling, storage and transport costs.
* Third party logistics fees.
{% endstep %}
{% step %}
### Set up warehouse and logistics branches
In the branch tree, create branches that reflect your logistics footprint, for example:
* Region - UK
* Warehouse - UK North
* Warehouse - UK South
* Region - EU
* Warehouse - EU Central
* Third Party Logistics
Each warehouse branch will hold capacity, volume, cost and staff variables. Transport costs can either live in the warehouse branches or in separate logistics branches if you want to analyse them separately.
{% endstep %}
{% step %}
### Link SKU volumes to warehouse loads
From SKU and margin models, obtain:
* Units sold per SKU per region or channel.
* Where possible, allocation of units to warehouses based on service territories or routing logic.
Create drivers such as:
* Units Inbound - Warehouse A.
* Units Outbound - Warehouse A.
* Orders or Order Lines - Warehouse A.
* Pallet Equivalents per Unit or per SKU Family.
Derive load metrics, for example:
* Pallets Inbound = Units Inbound ร Pallet Factor.
* Pallets Stored = Average Inventory ร Pallet Factor.
* Picks or Lines Per Period = Orders or Lines data.
These metrics will drive capacity utilisation and variable costs.
{% endstep %}
{% step %}
### Define capacity and utilisation
For each warehouse, create drivers for:
* Storage Capacity (for example pallet positions).
* Throughput Capacity (for example pallets or picks per period).
* Labour Capacity (for example shifts, FTEs or hours per period).
Calculate utilisation metrics such as:
* Storage Utilisation = Pallets Stored divided by Storage Capacity.
* Throughput Utilisation = Pallets Inbound plus Pallets Outbound divided by Throughput Capacity.
* Labour Utilisation = Required Hours divided by Available Hours.
You can highlight when utilisation exceeds threshold levels (for example above 85 percent) to indicate congestion or the need for additional capacity or process changes.
{% endstep %}
{% step %}
### Model warehouse and logistics costs
Create cost variables in each warehouse branch, for example:
* Staff - Warehouse Operations - Warehouse A.
* Opex - Rent and Rates - Warehouse A.
* Opex - Utilities, Maintenance and MHE.
* Opex - Inbound Freight.
* Opex - Outbound Freight.
* Opex - Third Party Logistics Fees.
Link these to drivers such as:
* Fixed monthly or annual rent and overhead allocations.
* Cost per pallet handled.
* Cost per order, per line or per kilogram.
* Contracted third party logistics rates per unit or per activity.
This allows you to see total logistics cost per unit, per order or per revenue pound in P\&L and cash.
{% endstep %}
{% step %}
### Use scenarios for footprint and strategy
Clone the model into scenario models to explore:
* Opening, closing or relocating warehouses.
* Moving from own operated to third party logistics, or vice versa.
* Changing service levels or delivery promises.
* Growth that saturates existing capacity.
In each scenario, adjust:
* Warehouse capacity and cost structures.
* Allocation of demand between warehouses.
* Transport and third party logistics rates.
* Staffing levels and productivity assumptions.
Compare scenarios using:
* Total logistics cost and cost per unit.
* Capacity and utilisation across the network.
* Service trade offs and working capital implications when combined with inventory models.
{% endstep %}
{% step %}
### Connect to inventory and customer models
When combined with Inventory Replenishment Cycles and Customer Level Revenue Modelling:
* Warehouse branches hold the physical and cost picture.
* Inventory models determine stock levels and movements.
* Customer models determine demand patterns and service levels.
Dashboards can show:
* Logistics cost per customer, product or region.
* Capacity bottlenecks under different demand scenarios.
* Effect of SKU rationalisation, pricing or service changes on logistics needs.
{% endstep %}
{% endstepper %}
## Check your work
* Warehouse capacity and cost assumptions match actual contracts and operating data.
* Load and utilisation metrics reconcile with historical operational reports.
* Scenario outputs are interpretable for operations, finance and commercial teams.
* Model granularity is appropriate to the decisions being made.
## Troubleshooting
Utilisation seems unrealistic
Check pallet and storage factors, and ensure you are not double counting inbound and outbound volumes when comparing to throughput capacity.
Logistics costs do not reconcile to historical accounts
Revisit mapping of costs into branches and ensure rate and volume assumptions match recent periods.
Model is too granular for quick decision making
Aggregate similar warehouses or logistics activities into representative nodes and keep detail only where it significantly changes decisions.
## Related guides
* [Build a Consolidated Forecast Model](/how-tos/core-modelling/build-a-consolidated-forecast-model)
* [Build a Cost of Goods Model](/how-tos/operations-and-unit-economics/build-a-cost-of-goods-model)
* [Investing Cashflow](/help/financial-outputs-and-valuation/investing-cashflow)
* [Timing Preview](/syntax/timing-syntax/timing-preview)
# Inventory Replenishment Cycles
This use case explains how to model inventory levels and replenishment cycles for wholesale, distribution and B2B trade businesses in Model Reef.
You will:
* Approximate inventory levels using purchase and sales timing.
* Represent lead times, reorder rules and safety stock in driver form.
* Estimate stock related working capital needs.
* Link inventory assumptions to P\&L, Cashflow and capacity models.
{% hint style="info" %}
Model Reef is not an operational inventory optimisation engine. It provides a financial view of inventory and working capital based on higher level policies and drivers.
{% endhint %}
***
## When to use this pattern
Use this pattern when:
* Inventory is a material part of your Balance Sheet and cash usage.
* You manage stock across one or more warehouses.
* You need to understand how replenishment policies impact cash and capacity.
* You want to connect SKU level demand forecasts to inventory and funding.
It fits alongside:
* SKU and Margin Forecasting
* Warehouse Capacity and Logistics Model
* Working Capital and Cashflow planning
***
## Architecture overview
Inventory replenishment modelling uses:
* Demand and sales inputs
* Units sold per SKU or SKU group.
* Seasonality and campaign effects.
* Replenishment and lead time drivers
* Reorder frequency and order quantities.
* Supplier lead times.
* Safety stock coverage.
* Inventory representation
* Approximate stock on hand in units or value.
* Inventory turnover metrics.
* Stock ageing approximations where needed.
* Financial integration
* COGS and purchases timing.
* Working capital and funding requirements.
* Warehouse capacity demands.
***
{% stepper %}
{% step %}
### Start from SKU demand forecasts
From the SKU and Margin Forecasting pattern, obtain:
* Unit sales per period for each SKU or SKU group.
* Seasonality and campaign patterns.
* Any channel or warehouse allocations.
These series represent demand that inventory must serve.
{% endstep %}
{% step %}
### Define replenishment rules as drivers
In the Data Library, create drivers that approximate your inventory policy, for example:
* Target Days of Cover per SKU or SKU group.
* Supplier Lead Time in days or periods.
* Reorder Frequency (for example weekly, fortnightly, monthly).
* Order Quantity rules (for example based on multiples of cartons or pallets).
Because Model Reef is period based rather than transaction based, express these as average behaviours at the model's granularity. For example:
* Monthly model: Target Cover in months, reorder frequency as multiples of months.
* Weekly model: Target Cover in weeks, reorder frequency in weeks.
{% endstep %}
{% step %}
### Approximate inventory levels
Using demand and policy drivers, approximate average inventory levels. For example:
* Average Inventory in Units = Demand per Period ร (Lead Time plus Safety Cover in Periods) divided by 2 for simple policies, or
* Average Inventory in Units = Demand per Period ร Target Cover in Periods.
Then compute inventory value using unit cost:
* Inventory Value = Average Inventory in Units ร Unit Cost per Unit.
Represent this with Asset variables, for example:
* Inventory - Product Family A.
* Inventory - Product Family B.
* Inventory - Long Tail SKUs.
You can group SKUs into a small number of inventory pools to keep the model manageable.
{% endstep %}
{% step %}
### Link purchases timing to COGS and inventory
For each inventory pool, ensure that:
* COGS reflects cost of units sold in each period.
* Purchases timing reflects when you pay suppliers.
* Inventory balances capture the difference between purchases and COGS.
In Model Reef, you can approximate this by:
* Setting COGS variables to follow sales timing.
* Setting purchase related Opex or COGS variables with delays that reflect lead times and payment terms.
* Using Inventory Asset variables to approximate stock on hand, with changes over time informed by the difference between purchases and sales based series.
The key is that P\&L, Balance Sheet and Cashflow views together produce a coherent picture of inventory related working capital.
{% endstep %}
{% step %}
### Analyse inventory turnover and working capital
Create metrics and dashboards to show:
* Inventory Turnover = COGS divided by Average Inventory.
* Days in Inventory = 365 or 52 or 12 divided by Turnover, depending on granularity.
* Inventory value over time by product family and location.
* Working capital tied up in stock compared to receivables and payables.
These views help you see which parts of the product range or network consume the most capital and where policy changes could have the biggest impact.
{% endstep %}
{% step %}
### Use scenarios for policy and supplier risk
Clone the model into scenario models to explore changes such as:
* Higher or lower target days of cover.
* Longer or shorter supplier lead times.
* Shifts from sea freight to air or vice versa.
* Additional safety stock in response to supply chain risk.
* SKU rationalisation or range expansion.
In each scenario, adjust:
* Policy drivers for cover, lead time and ordering.
* Unit cost and freight assumptions.
* Demand drivers from the SKU model.
Compare scenarios using:
* Inventory balances and working capital required.
* Logistics and warehouse capacity utilisation.
* Stock outs or overstock risk approximated via changes in service levels or buffer coverage where you choose to represent these.
{% endstep %}
{% step %}
### Integrate with financing and cash planning
Once inventory behaviours are included alongside receivables and payables in the Balance Sheet:
* Cashflow Statement and Cash Waterfall will show stock related cash impacts.
* You can test the effect of changes in inventory policy on overdraft usage, trade finance and covenants.
* You can connect inventory decisions to capex for additional storage or automation.
This ties together operational and financial planning in one model.
{% endstep %}
{% endstepper %}
***
Check your work
* Inventory levels and turnover metrics are realistic compared to historical data.
* Policy drivers are simple enough to explain yet capture the main behaviour.
* Working capital projections align with management experience and bank reporting.
* Scenario comparisons help frame decisions about policy changes and risk.
***
Troubleshooting
* Inventory appears negative or volatile\
Check that demand, purchase and inventory value methods are consistent and that you are not double counting inventory movement.
* Working capital changes are hard to interpret\
Use separate dashboards and reports that break out receivables, inventory and payables so you can see each component clearly.
* Too many small SKUs to manage\
Group SKUs into a handful of inventory pools based on similar behaviour rather than modelling each item separately.
***
## Related guides
* [Build an Inventory Timing Model](/how-tos/operations-and-unit-economics/build-an-inventory-timing-model)
* [Build a DCF Model (FCFF)](/how-tos/valuation/build-a-dcf-model-fcff)
* [Liability Variables: what is, rules, what it affects](/help/drivers-variables-and-timing/liability-variables)
* [Allowed Operators](/syntax/formula-syntax/allowed-operators)
# Customer-Level Revenue Modelling
This use case explains how to model customer level revenue, pricing, retention and growth for wholesale, distribution and B2B trade businesses in Model Reef.
You will:
* Segment customers by size, segment, channel or region.
* Build drivers for active customers, order frequency and basket size.
* Connect customer behaviour to SKU revenue and margin forecasts.
* Use scenarios to test pricing, retention and acquisition strategies.
Model Reef is not a CRM. It uses aggregated customer behavioural metrics, not individual account records, to drive financial forecasts.
{% hint style="info" %}
Model Reef is not a CRM โ it uses aggregated customer behavioural metrics, not individual account records, to drive financial forecasts.
{% endhint %}
***
## When to use this pattern
Use this pattern when:
* Customer relationships and repeat purchases are core to the business.
* You want to understand revenue at customer segment level, not just product level.
* You need to link pricing and discount strategies to customer economics.
* You want to test acquisition, retention and reactivation plans.
It pairs naturally with:
* SKU and Margin Forecasting
* Inventory Replenishment Cycles
* Warehouse Capacity & Logistics Model
* Build a Unit Economics Model
***
## Architecture overview
Customer level revenue modelling uses:
* Customer segmentation
* Segments based on size, sector, channel or region.
* Key accounts handled separately where needed.
* Behaviour drivers
* Active customer counts per segment.
* Acquisition, churn and reactivation rates.
* Order frequency and average order value.
* Revenue construction
* Revenue per segment and key account.
* Links between customer segments and SKU demand.
* Scenario and strategy analysis
* Alternative pricing, discount and contract strategies.
* Different acquisition and retention programmes.
***
{% stepper %}
{% step %}
### Define customer segments
List your main customer segments, for example:
* Enterprise customers
* Mid market customers
* Small business customers
* Resellers or distributors
* Key named accounts in specific industries
Decide whether to:
* Model key accounts individually and the rest in pooled segments, or
* Model only segments where no single customer is large enough to warrant separate treatment.
Reflect these segments using branches, categories or tags. For example:
* Branches for regions and channels
* Categories for customer segments within those branches
{% endstep %}
{% step %}
### Build customer count and movement drivers
In the Data Library, create time series for:
* Opening Active Customers per Segment
* New Customers Acquired per Period
* Churned Customers per Period
* Reactivated Customers per Period where relevant
You can also express these as rates:
* Acquisition Rate relative to a prospect pool
* Churn Rate relative to the active base
* Net Growth Rate
Compute Active Customers per Segment each period as:
* Active Customers = Previous Active + Acquisitions โ Churn + Reactivations
This provides the base population for order and revenue modelling.
{% endstep %}
{% step %}
### Create order frequency and basket size drivers
For each segment, define drivers such as:
* Average Orders per Customer per Period
* Average Order Value
* Average Lines per Order (if linking to warehouse load models)
Compute segment level revenue using:
* Orders = Active Customers ร Orders per Customer
* Revenue = Orders ร Average Order Value
To link to SKU level volumes more explicitly, also define:
* Average Units per Order per SKU family
* Then derive SKU level volumes using customer segment volumes and mix drivers
Keep the level of detail manageable by using product families rather than individual SKUs when working at segment level.
{% endstep %}
{% step %}
### Represent pricing and discount structures
Create drivers for pricing behaviour per segment, for example:
* List Price per Product Family
* Average Discount Percentage per Segment
* Contracted vs spot volume shares
Implement revenue as:
* Net Price per Unit = List Price ร (1 โ Discount Percentage)
* Revenue = Units Sold ร Net Price per Unit
Segments with higher bargaining power may have higher discounts and lower net prices. Represent promotional periods by adjusting discount drivers in specific periods.
{% endstep %}
{% step %}
### Link customer revenue to SKU and logistics models
To connect customer behaviour to other parts of the model:
* Map segment level demand into SKU or SKU family demand using mix drivers
* Use the resulting SKU volumes in SKU and Margin Forecasting
* Feed units and order counts into warehouse and logistics models
This ensures that customer strategies show up as:
* Changes in SKU mix and margins
* Changes in warehouse and logistics load
* Changes in inventory requirements and working capital
{% endstep %}
{% step %}
### Use scenarios for growth, pricing and retention strategies
Clone the base model into scenario models to test strategies such as:
* Increased investment in customer acquisition with different return expectations
* Changes in retention through service level, product or pricing changes
* Shifts in customer mix toward higher or lower margin segments
* Targeted price increases or discount reductions in specific segments
* Loss of a major key account
In each scenario, adjust:
* Customer movement drivers (acquisition, churn, reactivation)
* Order frequency and average order value
* Pricing and discount drivers
* Segment mix and key account assumptions
Compare scenarios using:
* Revenue by segment, product family and region
* Gross margin by segment
* Customer level unit economics where constructed
* Overall cashflow and valuation impacts
{% endstep %}
{% step %}
### Calibrate and validate against historical data
To ensure credibility:
* Import historical revenue by customer segment and key account where available
* Derive historical orders per customer and average order value where data allows
* Calibrate acquisition and churn rates to match observed changes in active customers over time
Use this calibration to set starting points for forward assumptions and scenario ranges.
{% endstep %}
{% endstepper %}
***
## Check your work
* Segment definitions reflect how the business manages and reports customers.
* Behaviour drivers are grounded in historical data or reasonable assumptions.
* Pricing and discount patterns align with commercial practice.
* Scenario insights are actionable for sales, marketing and account teams.
***
## Troubleshooting
Revenue does not reconcile with product or region views
Check mapping between segment revenues and SKU or region allocations, and ensure you are not double counting segments.
Model is too complex with many small segments
Group small segments into broader categories and maintain granularity only for strategically important segments or key accounts.
Difficult to trace impact of pricing changes
Use reports and dashboards that isolate pricing and discount drivers and show their specific contribution to revenue and margin changes.
***
## Related guides
* [Build a Recurring Revenue Forecast](/how-tos/core-modelling/build-a-recurring-revenue-forecast)
* [Build a Debt Schedule & Covenants Model](/how-tos/investment-and-transactions/build-a-debt-schedule-and-covenants-model)
* [Limitations of Public API Data](/help/importing-from-google-finance-and-yahoo-apis/limitations-of-public-api-data)
* [Auto-Validation Rules](/syntax/how-input-fields-work/auto-validation-rules)
# ๐จ Media, Agencies & Creative Studios
# Retainer & Project Pipeline Forecast
This use case explains how to forecast agency or studio revenue from retainers and project work in Model Reef.
You will:
* Represent retainers, projects and clients in the branch and category structure.
* Build drivers for retainers, active projects and win rates by stage.
* Model timing of revenue recognition and cash receipts.
* Connect the pipeline to staffing, delivery and profitability views.
Model Reef is not a CRM or job management tool. It consumes high level pipeline and contract assumptions and converts them into financial statements, cashflows and valuations.
## When to use this pattern
Use this pattern when:
* Your agency or studio has a mix of retainers and project work.
* The sales pipeline is material to future revenue.
* You need to explain revenue shape and timing to owners, finance or investors.
* You want to test utilisation, hiring and profitability under different win and pricing scenarios.
You can combine this with:
* Staffing and Creative Resource Planning
* Production Budgeting and Delivery Models
* Multi Client Profitability
* Build a Driver Based Forecast
***
## Architecture overview
{% stepper %}
{% step %}
### Structure
* Branches for studios, offices or business units.
* Optional branches for large clients or practice areas.
{% endstep %}
{% step %}
### Retainer drivers
* Monthly or quarterly retainer fee per client.
* Start and end dates, with renewal assumptions.
* Fee indexation or step changes.
{% endstep %}
{% step %}
### Project pipeline drivers
* Pipeline stages and weighted values.
* Win rates and average project values.
* Expected start dates and durations.
{% endstep %}
{% step %}
### Revenue timing
* Recognition patterns for retainers versus projects.
* Cash delays and payment terms.
{% endstep %}
{% endstepper %}
***
{% stepper %}
{% step %}
### Set up branches for studios and key clients
In the branch tree, create a structure that matches how you manage the business, for example:
* Agency Group
* Studio - Brand and Creative
* Studio - Digital and Product
* Studio - Production
* Key Client - Global FMCG A
* Key Client - Tech B
* Central Overheads
Optionally, give very large clients their own branches so you can see their P\&L and capacity impact directly. Smaller clients can be grouped and tracked via categories or Data Library entries.
{% endstep %}
{% step %}
### Create retainer revenue drivers
In the Data Library, create a table of retainers, including:
* Client name or group.
* Branch or studio that services them.
* Retainer start and end dates.
* Monthly or quarterly fee.
* Fee indexation rate or scheduled increases.
* Probability of renewal on expiry.
For each retainer, create a Revenue variable such as:
* Revenue - Retainer - Client X - Studio Brand.
Use timing fields to set start and end dates. Use a simple formula or preset to apply:
* Flat or escalated fee over the retainer term.
* Gap periods for planned pauses if required.
Cash timing comes from payment terms and delay settings, for example 30 days or 60 days from invoice.
{% endstep %}
{% step %}
### Create project pipeline stages and drivers
Define pipeline stages that reflect your sales process, for example:
* Stage 1: Qualified.
* Stage 2: Proposal.
* Stage 3: Verbal.
* Stage 4: Contracted.
In the Data Library, create series for each stage such as:
* Pipeline Value - Stage 2 - Studio Brand.
* Pipeline Value - Stage 3 - Studio Digital.
You can maintain these as:
* Total expected contract value per stage per period, or
* Number of deals and average deal size per stage.
For each stage, assign a win rate driver, for example 20 percent for Stage 2, 60 percent for Stage 3, 90 percent for Stage 4. Then compute weighted pipeline:
* Weighted Pipeline = Stage Value multiplied by Win Rate.
This provides the expected value of work likely to be won in each period.
{% endstep %}
{% step %}
### Translate pipeline into forecast projects
To convert pipeline into revenue, define drivers for:
* Average project duration in months or weeks.
* Revenue recognition pattern, for example even over duration, front loaded or milestone based.
* Expected start lag from pipeline recognition to project commencement.
You can approximate this at aggregate level by:
* Forecast Projects Won per Period = Weighted Pipeline Value divided by Average Project Value.
* Revenue from Projects = Projects Won multiplied by Revenue per Project, spread over duration using schedules or presets.
If you want finer control, you can maintain a Data Library of named large projects with expected start dates, values and durations, then create Revenue variables per project.
{% endstep %}
{% step %}
### Combine retainers and projects into total revenue
Total revenue per studio or client branch is the sum of:
* Retainer Revenue variables.
* Project Revenue variables derived from the pipeline.
* Any production or media pass through where you choose to model this separately.
Use categories and sub categories to distinguish:
* Retainer revenue.
* Project revenue.
* Pass through or third party costs if relevant.
Dashboards can then show revenue by type, client, studio and scenario.
{% endstep %}
{% step %}
### Use scenarios for pricing, win rate and renewal risk
Clone the base model into scenario models to test:
* Higher or lower win rates by stage.
* Different pricing or fee structures for projects and retainers.
* Retainer renewal and churn rates.
* Delays in project start dates or extensions to delivery schedules.
In each scenario, adjust:
* Win rate and pipeline value drivers.
* Retainer fee and renewal assumptions.
* Project duration and revenue recognition patterns.
* Payment term delays and working capital settings.
Compare scenarios using:
* Revenue growth and mix between retainer and project work.
* Studio level utilisation when combined with staffing models.
* Cash timing and funding needs.
* Valuation outputs where relevant.
{% endstep %}
{% endstepper %}
***
## Check your work
* Retainer and pipeline values reconcile with your CRM or sales reports where possible.
* Revenue forecasts align with realistic delivery and staffing capacity.
* Scenario outcomes are defensible when discussed with commercial and delivery teams.
* The level of project detail is appropriate to your planning horizon and materiality.
***
## Troubleshooting
Revenue looks too smooth or too lumpy
Adjust project duration and revenue recognition patterns so they better reflect how work is delivered and billed.
Utilisation models break when pipeline moves
Check that you have not double counted project volumes and that staffing drivers are linked to the correct retained and project workloads.
Too many small projects to model individually
Model small or short projects as aggregated project pools per studio or client group, and only model large strategic projects individually.
***
## Related guides
* [Build a Driver Based Forecast](/how-tos/core-modelling/build-a-driver-based-forecast)
* [Build a Forecast Accuracy Tracker](/how-tos/scenarios-and-planning/build-a-forecast-accuracy-tracker)
* [Mapping API Data Into Variables](/help/importing-from-google-finance-and-yahoo-apis/mapping-api-data-into-variables)
* [Branch Assignment](/syntax/variables-syntax/branch-assignment)
# Staffing & Creative Resource Planning
This use case explains how to plan staffing and utilisation for media, agencies and creative studios in Model Reef.
You will:
* Set up roles, teams and locations in branches and staff variables.
* Build drivers for headcount, day rates, utilisation and overheads.
* Link staffing to retainer and project workloads.
* See the impact on P\&L, capacity and profitability by studio and client.
{% hint style="info" %}
Model Reef is not a scheduling or timesheet system. It models headcount, utilisation and cost at planning level, not individual bookings or daily allocations.
{% endhint %}
## When to use this pattern
Use this pattern when:
* People cost is your main cost line and capacity constraint.
* You need to align hiring plans with pipeline and retainer commitments.
* You want to understand margin by studio, team or client.
* You are testing alternative staffing models or location strategies.
It connects directly with:
* Retainer and Project Pipeline Forecast
* Production Budgeting and Delivery Models
* Multi Client Profitability
## Architecture overview
{% stepper %}
{% step %}
### Structure
* Branches for studios, locations or practice areas.
* Staff variables for roles and teams.
{% endstep %}
{% step %}
### Headcount and utilisation drivers
* Number of FTEs per role per period.
* Utilisation targets and achieved utilisation.
* Billable versus non billable mix.
{% endstep %}
{% step %}
### Cost and rate drivers
* Salary, benefits and overhead loadings.
* Internal cost per day.
* External billable day rates where relevant.
{% endstep %}
{% step %}
### Capacity and demand
* Capacity in billable days or hours.
* Demand from retainers and project pipeline.
{% endstep %}
{% endstepper %}
***
## Step 1: Define roles and team structure
Decide on the granularity of roles, for example:
* Partner or Executive Creative Director.
* Creative Director and Design Lead.
* Designers and Copywriters.
* Developers and Producers or Project Managers.
* Account Management and Strategy.
* Production or Studio Operations.
In each studio or location branch, create Staff variables such as:
* Staff - Designers - Studio Brand.
* Staff - Developers - Studio Digital.
* Staff - Producers - Studio Production.
* Staff - Account Managers - All Studios.
These variables will hold headcount, cost and timing assumptions for each role group.
***
## Step 2: Build headcount and cost drivers
For each Staff variable, use the timing and amount settings to specify:
* Headcount per period.
* Start and end dates for roles or planned hires.
* Base salary per FTE.
* On costs such as benefits, payroll taxes and other employment charges.
* Pay frequency and cash delay settings.
You can either:
* Input headcount directly per period, or
* Use drivers in the Data Library such as Headcount Required per Role and link Staff variables to those drivers.
Ensure that the model reflects planned hires and departures, including freelancers or contractors where they are a regular part of delivery.
***
## Step 3: Add utilisation and capacity metrics
In the Data Library, create drivers for each role group such as:
* Working Days per FTE per period.
* Holiday, training and non working time assumptions.
* Target Billable Utilisation Percentage.
* Realised Utilisation Percentage where you model performance.
Calculate capacity metrics such as:
* Available Billable Days = Headcount ร Working Days ร Utilisation.
* Implied Billable Value = Available Billable Days ร Average Day Rate where you choose to compute this.
You can implement these as custom driver variables and then use charts and reports to view capacity and utilisation by role and studio.
***
## Step 4: Connect staffing to workload from retainers and projects
From the Retainer and Project Pipeline Forecast, derive approximate workload measures such as:
* Required Design Days.
* Required Development Days.
* Required Producer or Project Management Days.
These might be allocated per studio and per role based on:
* Retainer fee breakdowns.
* Standard effort mixes across disciplines.
* Historical time tracking data where available.
Use these workload drivers to compare:
* Required Days versus Available Billable Days by role.
* Over or under utilisation by team and period.
* Need for additional hires, contractors or reduced workload.
You can represent implied hires by adjusting headcount drivers in scenarios until capacity and demand are aligned at an acceptable utilisation level.
***
## Step 5: Reflect non billable roles and overheads
Create Staff variables for roles that are not directly billable, such as:
* Management and leadership.
* Operations and finance.
* HR and recruitment.
* Business development and marketing.
These still generate Staff cost in P\&L and affect EBITDA, but do not produce billable capacity. Include them in branch structures where they make sense, for example under Central Overheads or specific studios.
You can then calculate metrics like:
* Total staff cost per billable day.
* Ratio of non billable to billable headcount.
***
## Step 6: Use scenarios for hiring, rate and utilisation strategies
Clone the base model into scenario models to explore:
* Hiring earlier or later relative to pipeline growth.
* Different utilisation targets or management expectations.
* Changes in salary levels, location mix or contractor usage.
* Day rate changes by role or studio.
* Shifts between generalist and specialist team structures.
In each scenario, adjust:
* Headcount and timing.
* Salary and on cost levels.
* Utilisation and day rate drivers.
* Allocation of workload across studios and locations.
Compare scenarios using:
* EBITDA and margin by studio and for the group.
* Capacity and utilisation metrics.
* Cashflow and headcount stability over time.
* Client satisfaction or service risk approximated via utilisation and capacity indicators where you choose to represent these qualitatively.
***
## Check your work
* Headcount and staff costs reconcile reasonably with recent actuals.
* Utilisation targets and achieved figures align with operational reality.
* The relationship between pipeline and hiring plans is clear and defendable.
* Scenario outcomes support concrete hiring or restructuring decisions.
***
## Troubleshooting
Model is too granular with many micro roles
Group similar roles into role families and keep detail only where it meaningfully changes cost or utilisation dynamics.
Utilisation results look unrealistic
Recheck working day, holiday and utilisation drivers and confirm that workload measures are on the same basis as capacity.
Cannot reconcile staff cost to actual accounts
Ensure that all salary, contractor and freelance costs are included and mapped to Staff variables, and that on costs are appropriately represented.
***
## Related guides
* [Build a Staffing Cost Model](/how-tos/operations-and-unit-economics/build-a-staffing-cost-model)
* [Build an Annual Planning Pack](/how-tos/scenarios-and-planning/build-an-annual-planning-pack)
* [Mapping Branches](/help/importing-and-data-inputs/mapping-branches)
* [Branch Selector](/syntax/understanding-the-interface/branch-selector)
# Production Budgeting & Delivery Models
This use case explains how to model production budgets and delivery models for media, agencies and creative studios in Model Reef.
You will:
* Set up production budgets for projects, campaigns or shows.
* Distinguish between fee, pass through and third party cost elements.
* Represent different delivery models such as in house, outsourced or hybrid.
* Connect production assumptions to P\&L, Cashflow and client profitability.
Model Reef is not a shoot scheduling or production management tool. It provides a financial view of production budgets and delivery, not detailed call sheets or task plans.
## When to use this pattern
Use this pattern when:
* You produce TV, video, digital content or integrated campaigns.
* Projects include large pass through and third party cost elements.
* Margin depends on how you deliver and source production work.
* You need to understand project and client level profitability.
It often sits alongside:
* Retainer and Project Pipeline Forecast
* Staffing and Creative Resource Planning
* Multi Client Profitability
## Architecture overview
Production budgeting and delivery modelling uses:
1. Structure
* Branches for studios or production units.
* Categories for fee revenue, production costs and pass through items.
2. Project and campaign budgets
* Revenue budgets from retainers or project fees.
* Production cost budgets per project or project type.
3. Delivery models
* In house production with internal staff and facilities.
* Outsourced production with third party vendors.
* Hybrid models where parts are internal and parts external.
4. Financial outputs
* Project and client gross margin.
* Production cashflows and working capital needs.
* Impact on studio level P\&L.
{% stepper %}
{% step %}
### Step 1: Define fee, production cost and pass through structures
In your categories and variables, distinguish between:
* Fee Revenue (agency fee, creative fee or production fee).
* Production Costs (internal studio time, internal facilities).
* Pass Through Costs (third party production vendors, locations, talent and media bought on behalf of the client).
You can either:
* Use separate revenue and cost variables per project or project type, or
* Use aggregated variables per studio and client with project budgets feeding into them via drivers.
Ensure that pass through items are clearly identified so that gross income and gross margin can be calculated if required.
{% endstep %}
{% step %}
### Step 2: Create production budget templates
In the Data Library, construct production budget templates for common project types, for example:
* TV spot budgets with line items for director, crew, equipment, locations and post production.
* Social or digital content bundles.
* Integrated campaign packages.
Each template can contain drivers for:
* Units (for example shoot days, edit days, deliverables).
* Rates per unit for internal and external resources.
* Standard mark ups on third party costs where applicable.
Use these templates to drive Revenue and Opex variables, either at individual project level for large jobs or aggregated for smaller jobs.
{% endstep %}
{% step %}
### Step 3: Represent delivery models and sourcing mix
For each project type or studio, define drivers for sourcing mix, such as:
* Percentage delivered in house.
* Percentage outsourced to preferred vendors.
* Percentage using freelance staff.
Adjust production cost formulas accordingly, for example:
* Internal Production Cost = Internal Units ร Internal Rate.
* External Production Cost = External Units ร External Vendor Rate.
* Freelance Cost = Freelance Units ร Freelance Rate.
Use scenarios to shift sourcing mix between internal, external and freelance to see the impact on margin and capacity.
{% endstep %}
{% step %}
### Step 4: Link production budgets to project and client revenue
Connect production budgets to Revenue variables from the Retainer and Project Pipeline Forecast by:
* Mapping project fees and pass through revenue to specific clients and studios.
* Allocating production costs to the same branches and categories.
This enables you to compute:
* Gross income (fee revenue plus mark up on third party costs where used).
* Gross margin after internal and external production costs.
* Overhead allocation and EBITDA per client and studio when combined with staffing and overhead models.
{% endstep %}
{% step %}
### Step 5: Model timing and cashflow for production
Set timing and delay rules on production cost variables to reflect:
* Deposit, progress and final payment schedules to vendors.
* When you bill clients for pass through costs.
* Payment terms on client invoices.
This will drive:
* Short term cash requirements for production.
* Working capital exposure on large projects.
* The shape of Cashflow and Cash Waterfall across the portfolio.
You can then test scenarios where clients pay more slowly or where your vendor terms are less favourable.
{% endstep %}
{% step %}
### Step 6: Use scenarios for pricing, scope and delivery strategy
Clone the base model into scenario models to explore:
* Different pricing and mark up strategies.
* Changes to in house capacity versus outsourcing.
* Alternative scope levels for key clients.
* Different levels of risk allowance and contingency in production budgets.
In each scenario, adjust:
* Fee and mark up rates.
* Sourcing mix drivers.
* Production budget drivers per project type.
* Timing and payment assumptions.
Compare scenarios using:
* Project and client level margin.
* Studio capacity and staff utilisation.
* Cash exposure on production work in progress.
* Valuation metrics where relevant.
{% endstep %}
{% endstepper %}
{% hint style="success" %}
### Check your work
* Production budgets reflect realistic costs and scope based on past jobs.
* Fee and mark up structures match client contracts and commercial practices.
* Timing assumptions align with how you bill and pay today.
* Scenario outcomes support practical decisions about how to deliver work.
{% endhint %}
## Troubleshooting
Margins do not match historical project reviews
Recalibrate budget templates and mark up assumptions using a sample of recent projects and client reconciliations.
Cash exposure seems too high or low
Verify delay and payment term settings for both client and vendor related variables and ensure you have not double counted prepayments or deposits.
Too many project line items to maintain
Use templates and a small set of representative project profiles rather than modelling every job individually, unless it is material.
## Related guides
* [Build a Financial Statements Reporting Suite](/how-tos/dashboards-and-reporting/build-a-financial-statements-reporting-suite)
* [Build a Forecast from Ticker Fundamentals](/how-tos/data-workflows-and-automation/build-a-forecast-from-ticker-fundamentals)
* [Mapping Categories](/help/importing-and-data-inputs/mapping-categories)
* [Category Picker](/syntax/understanding-the-interface/category-picker)
# Multi-Client Profitability
This use case explains how to analyse profitability across multiple clients, studios and work types for media, agencies and creative studios in Model Reef.
You will:
* Attribute revenue and costs to clients and studios using branches and categories.
* Combine retainers, projects, production and overhead structures into client P\&L views.
* Build dashboards to compare client and portfolio performance.
* Use scenarios to test pricing, scope and portfolio mix changes.
Model Reef is not a CRM or case management system. It provides a financial view of client profitability based on the revenue and cost structures you define.
## When to use this pattern
Use this pattern when:
* You serve many clients across multiple studios or locations.
* You want to understand which clients and portfolios drive profit or loss.
* You need to support decisions on pricing, investment, scope or disengagement.
* You want to link client strategies to staffing and production plans.
It builds on:
* Retainer and Project Pipeline Forecast
* Staffing and Creative Resource Planning
* Production Budgeting and Delivery Models
## Architecture overview
Multi client profitability modelling uses:
1. Branch and category structure
* Branches for studios, offices or large clients.
* Categories to separate revenue, direct costs and overheads.
2. Revenue and cost attribution
* Mapping of retainer and project revenue to clients.
* Mapping of production and staffing costs to clients or client groups.
* Allocation of shared overheads by driver.
3. Client P\&L views
* Direct contribution margin by client.
* Fully loaded margin including allocated overhead.
* Portfolio and studio level summaries.
4. Scenario and portfolio analysis
* Client mix and scope changes.
* Pricing and rate changes.
* Growth or contraction in specific segments.
{% stepper %}
{% step %}
### Decide how to represent clients in the model
There are three main patterns:
* Branch per key client
* For a small number of large clients.
* Enables full client level P\&L and dashboards.
* Categories or tags for client segments
* For large numbers of smaller clients.
* Groups clients into meaningful segments, for example sector or size.
* Hybrid
* Branches for strategic or very large clients.
* Segments for the remainder.
Choose a pattern that matches your management reporting, and implement branches and categories accordingly.
{% endstep %}
{% step %}
### Attribute revenue to clients and studios
From the Retainer and Project Pipeline Forecast:
* Map retainer revenue to client branches or client categories.
* Map project revenue to specific clients or client segments.
* Distinguish between fee revenue and pass through or media revenue if you want to analyse gross income separately.
Ensure that each Revenue variable clearly identifies:
* Client or segment.
* Studio or office responsible.
* Work type (retainer, project, production, media).
This supports flexible reporting by client, studio and work type.
{% endstep %}
{% step %}
### Attribute direct costs to clients and work types
From Staffing and Creative Resource Planning and Production Budgeting and Delivery Models:
* Map staff cost where possible to the clients or client sets they primarily serve.
* Map production costs to the clients whose projects they relate to.
* Keep shared or pooled costs in studio or central branches to be allocated later.
Create Opex and Staff variables such as:
* Staff - Account Team - Client X.
* Staff - Dedicated Studio Team - Client Y.
* Production Cost - Campaign Z - Client X.
* Pooled Production Cost - Studio Brand.
This enables clear separation of direct client costs from shared overhead.
{% endstep %}
{% step %}
### Allocate shared overheads
For overheads that are not directly attributable to a single client, such as:
* Studio management and leadership.
* Shared creative or production pools.
* Office and facility costs.
* Central functions such as finance, HR or marketing.
Define allocation drivers in the Data Library, for example:
* Share of Revenue per client.
* Share of Direct Costs per client.
* Share of Staff Headcount or time per client.
* Manually set allocation percentages for key clients and segments.
Then create allocation variables that push a portion of total overhead into each client or segment P\&L. This can be done via formulas that reference total overhead and allocation percentages.
{% endstep %}
{% step %}
### Build client and portfolio P\&L views
Using reports and dashboards, construct views that show for each client or segment:
* Fee revenue and pass through revenue.
* Direct production and staff costs.
* Contribution margin.
* Allocated overhead.
* Fully loaded margin and EBITDA contribution.
At portfolio level, create views by:
* Studio or location.
* Sector or client type.
* Work type, for example retainer versus project.
* Size tier, for example strategic, core and long tail clients.
These views help you see which parts of the book of business drive profit and which consume disproportionate capacity or overhead.
{% endstep %}
{% step %}
### Use scenarios for pricing, scope and portfolio strategy
Clone the base model into scenario models to explore:
* Price increases or discount reductions for specific clients or segments.
* Scope expansion or reduction for individual clients.
* Focusing on higher margin sectors or work types.
* Discontinuing or reshaping unprofitable relationships.
* Shifting work between studios or locations.
In each scenario, adjust:
* Revenue rates and volumes.
* Direct costs and sourcing mix.
* Overhead allocation assumptions.
* Client mix and onboarding or offboarding timelines.
Compare scenarios using:
* Client and portfolio level profitability.
* Studio capacity and utilisation impacts.
* Cash and working capital implications.
* Valuation impacts where you choose to extend client cases into cashflow and valuation logic.
{% endstep %}
{% step %}
### Calibrate against historical client reports
To build confidence:
* Import historical revenue and cost by client or segment where available.
* Rebuild last year or last twelve months in the model to match reported client profitability.
* Calibrate allocation drivers and sourcing assumptions until model outputs align with management views.
Use this calibrated baseline as the starting point for forward looking portfolio scenarios.
{% endstep %}
{% endstepper %}
## Check your work
* Client level P\&Ls are consistent with internal reporting for key clients.
* Overhead allocations are reasonable and clearly documented.
* Scenario outputs support concrete portfolio and pricing decisions.
* Stakeholders can trace from high level client metrics down to underlying assumptions.
## Troubleshooting
Client margins look inconsistent with internal reporting
Confirm that you have aligned definitions of direct cost, pass through and overhead with your finance team and adjusted mappings accordingly.
Allocations feel arbitrary or hard to defend
Choose allocation drivers that match how clients consume capacity, such as time or headcount, and document the rationale alongside the drivers.
Model is too detailed for smaller clients
Use segments for smaller clients and reserve per client modelling for the largest and most strategic accounts.
## Related guides
* [Build a Multi Period Comparison Dashboard](/how-tos/dashboards-and-reporting/build-a-multi-period-comparison-dashboard)
* [Build a Multi Scenario Comparison](/how-tos/scenarios-and-planning/build-a-multi-scenario-comparison)
* [Mapping Subcategories](/help/importing-and-data-inputs/mapping-subcategories)
* [Multi-Branch Driver Behaviour](/syntax/drivers-syntax/multi-branch-driver-behaviour)
# ๐ Telecommunications & IT Services
# Recurring Services Revenue Model
This use case explains how to model recurring subscription and service revenue for telecommunications and IT services businesses in Model Reef.
You will:
* Represent products, plans and segments in branches and categories.
* Build drivers for subscribers, ARPU and churn.
* Model contract revenue timing, upgrades and downgrades.
* Connect recurring revenue to P\&L, Cashflow and valuation outputs.
Model Reef is not a billing or CRM system. It uses aggregated commercial and subscriber assumptions to generate financial statements, cashflows and scenarios.
## When to use this pattern
Use this pattern when:
* You sell recurring connectivity, SaaS, managed services or support contracts.
* ARPU, churn and net adds are core KPIs.
* You want to connect commercial metrics to full three statement outputs.
* You need to test pricing, bundling or acquisition scenarios.
Works well with:
* Hardware or Device Cost Modelling
* Contract Renewal Forecasting
* Support or Service Team Capacity
* Build a Recurring Revenue Forecast
***
## Architecture overview
Recurring services revenue modelling uses:
* Structure
* Branches for countries, business units or product lines.
* Categories for services, add ons and one off fees.
* Subscriber and contract drivers
* Opening subscribers per product or plan.
* Gross adds, churn and migrations.
* Contract term and renewal patterns.
* Revenue drivers
* ARPU or ARPA per segment.
* Price increases, discounts and promotions.
* One off activation, installation or hardware revenue where applicable.
* Financial outputs
* Recurring revenue and margin by product, segment and region.
* Cashflow timing from billing cycles and payment terms.
* Inputs to valuation via FCFF or FCFE logic.
***
{% stepper %}
{% step %}
### Define products, plans and segments
Start by deciding how to structure your recurring services, for example:
* Product lines: Mobile, Fixed, Data, Cloud, Managed Services.
* Plans: Entry, Standard, Premium.
* Segments: Consumer, Small business, Enterprise.
Implement this using a combination of:
* Branches for geographies or business units, such as Region - UK, Region - EU, Region - APAC.
* Categories and variable names for product and plan combinations, such as Revenue - Mobile - Premium - Consumer.
Choose a level of granularity that matches how you track KPIs and how often offerings change.
{% endstep %}
{% step %}
### Build subscriber and contract base drivers
In the Data Library, set up time series for each product or plan, including:
* Opening Subscribers.
* Gross Adds per period.
* Churned Subscribers per period.
* Net Adds per period = Gross Adds minus Churn.
* Contract Mix, for example share of customers on 12 month, 24 month or month to month.
Compute Active Subscribers per period as:
* Active Subscribers(t) = Active Subscribers(t minus 1) + Gross Adds(t) โ Churned Subscribers(t).
Where you have clear contract terms, you can also model:
* Renewal rates at end of term.
* Early termination rates.
* Migration between plans (upgrades and downgrades).
Keep these as drivers so you can adjust them in scenarios.
{% endstep %}
{% step %}
### Create ARPU and pricing drivers
For each product, plan and segment combination, create drivers such as:
* ARPU (Average Revenue per User) per period.
* List Price and Discount Percentage where you want to separate base price and discount.
* Price Increase Events (for example scheduled increases each year or in specific months).
* Bundled and unbundled price structures where relevant.
You can then express revenue per product as:
* Revenue = Active Subscribers ร ARPU\
or
* Revenue = Active Subscribers ร List Price ร (1 โ Discount Percentage).
Use seasonality and promotions via modifiers if you have pronounced intraโyear patterns.
{% endstep %}
{% step %}
### Account for one off and ancillary revenue
Create separate Revenue variables for one off items such as:
* Activation and installation fees.
* Upfront hardware or device sales.
* Professional services associated with onboarding or customisation.
* Penalty or exit fees where material.
Keep these distinct from recurring revenue so you can analyse the recurring base on its own. Timing of these items will generally follow events such as new subscriptions, migrations or terminations.
{% endstep %}
{% step %}
### Model cash timing through billing cycles and payment terms
Set payment timing and delays so that cash behaviour reflects billing practices, for example:
* Monthly billing in advance or in arrears.
* Quarterly or annual billing for enterprise contracts.
* Typical payment terms (for example 14, 30 or 45 days).
Model Reef will create receivables and cashflows according to these settings:
* Revenue is accrued when service is delivered or billed according to your policy.
* Cashflow statement reflects when cash is actually collected.
* Balance Sheet holds receivables for any gap between accrual and cash receipt.
This lets you see the impact of growth or pricing changes on working capital and funding needs.
{% endstep %}
{% step %}
### Use scenarios for growth, pricing and churn strategies
Clone the base model into scenario models to test strategies such as:
* Higher or lower subscriber growth in specific products or segments.
* ARPU expansion through price increases or upsell of add ons.
* Changes in churn due to service improvements or competitive pressure.
* Shifts in product mix between legacy and new offerings.
* Different contract term structures (more or fewer customers on long term plans).
In each scenario, adjust:
* Gross adds, churn and migration drivers.
* ARPU and price increase drivers.
* Contract mix and renewal assumptions.
* Promotion or discount rules.
Compare scenarios using:
* Recurring revenue and total revenue by product, plan and region.
* Margin when combined with cost models.
* Cashflow and valuation metrics.
* KPIs such as net adds, churn, ARPU and lifetime value where you choose to compute them.
{% endstep %}
{% endstepper %}
***
## Check your work
* Subscriber, ARPU and churn assumptions reconcile with historical KPIs.
* Revenue by product and segment matches recent financial reports when historical drivers are applied.
* Scenario results are intuitive to commercial, product and finance teams.
* Model complexity reflects your product and pricing catalogue without becoming unmanageable.
***
## Troubleshooting
Revenue does not match billing system reports
Check that subscriber counts, contract terms and ARPU values are aligned with your source systems and that you have not double counted upgrades or migrations.
Churn and growth behaviour look unrealistic
Revisit driver definitions for gross adds and churn and ensure they are expressed in consistent units and rates.
Too many product variants to manage
Group similar plans or offerings into a smaller number of representative product families and model them at that level.
***
## Related guides
* [Build a KPI Dashboard](/how-tos/dashboards-and-reporting/build-a-kpi-dashboard)
* [Build a Live Actuals Model Using Xero](/how-tos/data-workflows-and-automation/build-a-live-actuals-model-using-xero)
* [Mapping Units & Frequency](/help/importing-and-data-inputs/mapping-units-and-frequency)
* [Chart & Table Syntax](/syntax/chart-and-table-syntax)
# Hardware/Device Cost Modelling
This use case explains how to model hardware and device costs, subsidies and margins for telecommunications and IT services businesses in Model Reef.
You will:
* Represent devices and hardware bundles alongside recurring services.
* Model hardware purchase costs, subsidies and financing where applicable.
* Connect device sales and instalment plans to P\&L and Cashflow.
* Analyse device related margin and payback in combination with service revenue.
Model Reef is not a stock control or billing engine. It uses aggregated device and contract assumptions to generate financial and cashflow impacts.
## When to use this pattern
Use this pattern when:
* You bundle handsets, routers, set top boxes or other devices with service plans.
* You subsidise hardware and recover costs through future service revenue.
* Device economics are important to customer acquisition and retention decisions.
* You need to forecast device related margin and working capital.
It is commonly paired with:
* Recurring Services Revenue Model
* Inventory Replenishment Cycles
* Contract Renewal Forecasting
## Architecture overview
{% stepper %}
{% step %}
### Structure
* Categories for device revenue and device COGS.
* Optional branches or categories for device only channels or programmes.
{% endstep %}
{% step %}
### Volume drivers
* Devices sold per product or plan.
* Take up rates for device bundles versus SIM only or service only offers.
{% endstep %}
{% step %}
### Price and cost drivers
* Retail price and discounts.
* Wholesale cost, rebates and subsidies.
* Instalment plan structures where used.
{% endstep %}
{% step %}
### Financial outputs
* Device margin and contribution by product or segment.
* Cash outflows for purchases and inflows from customers.
* Working capital and funding needs linked to inventory and receivables.
{% endstep %}
{% step %}
### Define device products and groupings
Decide how to group devices for planning purposes, for example:
* By device type (phones, routers, set top boxes, other equipment).
* By price band (entry, mid, premium).
* By key manufacturer or platform where that matters commercially.
Set up Revenue and COGS variables, such as:
* Revenue - Device - Premium Handsets.
* COGS - Device - Premium Handsets.
* Revenue - Device - Routers.
* COGS - Device - Routers.
If you have device only channels, you can create separate branches to analyse those separately from bundled offers.
{% endstep %}
{% step %}
### Link device volumes to subscriber and sales drivers
Starting from the Recurring Services Revenue Model, create drivers such as:
* SIM Only vs Device Bundle mix per product or segment.
* Device replacement cycles, for example every 24 or 36 months.
* Proportion of gross adds taking a device bundle.
Calculate device units sold per period using:
* Device Units Sold = New Bundled Subscribers plus Replacements.
Where you sell devices separately from service, add drivers for:
* Standalone device sales volumes per channel or segment.
This links device volumes to the same commercial flows that drive recurring revenue.
{% endstep %}
{% step %}
### Model device prices, costs and subsidies
For each device grouping, create drivers for:
* Retail Price per device.
* Upfront discount or subsidy (for example customer pays less than retail).
* Wholesale Cost per device from suppliers.
* Supplier rebates or volume discounts, expressed as reductions in effective unit cost.
Construct revenue and COGS like this:
* Device Revenue = Device Units Sold ร Customer Device Price.
* Device COGS = Device Units Sold ร Effective Wholesale Cost.
Subsidy per unit is then the difference between wholesale cost and customer price, which can be recovered through future service margins connected via the recurring revenue model.
{% endstep %}
{% step %}
### Include instalment or financing plans where relevant
If you offer devices on instalment plans rather than upfront payment, define drivers for:
* Instalment term (for example 12, 24 or 36 months).
* Instalment amount per period.
* Interest or financing charges, if any.
* Default or non payment assumptions if you want to approximate credit risk.
You can represent instalment plans as:
* Revenue variables that spread device payments over the term, and
* Cashflow timing that reflects when cash is collected versus when devices are paid for.
This will increase receivables and extend device related cashflow impacts over the life of the instalment plan.
{% endstep %}
{% step %}
### Connect device costs to inventory and working capital
If you carry device inventory, combine this pattern with Inventory Replenishment Cycles to approximate:
* Inventory on hand by device grouping.
* Purchase timing relative to sales.
* Supplier payment terms.
This will drive:
* Cash outflows for device purchases.
* Inventory balances and turnover.
* Working capital tied up in device stock.
Balance device purchases and stock levels against expected sales to avoid over or under stocking in scenarios.
{% endstep %}
{% step %}
### Use scenarios for pricing, subsidy and mix strategies
Clone the base model into scenario models to test:
* Higher or lower device subsidies.
* Different retail pricing and instalment structures.
* Shifts in mix between SIM only and device bundles.
* Changing device replacement cycles.
* Different supplier cost and rebate structures.
In each scenario, adjust:
* Retail price, subsidy and wholesale cost drivers.
* Bundle mix and replacement cycle drivers.
* Instalment term and payment assumptions.
* Inventory and supplier term drivers.
Compare scenarios using:
* Device margin and total margin inclusive of service revenue.
* Customer lifetime value where you choose to combine service and device economics.
* Cashflow and working capital requirements.
* Sensitivity of profitability to subsidy and mix decisions.
{% endstep %}
{% endstepper %}
## Check your work
* Device prices and costs align with commercial and procurement data.
* Subsidy and instalment assumptions are consistent with actual offers.
* Device volumes tied to subscriber flows are realistic.
* Combined service and device economics support acquisition and retention strategies.
## Troubleshooting
Device margin appears misleading without service revenue
Always interpret device economics together with recurring service margins, especially where you subsidise hardware.
Inventory balances look unrealistic
Recheck replenishment rules, lead times and purchase timing assumptions and ensure you are not double counting device volumes.
Model is over detailed for rapidly changing device portfolios
Group devices into a small number of representative categories and focus on the economics of those rather than individual models.
## Related guides
* [Build a Machine Readable Model for Automation](/how-tos/data-workflows-and-automation/build-a-machine-readable-model-for-automation)
* [Build a Multi Scenario Valuation Pack](/how-tos/valuation/build-a-multi-scenario-valuation-pack)
* [Mapping Variable Types](/help/importing-and-data-inputs/mapping-variable-types)
* [Cloning Scenarios](/syntax/scenario-syntax/cloning-scenarios)
# Contract Renewal Forecasting
This use case explains how to model contract renewals, term structures and retention for telecommunications and IT services businesses in Model Reef.
You will:
* Represent contract terms and cohorts for key products and segments.
* Build drivers for renewal, churn and regrading at end of term.
* Connect renewal behaviour to recurring revenue and device economics.
* Use scenarios to test retention, pricing and re contract strategies.
Model Reef is not a CRM or contract management platform. It models contract behaviour at cohort or segment level, not individual accounts.
## When to use this pattern
Use this pattern when:
* You sell fixed term contracts such as 12, 24 or 36 month plans.
* Renewal behaviour and retention are key value drivers.
* You need forward visibility on contracts rolling off and being renewed or lost.
* You want to test different re contract, pricing and upgrade strategies.
It complements:
* Recurring Services Revenue Model
* Hardware or Device Cost Modelling
* Support or Service Team Capacity
## Architecture overview
Contract renewal forecasting uses:
* Contract cohorts
* New contracts written in a given period and plan.
* Remaining term structure per cohort.
* Renewal and churn drivers
* Renewal rates at end of term.
* Churn on expiry.
* Upgrades or downgrades to different plans.
* Revenue and margin impacts
* ARPU changes on renewal or migration.
* Device and subsidy impacts where relevant.
* Cash timing via billing and payment terms.
* Scenario analysis
* Different retention and re contract strategies.
* Portfolio shifts between legacy and new products.
{% stepper %}
{% step %}
### Define contract cohorts and terms
Start by defining contract cohorts at the level you want to track, for example:
* Product and plan level for major offerings.
* Broad contract types for smaller or legacy portfolios.
In the Data Library, create drivers such as:
* New Contracts Written per Period per Cohort.
* Contract Term in months (for example 12, 24, 36).
* Contract Type (for example handset inclusive vs SIM only).
These become the base for renewal and churn modelling.
{% endstep %}
{% step %}
### Track in force contracts over time
For each cohort, approximate the number of in force contracts over time. A simple approximation is:
* In Force Contracts(t) = Previous In Force minus Normalised Mid Term Churn until expiry.
Where you want more detail, you can model:
* Scheduled expiry period based on term.
* Mid term churn before expiry.
* End of term behaviour at renewal decision point.
Keep this at cohort level rather than individual contract level to keep the model tractable.
{% endstep %}
{% step %}
### Apply renewal, churn and migration rules at expiry
Define drivers for end of term behaviour per cohort, such as:
* Renewal Rate (percentage of contracts that renew on a new term).
* Churn on Expiry (percentage that leave).
* Migration Split (percentage that move to each available new plan).
At the end of each cohort's term, allocate in force contracts into:
* Renewed contracts in the same or new plan cohorts.
* Churned customers.
* Upgraded or downgraded plan cohorts.
This can be implemented using formulas that move counts between cohort driver series at the appropriate period.
{% endstep %}
{% step %}
### Link renewed and migrated contracts to revenue
Connect contract cohort behaviour to revenue by:
* Associating each cohort and plan with an ARPU or pricing profile.
* Applying different ARPU profiles to renewed, upgraded and downgraded contracts.
* Updating Revenue variables to reference updated cohort based active subscriber counts.
This allows you to see:
* How much revenue is at risk at each renewal point.
* The effect of price changes and re contract offers on ARPU.
* The transition of customers from legacy to new products over time.
{% endstep %}
{% step %}
### Integrate device and subsidy effects where relevant
If you bundle devices with contracts, combine this pattern with Hardware and Device Cost Modelling by:
* Linking device subsidies and repayment plans to specific cohorts.
* Ensuring that churn and renewal behaviour carries associated device economics, for example residual instalments or early termination fees.
* Adjusting device replacement cycles for customers who re contract early and receive new hardware.
For simplicity, you can approximate these effects at cohort level using average values.
{% endstep %}
{% step %}
### Use scenarios for retention, pricing and migration strategies
Clone the base model into scenario models to explore:
* Different renewal and churn rates at end of term.
* Stronger upgrade programs to move customers to higher value plans.
* More aggressive or conservative price increases on renewal.
* Shifts in contract term structures, for example moving more customers to 24 month terms.
* Campaigns targeting specific cohorts nearing expiry.
In each scenario, adjust:
* Renewal, churn and migration drivers.
* ARPU and pricing profiles for renewed and migrated cohorts.
* Device replacement and subsidy assumptions.
Compare scenarios using:
* Revenue retention and growth over the forecast horizon.
* Margin and device payback metrics.
* Customer lifetime value where you choose to calculate it.
* Cashflow and valuation changes arising from different strategies.
{% endstep %}
{% endstepper %}
Check your work
* Contract cohort sizes and timing reconcile with historical contract and billing data.
* Renewal and churn assumptions are consistent with observed behaviour.
* Migration flows between products are plausible and align with commercial strategy.
* Scenario results support decision making rather than creating noise.
Troubleshooting
* **In force contract counts behave unexpectedly**\
Check term assumptions and ensure mid term churn and expiry treatments are consistent and not double counted.
* **Revenue diverges from simpler subscriber models**\
Ensure that the link between cohort based counts and ARPU is correctly implemented and that you are not summing both cohort and non cohort counts.
* **Too many cohorts to track**\
Aggregate cohorts into broader groups by product, term and vintage and use average behaviours rather than modelling each small group separately.
## Related guides
* [Build a Pricing Model](/how-tos/operations-and-unit-economics/build-a-pricing-model)
* [Build a Relative Valuation Using Fundamentals](/how-tos/valuation/build-a-relative-valuation-using-fundamentals)
* [Model Archiving](/help/workspace-and-organisation/model-archiving)
* [Common Size Mode](/syntax/chart-and-table-syntax/common-size-mode)
# Support/Service Team Capacity
This use case explains how to model support and service team capacity, workload and cost for telecommunications and IT services businesses in Model Reef.
You will:
* Represent support and service functions by team, role and location.
* Build drivers for contact volumes, tickets and handling effort.
* Link workload to headcount, utilisation and service levels.
* Connect support economics to P\&L, Cashflow and customer strategies.
Model Reef is not a ticketing or contact centre platform. It uses aggregated workload and staffing assumptions, not per contact data.
## When to use this pattern
Use this pattern when:
* Support and service are major cost and experience drivers.
* You need to align headcount with subscriber and contract growth.
* You want to test service level and outsourcing strategies.
* You need to show how customer propositions affect support workload.
It ties directly into:
* Recurring Services Revenue Model
* Contract Renewal Forecasting
* Build a Staffing Cost Model
## Architecture overview
Support and service capacity modelling uses:
1. Structure
* Branches for regions, channels or support functions.
* Staff variables for roles and teams.
2. Workload drivers
* Contacts or tickets per customer per period.
* Average handling time per contact.
* Mix of channels (phone, chat, email, self service).
3. Capacity and staffing
* FTEs per role and location.
* Working hours and schedule patterns.
* Target utilisation and occupancy.
4. Financial outputs
* Staff cost and overhead.
* Cost per contact or per customer.
* Impact on EBITDA and cash.
{% stepper %}
{% step %}
### Set up support and service branches
In the branch tree, create branches for your support structure, for example:
* Support and Service
* Contact Centre - Country A
* Contact Centre - Country B
* Technical Support - Region Wide
* Field Service Teams
Alternatively, if support is embedded within regions or product units, place support branches under each region or unit.
{% endstep %}
{% step %}
### Build workload drivers from subscribers and contracts
From your Recurring Services Revenue and Contract Renewal models, derive drivers such as:
* Subscribers or active contracts per segment.
* Contact Rate per customer per period (for example contacts per customer per month).
* Ticket Rate per active device or service for technical support.
Calculate total workload per period, for example:
* Contacts = Active Customers ร Contact Rate.
* Tickets = Active Services ร Ticket Rate.
If you use multiple channels, split contacts across channels using mix drivers such as:
* Share of contacts via phone, chat, email, self service.
{% endstep %}
{% step %}
### Convert workload into effort and FTE requirements
Create drivers for handling effort, such as:
* Average Handling Time per contact in minutes by channel.
* After call work or wrap time allowances.
* Shrinkage factors for training, breaks and other non contact time.
Compute total effort, for example:
* Total Handling Minutes = Contacts ร Average Handling Time.
* Required FTEs = Total Handling Minutes divided by (Working Minutes per FTE ร Target Utilisation).
Use these calculations as driver variables to inform staffing decisions.
{% endstep %}
{% step %}
### Model staff headcount, cost and timing
Create Staff variables for each support role, for example:
* Staff - Contact Centre Advisors - Country A.
* Staff - Team Leaders - Country A.
* Staff - Technical Support Engineers.
* Staff - Field Technicians.
For each, specify:
* Headcount per period based on FTE requirements.
* Salary and on cost assumptions.
* Start dates for hires and any planned changes.
* Payment frequency and delay settings for cash timing.
Where you use outsourcers, represent them either as:
* Staff with different cost structures and flexibility, or
* Opex variables linked to volume and contracted unit rates.
{% endstep %}
{% step %}
### Link service levels and self service to workload
Define drivers for:
* Target or actual service levels and first contact resolution.
* Proportion of queries handled by self service without agent involvement.
* Impact of product design or customer communication on contact rates.
Represent improvements in self service, product and process design as changes to:
* Contact Rate per customer.
* Channel mix toward lower cost channels.
* Average Handling Time.
Use scenarios to test investment in digital service and its payback in reduced contact volumes and staff cost.
{% endstep %}
{% step %}
### Use scenarios for sourcing, quality and service strategy
Clone the base model into scenario models to explore:
* Increasing or decreasing service levels.
* Shifting work between internal teams and outsourcers.
* Moving work to lower cost locations.
* Changing product or policy to reduce contacts.
* Upskilling teams to improve first contact resolution.
In each scenario, adjust:
* Workload, handling time and self service drivers.
* FTE requirements and sourcing assumptions.
* Pay rates and on costs.
* Target utilisation and service levels.
Compare scenarios using:
* Total support cost and cost per contact.
* Support cost per customer or per unit of revenue.
* Service level and workload metrics.
* Customer retention and NPS metrics where you choose to add them as external inputs or qualitative indicators.
{% endstep %}
{% endstepper %}
## Check your work
* Workload and contact rates reconcile with historical support reports.
* Staffing and cost assumptions align with HR and finance data.
* Scenario outputs are understandable for operations, finance and product teams.
* The model supports decision making on service strategy rather than trying to replicate operational systems.
## Troubleshooting
Required FTE numbers look too high or too low
Recheck handling time, shrinkage and utilisation assumptions and confirm that contact rates are on the correct basis (per active customer, per device, etc).
Support cost does not reconcile to P&L
Ensure that all support related costs (internal staff, outsourcers, tools) are mapped into the relevant Staff and Opex variables and categories.
Model is too granular for quick analysis
Aggregate roles, channels or regions where appropriate and use representative averages instead of detailed breakdowns when decisions do not require that level of detail.
## Related guides
* [Build a Rolling Forecast](/how-tos/scenarios-and-planning/build-a-rolling-forecast)
* [Build a Seasonality Adjusted Forecast](/how-tos/scenarios-and-planning/build-a-seasonality-adjusted-forecast)
* [Model Structure Principles](/help/building-your-model/model-structure-principles)
* [Creating Scenarios](/syntax/scenario-syntax/creating-scenarios)
# ๐ Education Providers (Private, Vocational)
# Student Enrolment & Intake Forecasts
This use case explains how to model student enrolment, intakes and cohorts for private and vocational education providers in Model Reef.
You will:
* Represent campuses, programs and intakes in the branch and category structure.
* Build drivers for enquiries, applications, offers and enrolments.
* Model intakes and student cohorts over multiple terms or years.
* Connect enrolment forecasts to revenue, staffing, facilities and cash.
Model Reef is not a student information or CRM system. It works at planning level using aggregated intake and cohort assumptions, not individual student records.
## When to use this pattern
Use this pattern when:
* Tuition and fee income is driven by intakes, cohorts and progression.
* You need to plan revenue and capacity across campuses and programs.
* Enrolment risk and conversion are key to financial performance.
* You want one consistent model for enrolment, teaching cost and profit.
It combines well with:
* Course or Program Profitability
* Teaching Staff Allocation Model
* Campus or Program Consolidation
* Build a Recurring Revenue Forecast
## Architecture overview
{% stepper %}
{% step %}
### Structure
* Branches for campuses or regions.
* Categories and variables for programs, courses and levels.
{% endstep %}
{% step %}
### Funnel drivers
* Enquiries, applications, offers and acceptances.
* Conversion rates between each stage.
{% endstep %}
{% step %}
### Cohort and intake drivers
* Intakes per year per program.
* Cohort size and progression.
* Retention and completion rates.
{% endstep %}
{% step %}
### Financial drivers
* Tuition fee per student per period.
* Scholarships and discounts.
* Payment timing and collection patterns.
{% endstep %}
{% step %}
### Set up campuses and programs
In the branch tree, create a structure that matches your organisation, for example:
* Group
* Campus - City A
* Campus - City B
* Online Campus
Within each campus, represent programs using categories and variable naming such as:
* Revenue - Tuition - Program A - Domestic.
* Revenue - Tuition - Program A - International.
* Revenue - Tuition - Program B - Domestic.
This keeps campus and program views clean and supports consolidation later.
{% endstep %}
{% step %}
### Build funnel drivers for demand and conversion
In the Data Library, create drivers for each program and intake cycle, for example:
* Enquiries per period.
* Applications per period.
* Offers made per period.
* Acceptances or enrolments per period.
You can either:
* Enter each stage directly from marketing and admissions plans, or
* Model conversion rates between stages, such as Application Rate, Offer Rate and Accept Rate.
Compute intakes as the number of new students enrolled per intake period. You can maintain separate drivers for domestic and international students or for different channels if needed.
{% endstep %}
{% step %}
### Create cohort and progression logic
Once you know how many students start in each intake, represent their progression as cohorts. For each program, define drivers for:
* Standard duration in terms or years.
* Progression rates between levels or years.
* Retention and drop out rates per stage.
* Completion rates.
You can approximate active student numbers per period with cohort style logic, for example:
* Active Students in Year 1 = New Intake minus Early Dropouts.
* Active Students in Year 2 = Prior Year 1 Progressing minus Year 2 Dropouts.
Keep this at program level rather than individual course level unless you need more detail. You can differentiate full time and part time loads using separate cohorts or load factors.
{% endstep %}
{% step %}
### Link student numbers to tuition revenue
For each program and student type, create Revenue variables such as:
* Revenue - Tuition - Program A - Domestic.
* Revenue - Tuition - Program A - International.
Attach drivers for:
* Tuition fee per student per term or per year.
* Scholarships or discount percentages.
* Load factors for part time students if applicable.
Then express revenue as:
* Tuition Revenue = Active Students ร Fee per Student ร Load Factor.
Use timing settings to align revenue recognition with delivery periods, for example by term or by academic year. Cash timing will then be handled via delays that represent when fees are billed and paid.
{% endstep %}
{% step %}
### Model fee payments, funding and cash timing
Set delays and timing to reflect how and when you are paid, for example:
* Upfront payments at the start of term.
* Instalments across the term.
* Deferred payment arrangements or loan payments.
* Government funding or subsidies paid on census date or completion.
Model Reef will then create receivables and cashflows consistent with these assumptions. This allows you to see the impact of growth, discounting and retention on cash and working capital as well as revenue.
{% endstep %}
{% step %}
### Use scenarios for demand, pricing and retention
Clone the base model into scenario models to test:
* Different enquiry, application and conversion outcomes.
* Alternative pricing and scholarship strategies.
* Changes in retention and progression by program.
* New program launches or program closures.
* Shifts between on campus and online delivery.
In each scenario, adjust:
* Funnel and cohort drivers.
* Fee levels and discount policies.
* Intake timing and size.
* Funding and payment timing assumptions.
Compare scenarios using:
* Tuition revenue by program and campus.
* Total students and full time equivalent load.
* Cashflow and working capital profiles.
* Capacity and staffing implications when combined with teaching models.
{% endstep %}
{% endstepper %}
## Check your work
* Intake, conversion and retention assumptions align with recent history.
* Tuition revenue reconciles with prior year accounts when historic drivers are applied.
* Scenario outcomes are credible and interpretable for recruitment, academic and finance stakeholders.
* Cohort logic is simple enough to maintain for your planning horizon.
## Troubleshooting
Student numbers look too high or low compared to history
Recheck funnel and retention drivers and ensure you are not double counting intakes across terms or years.
Revenue does not match academic calendars
Confirm that timing settings match your term or semester structure and that fees are not being recognised outside delivery periods.
Model is too detailed for small programs
Group smaller programs into aggregated program families and reserve detailed cohort modelling for large or strategic programs.
## Related guides
* [Build a Terminal Value Model](/how-tos/valuation/build-a-terminal-value-model)
* [Build a Top Down Forecast](/how-tos/core-modelling/build-a-top-down-forecast)
* [Model Templates](/help/workspace-and-organisation/model-templates)
* [Drilldown Behaviour](/syntax/chart-and-table-syntax/drilldown-behaviour)
# Course/Program Profitability
This use case explains how to model profitability by course or program for private and vocational education providers in Model Reef.
You will:
* Attribute revenue and costs to courses and programs across campuses.
* Combine tuition, fees, teaching cost and direct support cost into program P\&L views.
* Allocate shared overhead where needed to see fully loaded margins.
* Use scenarios to test pricing, cost and mix strategies.
Model Reef is not a learning management or timetabling system. It provides a financial view of course and program economics based on the structures and drivers you define.
## When to use this pattern
Use this pattern when:
* You need to understand which programs drive margin and which consume resources.
* You operate multiple campuses, modes or delivery formats for the same programs.
* You want to link pricing, intake and teaching plans to financial outcomes.
* You are considering launching, scaling or closing programs.
It sits on top of:
* Student Enrolment and Intake Forecasts
* Teaching Staff Allocation Model
* Campus or Program Consolidation
## Architecture overview
Course or program profitability modelling uses:
* Structure
* Branches for campuses or regions.
* Categories and variables for programs and course groups.
* Revenue attribution
* Tuition and fee revenue per program and campus.
* Additional revenue such as materials, exam or service fees.
* Direct cost attribution
* Teaching staff cost per program or group of programs.
* Consumables, materials, licences and facility usage.
* Placement, lab or clinic costs for vocational programs.
* Overhead allocation
* Shared administration and student support cost.
* Facility and central services cost allocation.
* Fully loaded margins by program.
{% stepper %}
{% step %}
### Decide on program and course grouping
Decide at what level you want to analyse profitability, for example:
* Whole qualification programs such as diplomas and degrees.
* Streams or majors within programs.
* Course clusters that are shared between programs.
Represent these as:
* Categories such as Program - Nursing, Program - Business, Program - IT.
* Variable naming that includes program and campus identifiers.
Group very small or low volume programs where appropriate to keep the model maintainable.
{% endstep %}
{% step %}
### Attribute revenue to programs and campuses
From Student Enrolment and Intake Forecasts, you have:
* Active student counts by program and campus.
* Tuition fees and scholarships per program and student type.
Ensure that tuition Revenue variables are clearly tagged by program and campus, for example:
* Revenue - Tuition - Program Nursing - Campus A.
* Revenue - Tuition - Program Nursing - Campus B.
If you have additional fees, create separate Revenue variables for:
* Materials or lab fees.
* Registration or exam fees.
* Placement or clinical fees.
This ensures that program level P\&Ls reflect all relevant income streams.
{% endstep %}
{% step %}
### Map teaching staff cost to programs
Using the Teaching Staff Allocation Model, determine how teaching staff effort is allocated across programs. You can:
* Assign teaching roles primarily to one program where that is accurate, or
* Use load allocation drivers that split effort across multiple programs based on contact hours, student load or historical teaching patterns.
Create Staff variables such as:
* Staff - Lecturers - Program Nursing.
* Staff - Tutors - Program Business.
* Staff - Clinical Supervisors - Program Nursing.
Or maintain central Staff variables and use allocation formulas that push cost into program level Opex variables based on teaching load.
The key is to identify the portion of staff cost that is directly driven by each program.
{% endstep %}
{% step %}
### Capture direct non staff costs per program
Create Opex variables for direct program costs, for example:
* Opex - Teaching Materials - Program Nursing.
* Opex - Software Licences - Program IT.
* Opex - Lab Consumables - Program Science.
* Opex - Placement and Supervision Fees - Program Allied Health.
Link these costs to drivers such as:
* Cost per student.
* Cost per class or group.
* Cost per placement or lab session.
This allows direct costs to scale with enrolments and delivery patterns.
{% endstep %}
{% step %}
### Allocate overhead and shared costs
Shared costs that cannot be directly assigned to a single program need allocation, such as:
* Campus administration and student services.
* Marketing and admissions.
* Facilities and utilities.
* Central IT and management overhead.
Define allocation drivers in the Data Library, for example:
* Share of student load or enrolments.
* Share of direct teaching cost.
* Share of revenue.
* Fixed allocations for strategic programs.
Create allocation variables that move portions of total overhead into program level Opex variables. This produces fully loaded program P\&L views alongside direct contribution views.
{% endstep %}
{% step %}
### Build program and portfolio P\&L views
Use reports and dashboards to build:
* Program level P\&Ls per campus and for the group.
* Comparisons between programs by margin, revenue and student load.
* Campus level views showing program mix and margin.
* Portfolio level summaries by discipline or qualification type.
These views support decisions about pricing, cost structure, delivery format and program mix.
{% endstep %}
{% step %}
### Use scenarios for pricing, mix and cost strategies
Clone the base model into scenario models to test:
* Fee increases or scholarship changes by program.
* Scaling up or down specific programs.
* Introducing new pathways, delivery modes or campuses.
* Changing staff mix or teaching models (for example more online or blended).
* Adjusting overhead allocations and campus footprints.
In each scenario, adjust:
* Enrolment and fee drivers.
* Staff allocation and cost drivers.
* Direct cost assumptions.
* Overhead allocation rules.
Compare scenarios using:
* Program and campus level margins.
* Total portfolio margin and cashflow.
* Capacity and staffing implications.
* Strategic contribution of programs beyond short term margin where you choose to add qualitative markers.
{% endstep %}
{% endstepper %}
## Check your work
* Program level revenues reconcile with academic and finance reporting for recent periods.
* Direct teaching and support costs match how resources are actually deployed.
* Overhead allocation rules are transparent and acceptable to stakeholders.
* Scenario analysis helps frame concrete decisions rather than just adding complexity.
## Troubleshooting
Program profitability looks very different to internal reports
Confirm definitions of direct and indirect cost with finance stakeholders and adjust mappings and allocations accordingly.
Overhead allocations feel arbitrary
Choose drivers that best represent resource usage, such as teaching hours, student load or occupied space, and document the rationale alongside the drivers.
Model is unwieldy with many small programs
Group minor programs or streams into aggregated program families and focus detail on material or strategic areas.
## Related guides
* [Build a Unified Forecast from Multiple Inputs](/how-tos/core-modelling/build-a-unified-forecast-from-multiple-inputs)
* [Build a Unit Economics Model](/how-tos/operations-and-unit-economics/build-a-unit-economics-model)
* [Modifier Drivers](/help/drivers-variables-and-timing/modifier-drivers)
* [Driver Editor Screen](/syntax/understanding-the-interface/driver-editor-screen)
# Teaching Staff Allocation Model
This use case explains how to model teaching staff loads, allocation and cost for private and vocational education providers in Model Reef.
You will:
* Represent teaching roles and teams across campuses and programs.
* Build drivers for contact hours, preparation and assessment effort.
* Allocate teaching effort and cost to programs and courses.
* Connect staff planning to enrolments, capacity and program profitability.
Model Reef is not a timetable generator or HR system. It models teaching effort, allocation and cost at planning level rather than individual class schedules.
## When to use this pattern
Use this pattern when:
* Teaching staff cost is one of the largest expense lines.
* You need to align hiring and teaching loads with enrolment and program plans.
* You want to understand the cost to deliver each program or group of courses.
* You are exploring different delivery or staffing models.
It integrates with:
* Student Enrolment and Intake Forecasts
* Course or Program Profitability
* Campus or Program Consolidation
* Build a Staffing Cost Model
## Architecture overview
Teaching staff allocation modelling uses the following building blocks:
{% stepper %}
{% step %}
### Structure
* Branches for campuses or academic units.
* Staff variables for teaching roles.
{% endstep %}
{% step %}
### Workload drivers
* Contact hours per course or program.
* Preparation, marking and administration effort.
* Class sizes and group numbers.
{% endstep %}
{% step %}
### Allocation and cost
* Allocation of staff effort to programs.
* Salary and on cost per role.
* Use of permanent, part time and casual staff.
{% endstep %}
{% step %}
### Capacity and planning
* Maximum feasible loads per role.
* Headcount and cost required under different enrolment scenarios.
{% endstep %}
{% endstepper %}
***
## Step 1: Define teaching roles and units
Start by listing the main teaching roles, for example:
* Professors or senior lecturers.
* Lecturers or trainers.
* Tutors or teaching assistants.
* Clinical or workplace supervisors for vocational programs.
Decide how to group academic units, for example by faculty or department, then create Staff variables such as:
* Staff - Lecturers - Nursing - Campus A.
* Staff - Tutors - Business - Campus B.
* Staff - Clinical Supervisors - Health - Campus A.
These variables will hold headcount, cost and timing for teaching roles.
***
## Step 2: Create workload drivers for teaching effort
In the Data Library, create drivers for each program or course group, such as:
* Contact Hours per Student per Course.
* Number of Courses per Program per Term.
* Typical Class Size.
* Preparation and Marking Hours per Contact Hour.
* Additional coordination or administration hours per course.
From Student Enrolment and Intake Forecasts, you already have student numbers per program and campus. Use these to derive:
* Total Contact Hours = Students ร Contact Hours per Student.
* Number of Classes or Groups = Students รท Class Size.
* Total Teaching Hours = Contact Hours + Preparation and Marking Hours + Coordination Hours.
These series represent the total teaching effort required by program or course group.
***
## Step 3: Allocate teaching effort to roles and staff groups
Define how teaching effort is shared between roles, for example:
* Percentage of contact hours delivered by lecturers versus tutors.
* Clinical supervision portion delivered by supervisors versus workplace mentors.
Create allocation drivers such as:
* Share of teaching hours by role for each program.
Then calculate required hours per role and program and use these to inform Staff variables. You can use formulas that link Staff variables to the required hours and convert them to FTE using working hours per FTE.
***
## Step 4: Build staff cost and timing
For each Staff variable, set:
* Headcount per period (either directly or via FTE drivers).
* Salary and benefits per FTE.
* On cost percentages for pension, payroll taxes and other charges.
* Start and end dates for roles.
* Payment frequency and delay for cash timing.
Where you use casual or sessional staff, you can represent them either as separate Staff variables with different salary and loadings, or as Opex variables linked to teaching hours via pay rates per hour.
This generates the teaching staff cost lines in P\&L and corresponding cashflows.
***
## Step 5: Attribute teaching cost to programs and courses
Use either of these approaches, or a mix:
{% stepper %}
{% step %}
### Direct staff per program
Where staff are predominantly assigned to one program, map Staff variables directly to that program's P\&L.
{% endstep %}
{% step %}
### Central staff with allocation
Maintain staff in faculty or campus branches and create allocation Opex variables that push cost into program level cost variables based on teaching hours or student load.
{% endstep %}
{% endstepper %}
In both cases, the objective is that course or program profitability views show a fair share of teaching cost for each offering.
***
## Step 6: Use scenarios for staffing, delivery and mode strategies
Clone the base model into scenario models to explore:
* Different class size and teaching load policies.
* Shifts between face to face and online or blended delivery.
* Increased use of sessional staff.
* Centralisation of certain courses across campuses.
* Investing in additional teaching resources for priority programs.
In each scenario, adjust:
* Workload and class size drivers.
* Allocation of teaching effort across roles.
* Headcount and salary levels.
* Use of casual versus permanent staff.
Compare scenarios using:
* Teaching staff cost by program, campus and role.
* Capacity and load indicators for staff.
* Course and program margin when combined with revenue and direct cost models.
* Overall EBITDA and cash impact.
***
## Check your work
* Teaching loads and class sizes match academic and industrial norms.
* Staff cost outputs reconcile with HR and finance data for recent periods.
* Program level staff cost shares align with internal expectations.
* Scenario outcomes are realistic and useful for academic and finance planning.
***
## Troubleshooting
Required staff numbers look too high or low
Check workload, class size and working hours per FTE assumptions and ensure they are consistent across programs and roles.
Course profitability shifts unexpectedly when staff assumptions change
Verify that allocation rules are correct and not double counting or omitting staff cost for some programs.
Model is too complex with many small courses
Group smaller courses into course clusters or modules and apply average workloads for planning purposes rather than modelling each course separately.
***
## Related guides
* [Build a Variance Analysis Model](/how-tos/dashboards-and-reporting/build-a-variance-analysis-model)
* [Build an Acquisition Case vs Base Case](/how-tos/investment-and-transactions/build-an-acquisition-case-vs-base-case)
* [Staff Variables: what is, rules, what it affects](/help/drivers-variables-and-timing/staff-variables)
* [Drivers Syntax](/syntax/drivers-syntax)
# Campus/Program Consolidation
This use case explains how to model consolidation, expansion and restructuring of campuses and programs for private and vocational education providers in Model Reef.
You will:
* Represent each campus and program as branches and categories in a group model.
* Test closing, merging or opening campuses and programs.
* See how consolidation affects revenue, cost, capacity and profitability.
* Use scenarios to compare structural options before committing to change.
Model Reef is not a property or HR transactional system. It helps you test structural options and their financial impact before implementation.
## When to use this pattern
Use this pattern when:
* You operate multiple campuses or locations.
* You deliver the same programs across different sites or delivery modes.
* You are considering closing, merging or opening campuses or programs.
* You want to understand the medium term financial impact and risk of structural change.
It builds on:
* Student Enrolment and Intake Forecasts
* Course or Program Profitability
* Teaching Staff Allocation Model
* Workspace Organisation
## Architecture overview
Campus and program consolidation modelling uses:
1. Branch and program structure
* Branches for campuses and academic units.
* Program and course variables under each branch.
2. Consolidation controls
* Branch toggles and enable or disable behaviour.
* Migration drivers for students and staff.
* One off closure, relocation or setup costs.
3. Financial and capacity outputs
* Revenue, cost and margin by campus and program.
* Combined capacity and utilisation.
* Cash, working capital and valuation impacts.
4. Scenario comparison
* Alternative consolidation and expansion plans.
* Sensitivity to enrolments, pricing and cost assumptions.
{% stepper %}
{% step %}
### Build a multi campus, multi program structure
Set up a group model where:
* Each campus is a branch, for example Campus A, Campus B, Online.
* Each program has its own revenue and cost variables under each campus where it is delivered.
* Central functions such as group management and shared services sit in separate branches.
Ensure that Student Enrolment, Teaching Staff and Program Profitability patterns are already implemented in this structure so that each campus and program has its own P\&L view.
{% endstep %}
{% step %}
### Add consolidation controls and toggles
Use the branch enable or disable capability and additional drivers to represent consolidation actions, for example:
* Campus A disabled from a future date to represent closure.
* Program X disabled at Campus B and enabled at Campus A to represent relocation.
* Online versions of programs enabled in new branches while physical delivery is reduced.
You can also create explicit control drivers such as:
* Active Campus Indicator per period.
* Delivery Share between campuses and online modes for each program.
These allow you to phase changes in over time rather than switching them instantly.
{% endstep %}
{% step %}
### Model student migration between campuses and programs
When you close or consolidate, you may migrate some students rather than losing them. In the Data Library, build drivers for:
* Proportion of enrolled students who transfer to another campus or mode.
* Proportion who withdraw or do not continue.
* Timing of migration across intakes and academic years.
Adjust Student Enrolment drivers so that:
* Intakes and cohorts at closing campuses reduce over time.
* Intakes at receiving campuses increase according to migration assumptions.
* Total enrolment reflects both migration and loss effects.
This lets you test how different migration strategies affect retention and revenue.
{% endstep %}
{% step %}
### Model staff, facility and overhead changes
Use Teaching Staff and overhead variables to represent:
* Staff leaving or being redeployed to other campuses.
* Changes in teaching loads and role structures.
* Closure or reduction of facilities and associated costs.
* New facility investment for expanded sites or online capability.
You can implement this by:
* Adjusting Staff variables by campus and program over time.
* Scaling down facility related Opex and Asset variables for closing sites.
* Adding one off closure costs or redundancy costs as Opex variables.
* Adding capex for new or expanded sites where needed.
This ensures that staff and facility changes flow through to P\&L, Balance Sheet and Cashflow.
{% endstep %}
{% step %}
### Include one off transition and restructuring items
Consolidation usually involves one off items such as:
* Redundancy payments.
* Lease exit costs or make good obligations.
* Consultancy, legal or project costs.
* Marketing and communication campaigns.
Create dedicated Opex and Cashflow variables for these items and schedule them in the periods when they are expected to occur. Keep them separate from ongoing operating costs to preserve clarity.
{% endstep %}
{% step %}
### Use scenarios for alternative consolidation and growth paths
Clone the base model into scenario models to explore options such as:
* Closing different combinations of campuses.
* Moving programs to different hubs.
* Investing more in online or hybrid delivery.
* Delaying or bringing forward consolidation dates.
* Combining consolidation with new program launches.
In each scenario, adjust:
* Campus and program enable or disable settings.
* Migration, intake and enrolment drivers.
* Staff and facility cost drivers.
* One off restructuring and capex items.
Compare scenarios using:
* Campus and program level P\&Ls.
* Group level margin and cash profiles.
* Capacity, utilisation and headcount metrics.
* Valuation impacts over the planning horizon.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
### Check your work
* Campus and program structures reflect your current operating model before changes.
* Consolidation actions are phased in realistically rather than switched in a single period unless that reflects reality.
* Student and staff migration assumptions are grounded in experience or reasoned estimates.
* Scenario outputs provide clear insight into trade offs across options.
{% endhint %}
## Troubleshooting
Consolidation creates implausible jumps in revenue or cost
Smooth transitions by phasing intakes, migration and staff changes over multiple periods rather than single step changes.
Difficult to see underlying ongoing performance after one off items
Use separate reporting views that strip out one off restructuring items and focus on steady state post consolidation economics.
Model is unwieldy with many small campuses or programs
Group minor campuses or programs into regional or program clusters and focus structural scenarios on material parts of the network.
## Related guides
* [Build an M\&A Consolidation Model](/how-tos/investment-and-transactions/build-an-m-and-a-consolidation-model)
* [Build an Equity Valuation Model (FCFE)](/how-tos/valuation/build-an-equity-valuation-model-fcfe)
* [Money Multiple Calculation](/help/financial-outputs-and-valuation/money-multiple-calculation)
* [Dropdown Field Behaviour](/syntax/how-input-fields-work/dropdown-field-behaviour)
# ๐งฉ Franchise Networks (Franchisors & Franchisees)
# Franchisee Unit P\&L Model
This use case explains how to build a franchisee unit P\&L model in Model Reef.
You will:
* Represent each franchise site or unit in the branch structure.
* Model site level revenue using volume, price and mix drivers.
* Model site level costs for staff, rent, marketing and supplies.
* Include royalties, marketing levies and network fees at unit level.
* Connect unit P\&Ls to network wide reporting and valuation.
Model Reef is not a point of sale or store back office system. It uses aggregated commercial and cost drivers to derive financial statements, cashflows and scenarios.
## When to use this pattern
Use this pattern when:
* You are a franchisor needing a standard unit economics model.
* You are a franchisee or advisor analysing individual site performance.
* You want to compare sites with consistent logic and input structures.
* You need a template that can scale to tens or hundreds of units.
It is a foundation for:
* Royalty and Fee Revenue Model
* Territory Rollout Planning
* Network Level Consolidated Reporting
* Build a Multi Division Model
## Architecture overview
Franchisee unit P\&L modelling uses:
* Structure
* Branches for each unit, store or territory.
* Parent branches for regions and the overall network.
* Revenue drivers
* Foot traffic, conversion and basket size.
* Average selling price and product mix.
* Seasonality and promotions.
* Cost drivers
* Staff rosters and wage assumptions.
* Rent and occupancy costs.
* Cost of goods, supplies and wastage.
* Local marketing and other operating expenses.
* Franchise related items
* Royalties as a percentage of sales.
* Marketing levies or co op funds.
* Fixed network fees or minimum royalties.
{% stepper %}
{% step %}
### Create branches for units and regions
In the branch tree, create a structure like:
* Network
* Region - North
* Unit - Store 001
* Unit - Store 002
* Region - South
* Unit - Store 010
* Unit - Store 011
Each Unit branch will hold that siteโs revenue and cost variables. Regions and the Network branch provide consolidated views.
You can also create scenario sets of the same structure for different operating models or pricing settings by duplicating models.
{% endstep %}
{% step %}
### Build unit level revenue drivers
For each unit, decide which revenue pattern fits best. Common patterns are:
* Volume based
* Transactions per day or week.
* Average transaction value.
* Seasonality factors by month or week.
* Capacity based
* Seats, rooms or service capacity.
* Utilisation and pricing per session or period.
Create drivers in the Data Library, for example:
* Foot Traffic per day.
* Conversion percentage.
* Average Items per Ticket.
* Average Selling Price.
Define unit Revenue variables such as:
* Revenue - Store 001 - Core Sales.
* Revenue - Store 001 - Add on Sales.
Use formulas such as:
* Revenue = Volume ร Price ร Seasonality.
Keep pricing and volume drivers central in the Data Library so changes can be pushed across multiple units where appropriate.
{% endstep %}
{% step %}
### Model unit level direct costs and staff
Create COGS and Staff variables for each unit, for example:
* COGS - Store 001 - Food and Beverage.
* Staff - Store 001 - Front of House.
* Staff - Store 001 - Back of House.
For COGS, you can use:
* Percentage of sales by category, or
* Unit cost per item multiplied by volume.
For Staff, define:
* Headcount per role.
* Wage rate and on costs.
* Roster pattern and timing.
* Payment delays to suppliers and staff.
These variables will populate site level gross margin and staff cost in the P\&L.
{% endstep %}
{% step %}
### Add rent, occupancy and local operating expenses
Create Opex variables for each unit, for example:
* Opex - Store 001 - Rent.
* Opex - Store 001 - Utilities.
* Opex - Store 001 - Local Marketing.
* Opex - Store 001 - Repairs and Maintenance.
For rent, you may have:
* Fixed monthly base rent.
* Percentage rent above a sales threshold.
* Scheduled rent increases.
For other costs, use drivers such as:
* Cost per square metre.
* Cost per unit of revenue.
* Known annual agreements spread over periods.
This gives each unit a full operating cost profile below gross margin.
{% endstep %}
{% step %}
### Include royalties, levies and franchise fees at unit level
At each unit, create Opex variables for franchisor related charges, such as:
* Opex - Store 001 - Royalty Fee.
* Opex - Store 001 - Marketing Levy.
* Opex - Store 001 - Fixed Franchise Service Fee.
Typically, royalties and levies are expressed as:
* Royalties = Royalty Percentage ร Eligible Sales.
* Marketing Levy = Levy Percentage ร Eligible Sales.
Where minimums apply, you can use formulas based on the greater of a fixed amount and a percentage applied to sales. If you want to keep pure arithmetic, approximate minimums via conservative percentages or separate adjustment variables.
These costs will appear in unit P\&L but represent income at the franchisor network level in separate branches or models.
{% endstep %}
{% step %}
### Connect units to network wide reporting
By placing unit branches under regional and network parents, Model Reef will automatically:
* Aggregate unit P\&Ls into regional and network P\&Ls.
* Roll up Balance Sheet and Cashflow contributions.
* Feed consolidated outputs into dashboards and valuation.
You can filter reports by:
* Unit.
* Region.
* Network total.
* Mature versus new stores.
* Company owned versus franchisee owned if you model both in the same structure.
This supports consistent performance measurement and benchmarking.
{% endstep %}
{% step %}
### Use scenarios for pricing, staffing and rent tests
Clone the base model to create scenario models for:
* Different pricing strategies.
* Changes in wage rates and rosters.
* New rent or lease terms.
* Alternative operating hours.
* Local marketing spend and promotion strategies.
In each scenario, adjust unit drivers and compare:
* Unit and network level EBITDA.
* Cashflow and payback for new units.
* Sensitivity of performance to key assumptions.
* Valuation impacts where relevant.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
### Check your work
* Unit revenue and cost patterns match historical data for sample sites.
* Rent, staffing, and royalty structures reflect franchise agreements.
* Aggregated network results reconcile with accounting reports for recent periods.
* Scenario results are intuitive for both franchisor and franchisee stakeholders.
{% endhint %}
## Troubleshooting
Unit P&Ls do not reconcile with accounting records
Check that all key cost categories are represented, that royalties and levies are not double counted, and that timing assumptions reflect real payment patterns.
Comparisons between units are noisy or hard to interpret
Standardise assumptions and categories across units, and use benchmarks such as margin and cost percentages rather than only absolute numbers.
Model becomes unwieldy with many units
Group smaller or similar units into representative branches for planning, and keep detailed per unit models only for large or strategic sites.
## Related guides
* [Operations & Unit Economics](/how-tos/operations-and-unit-economics)
* [Build an LBO Model](/how-tos/investment-and-transactions/build-an-lbo-model)
* [Naming (Branches)](/help/building-your-model/naming-branches)
* [Editing Bounds](/syntax/how-input-fields-work/editing-bounds)
# Royalty & Fee Revenue Model
This use case explains how to model royalties, marketing levies and franchise fees for franchisors in Model Reef.
You will:
* Link franchisee sales to royalty and fee revenue for the franchisor.
* Represent different royalty structures and marketing levy arrangements.
* Model minimums, fixed fees and tiered royalty rates where applicable.
* Connect royalty revenue to network P\&L, Cashflow and valuation.
Model Reef is not a billing or contract enforcement system. It models the economics of royalties and fees at planning level based on defined structures and assumptions.
## When to use this pattern
Use this pattern when:
* You are a franchisor with royalty based income.
* You charge marketing levies or service fees on franchisee sales.
* You want to understand network level revenue from royalties and fees.
* You need to simulate changes in commercial terms across the network.
It often sits on top of:
* Franchisee Unit P\&L Model
* Territory Rollout Planning
* Network Level Consolidated Reporting
## Architecture overview
{% stepper %}
{% step %}
### Source revenue
* Franchisee sales by unit, region and network.
* Eligible sales bases for different fee types.
{% endstep %}
{% step %}
### Royalty structures
* Percentage of sales.
* Tiered percentage rates by sales volume.
* Minimum royalty amounts.
{% endstep %}
{% step %}
### Marketing and service fees
* Marketing levies as a percentage of sales.
* Fixed or per unit service fees.
* Other recurring charges.
{% endstep %}
{% step %}
### Franchisor financial outputs
* Royalty and fee income in the franchisor P\&L.
* Cashflow timing from remittance behaviour.
* Network level valuation based on fee streams.
{% endstep %}
{% endstepper %}
***
## Define the relationship between franchisee and franchisor models
You can represent franchisee activity and franchisor royalties in either:
* A single Model Reef model where franchisee branches and franchisor branches coexist, or
* Separate models, where franchisee output is imported or approximated for the franchisor model.
In either case, identify the sales base for each unit or group of units that will drive royalties and fees.
***
## Drivers for royalty bases and percentages
In the franchisor model, create drivers for:
* Eligible Sales for Royalties per unit or per region.
* Royalty Percentage for each franchise agreement type.
* Tier thresholds and rates where tiered structures are used.
You can reference:
* Revenue variables from franchisee branches, or
* Imported sales data where you maintain franchisee models externally.
Define a Royalty Revenue variable such as:
* Revenue - Royalty Income - Region North.
Example formulas:
* Royalty Revenue = Eligible Sales ร Royalty Percentage.
For tiered structures, approximate by using weighted average percentages or piecewise applications via separate variables per tier if you want more precision.
***
## Model marketing levies and pooled funds
If you run network marketing funds, create additional Revenue variables such as:
* Revenue - Marketing Levy Income - Network.
Define drivers for:
* Levy Percentage on eligible sales.
* Any minimum or cap per unit where applied.
Compute:
* Marketing Levy Income = Eligible Sales ร Levy Percentage.
On the cost side, create Opex variables for spend from the marketing fund, either as:
* Direct marketing campaign spend by channel, or
* Allocations to regions or units if you want to track benefits by geography.
This lets you see whether levies and spend are approximately balanced or intentionally in surplus or deficit.
***
## Include fixed fees and other recurring income
Many networks also charge:
* Initial franchise fees.
* Ongoing fixed service or licence fees.
* Technology or system access fees.
* Training fees.
Create Revenue variables for each type, for example:
* Revenue - Initial Franchise Fees.
* Revenue - Ongoing Service Fees.
* Revenue - Technology Licence Fees.
Link them to drivers such as:
* Number of new units opened per period.
* Fee per unit per period.
* Upgrades or re fit fees every certain number of years.
These will be particularly important in Territory Rollout Planning.
***
## Model cash timing and compliance behaviour
Set delay and timing rules for royalty and fee cashflows, for example:
* Royalties remitted monthly in arrears.
* Levies remitted with the same cadence as royalty payments.
* Occasional late payment behaviour approximated via additional delays.
This will create:
* Receivables for unpaid royalties and fees.
* Cash inflows when payments are made.
* Cashflow sensitivity to payment behaviour.
You can use scenarios to approximate stress cases where some franchisees delay or default on payments.
***
## Use scenarios for commercial term and pricing changes
Clone the base model into scenario models to test:
* Royalty percentage increases or holiday periods.
* New or adjusted marketing levies.
* Introduction of new service fee structures.
* Differentiated terms for new franchisees compared to existing ones.
* Incentives for high performance units.
In each scenario, adjust:
* Royalty and levy percentages.
* Fixed fee levels and timing.
* Eligibility rules for different fee types.
* Payment timing and compliance assumptions.
Compare scenarios using:
* Franchisor revenue from royalties and fees.
* Network and unit level profitability.
* Cashflow and valuation metrics.
* Incentive alignment between franchisor and franchisees.
***
## Check your work
* Royalty and fee structures match actual franchise agreements.
* Sales bases used for calculations reconcile with franchisee P\&Ls.
* Timing of payments aligns with historical remittance patterns.
* Scenario changes are understandable to commercial and legal teams.
***
## Troubleshooting
Royalty income does not match historical actuals
Check that eligible sales match the definitions in the agreements and that percentages, minimums and caps are correctly implemented.
P&L shows fees in the wrong place
Ensure that royalty and fee revenue variables are mapped to appropriate categories and branches in the franchisor model, not left in franchisee branches.
Tiered structures are difficult to maintain
Use a small number of representative tiers and approximate complex schedules with weighted averages, then document any simplifications in notes.
***
## Related guides
* [Build an Opex Planning Model](/how-tos/operations-and-unit-economics/build-an-opex-planning-model)
* [Combine Multiple External Data Sources](/how-tos/data-workflows-and-automation/combine-multiple-external-data-sources)
* [Naming (Drivers)](/help/building-your-model/naming-drivers)
* [Editing Driver Time Series](/syntax/drivers-syntax/editing-driver-time-series)
# Territory Rollout Planning
This use case explains how to plan territory rollout, unit openings and network growth for franchise networks in Model Reef.
You will:
* Represent current and future territories and units in the branch structure.
* Build drivers for new unit openings, ramp up and maturity curves.
* Connect territory rollout to unit P\&Ls and franchisor royalty income.
* Use scenarios to compare alternative rollout and growth strategies.
Model Reef is not a GIS or site selection system. It models financial and timing impacts of rollout decisions, not site scoring or location analytics.
## When to use this pattern
Use this pattern when:
* You are planning expansion into new regions or territories.
* You want to test different rollout speeds and formats.
* You need to quantify the impact of rollout on network revenue, cost and cash.
* You need a structured way to compare expansion scenarios.
It depends on:
* Franchisee Unit P\&L Model
* Royalty and Fee Revenue Model
* Network Level Consolidated Reporting
## Architecture overview
Territory rollout planning uses:
1. Territory and unit structure
* Branches for territories, regions and units.
* Flags or drivers for current versus future territories.
2. Opening profile and ramp up
* Number of new units opened per period by territory.
* Ramp up curves for volume and margin as units mature.
* Unit closure or relocation assumptions where relevant.
3. Franchisor and franchisee economics
* Unit level P\&Ls for new stores.
* Royalty and fee revenue for the franchisor.
* One off fees and capex for openings.
4. Scenario analysis
* Different rollout speeds, territories and formats.
* Sensitivity to unit economics and success rates.
{% stepper %}
{% step %}
### Map territories and units into the branch tree
Set up a branch structure such as:
* Network
* Territory - Region A
* Unit - Store 001
* Unit - Store 002
* Territory - Region B
* Unit - Store 010 (planned)
* Unit - Store 011 (planned)
Include planned units as branches even before they open. Use timing and enable/disable controls to represent when they become active.
If relevant, distinguish between:
* Company owned units.
* Franchisee owned units.
You can represent them in separate sub-branches or via categories and flags.
{% endstep %}
{% step %}
### Create rollout and opening drivers
In the Data Library, define rollout drivers such as:
* Units Opened per Period by Territory.
* Earliest and latest opening dates for each planned unit.
* Probability or success rate of planned openings being executed.
You can use simple counts per period, or detailed lists of specific units with target opening dates.
These drivers will turn planned units into active revenue and cost generators when the model timeline passes their opening dates.
{% endstep %}
{% step %}
### Apply ramp up curves for new units
New units rarely perform at steady state from day one. For each unit or unit pattern, define:
* Ramp Up Period (for example 6, 12 or 24 months).
* Ramp Up Curve as a percentage of mature sales and margin per period.
* Stabilised or mature performance levels.
Implement this by:
* Defining a Ramp Factor series per unit or unit cohort.
* Multiplying mature revenue and cost levels by Ramp Factor in early periods.
You can represent cohorts of similar units instead of each unit individually, particularly when planning larger rollouts.
{% endstep %}
{% step %}
### Connect rollout to franchisee and franchisor economics
Using the Franchisee Unit P\&L Model, each new unit will:
* Generate its own revenue and cost profile as it ramps.
* Contribute to territory and network P\&L.
Using the Royalty and Fee Revenue Model, those same units will:
* Generate royalty and fee income for the franchisor.
* Contribute to marketing levies and service fees.
* Trigger initial franchise fees at opening.
Ensure that:
* New units reference the same driver sets as existing representative units, adjusted for local differences where needed.
* One off fees are tied to the opening schedule.
* Capex and fit out cost are captured in Asset and Cashflow variables at opening.
{% endstep %}
{% step %}
### Model capex, funding and working capital impacts
For each new unit or cohort, create Asset and Cashflow variables for:
* Fit out and equipment capex.
* Initial inventory or stock where relevant.
* Pre opening marketing.
Set timing so that:
* Capex occurs in the build period prior to opening.
* Funding assumptions (debt, equity or franchisee funding) are represented correctly.
* Any franchisor contributions or incentives are visible.
This allows you to see how rollout plans affect the networkโs cash position and funding needs.
{% endstep %}
{% step %}
### Use scenarios for alternative rollout strategies
Clone the base model into scenario models to test different rollout plans, for example:
* Faster versus slower rollout.
* Different territory order and sequencing.
* Larger format units versus smaller format or kiosk units.
* Company led versus franchisee led expansion.
* Different ramp up assumptions and success rates.
In each scenario, adjust:
* Units opened per period and per territory.
* Ramp up curves and mature unit assumptions.
* Capex and funding settings.
* Royalty and fee structures for new cohorts of franchisees.
Compare scenarios using:
* Network revenue and margin growth over time.
* Cashflow, funding requirements and headroom.
* Payback and valuation metrics.
* Sensitivity to unit economics and ramp up patterns.
{% endstep %}
{% endstepper %}
## Check your work
* Planned unit openings and timing align with your commercial plans.
* Ramp up and mature unit performance assumptions are grounded in historical performance and realistic expectations.
* Capex and working capital assumptions reflect actual experience.
* Scenario comparisons help decide which rollout paths are acceptable and which are too risky.
## Troubleshooting
Rollout plans produce unrealistic growth curves
Recalibrate ramp up curves and success rates and ensure that capacity and market size are considered in your volume drivers.
Cash requirements are higher than expected
Check timing of capex, franchise fees and royalties and confirm whether you have assumed franchisor funding where franchisees would typically fund their own fit out and working capital.
Model becomes complex with many planned units
Group units into cohorts by type and location instead of modelling every unit individually, especially beyond the near term horizon.
## Related guides
* [Scenarios & Planning](/how-tos/scenarios-and-planning)
* [Convert a PDF to a Structured Forecast](/how-tos/data-workflows-and-automation/convert-a-pdf-to-a-structured-forecast)
* [Naming (Variables)](/help/building-your-model/naming-variables)
* [Editing Frequency](/syntax/how-input-fields-work/editing-frequency)
# Network-Level Consolidated Reporting
This use case explains how to build network level consolidated reporting for franchisors and multi unit operators in Model Reef.
You will:
* Aggregate franchisee unit results into regional and network views.
* Combine franchisee unit economics and franchisor royalties and fees.
* Build dashboards and reports for network performance and valuation.
* Support decision making on rollout, pricing and structural changes.
Model Reef is not a replacement for statutory consolidation systems. It provides planning and management reporting views built from the same driver based models used for unit and franchisor economics.
## When to use this pattern
Use this pattern when:
* You operate or manage a multi unit or franchise network.
* You need a consistent network view across units, regions and formats.
* You want to integrate unit and franchisor financials in one place.
* You want a single framework to support planning, scenarios and valuation.
It depends on:
* Franchisee Unit P\&L Model
* Royalty and Fee Revenue Model
* Territory Rollout Planning
* Build a Consolidated Forecast Model
## Architecture overview
{% stepper %}
{% step %}
### Branch hierarchy
* Unit branches for each store or site.
* Regional branches aggregating units.
* Network branch aggregating all regions and franchisor entities.
{% endstep %}
{% step %}
### Entity and ownership structure
* Company owned units versus franchisee owned units.
* Franchisor entity with its own revenue and cost lines.
* Optional holding or investment entities.
{% endstep %}
{% step %}
### Reporting and dashboards
* P\&L, Balance Sheet, Cashflow and Cash Waterfall for the network.
* Segment views by region, brand, format or ownership.
* KPI dashboards for store, region and network performance.
{% endstep %}
{% step %}
### Scenario overlays
* Different rollout, pricing or commercial term strategies.
* Alternative ownership or capital structure models.
{% endstep %}
{% endstepper %}
## Steps to implement
{% stepper %}
{% step %}
### Confirm the branch structure for units, regions and franchisor
Ensure that:
* Each unit has a branch with its own variables.
* Units are grouped under regions, and regions under a Network parent.
* The franchisor entity has its own branch or set of branches for royalty and fee income and network level costs.
If you model company owned units in the same structure, differentiate them from franchised units using:
* Separate sub branches, or
* Categories and tags.
This hierarchy is the backbone of consolidation behaviour in Model Reef.
{% endstep %}
{% step %}
### Align category structures across units and entities
For consolidated reporting to be meaningful, all units and the franchisor should use consistent category and sub category structures for:
* Revenue.
* COGS.
* Staff.
* Opex.
* Assets and liabilities.
Review category mappings so that a given type of revenue or cost appears in the same report line across units and in the network.
This allows you to build:
* Clean stacked views by unit or region.
* Comparable margins and ratios.
* Roll ups that can be sliced by segment.
{% endstep %}
{% step %}
### Build standard network P\&L, Balance Sheet and Cashflow views
Use the reporting system to create:
* Network P\&L for the entire organisation.
* Regional P\&Ls filtered by branch.
* Unit P\&L templates for site level analysis.
* Network Cashflow and Cash Waterfall that aggregate all unit and franchisor cashflows.
Check that:
* Franchisee revenues are not double counted at the franchisor level unless you want to present gross network sales.
* Franchisor royalty and fee income is clearly separated from unit operating income.
* Intercompany or internal flows (such as technology fees between entities you own) are treated according to your reporting needs.
You can build both:
* Network sales views that show total franchisee revenue, and
* Franchisor entity views that show only franchisor level financials.
{% endstep %}
{% step %}
### Create dashboards for key network KPIs
Build dashboards that track:
* Sales, margin and EBITDA by region and network.
* Same store sales and like for like trends where data permits.
* Royalty income and marketing fund position.
* Store count, openings and closures over time.
* Cashflow, funding and headroom at network level.
Back these dashboards with:
* Filters for region, brand, format and ownership type.
* Scenario selectors so users can flip between planning cases.
* Drill down links from network and regional charts to unit level views.
This turns the consolidated model into a management cockpit for the network.
{% endstep %}
{% step %}
### Implement scenario based network reporting
Clone the base consolidated model into scenario models to explore:
* Different rollout or refurbishment plans.
* Pricing and royalty term changes.
* Wage and rent inflation scenarios.
* Different mixes of company owned and franchised units.
* Capital structure changes and financing strategies.
For each scenario, maintain the same branch and category structure so that:
* Network reports are directly comparable between scenarios.
* Dashboards can be switched between scenarios without reconfiguration.
* Valuation outputs are strictly comparable.
Use Multi Scenario reporting or side by side views to present key scenario differences to stakeholders.
{% endstep %}
{% step %}
### Use consolidated outputs for valuation and funding discussions
With the full network model in place, use the valuation engine to compute:
* FCFF and FCFE at network level.
* NPV, IRR and money multiple metrics under each scenario.
* Cashflow profiles for lenders and investors.
Combine this with:
* Debt schedules and covenant models where relevant.
* Equity injection or distribution strategies.
* Sensitivity analysis on key drivers such as sales growth, margins and royalty rates.
This supports funding, transaction and strategic planning work without needing separate spreadsheet models.
{% endstep %}
{% endstepper %}
## Check your work
* Network level P\&L, Balance Sheet and Cashflow reconcile with consolidated accounts for historical periods.
* Intercompany flows and franchisee to franchisor relationships are treated consistently.
* Scenario based reports use identical structures for clean comparison.
* Dashboards and reports tell a coherent story for management, investors and lenders.
## Troubleshooting
Consolidated numbers do not match statutory accounts
Confirm which entities and flows are included in the planning model, reconcile starting positions and ensure that internal flows are treated correctly for your reporting purpose.
Segment views are inconsistent across regions or units
Ensure consistent category mapping and variable naming conventions across all units and entities before relying on comparative views.
Model performance slows with many units
Use representative unit cohorts for long range planning and keep per unit detail for the near term and for the largest units.
## Related guides
* [Dashboards & Reporting](/how-tos/dashboards-and-reporting)
* [Core Modelling](/how-tos)
* [Net Income](/help/financial-outputs-and-valuation/net-income)
* [Editing Units](/syntax/how-input-fields-work/editing-units)
# ๐ฝ Hospitality Groups (Multi Venue)
# Venue-Level Forecasting Pack
This use case explains how to build a standardised venue level forecasting pack for hospitality groups that operate multiple restaurants, bars, cafes or venues.
You will:
* Represent each venue as its own branch with consistent variable structure.
* Build volume and pricing drivers for food, beverage and other revenue lines.
* Model venue level COGS, staff, rent and operating costs.
* Package the outputs into a repeatable pack you can use across all venues.
* Roll venue packs into group level views and scenarios.
Model Reef is not a POS or rostering system. It uses aggregated drivers, not individual transaction or shift level data.
## When to use this pattern
Use this pattern when:
* You run multiple venues and want a consistent forecasting framework.
* You need to compare venue performance using the same definitions.
* You want a pack you can hand to each venue manager to own and update.
* You want venue forecasts that roll into group reporting and valuation.
It is a foundation for:
* Group Level Consolidated Reporting
* Promotions and Margin Sensitivity
* Staff Rostering and Labour Planning
* Build a Multi Division Model
## Architecture overview
Venue level forecasting uses:
1. Structure
* Branches for each venue with a shared template.
* Parent branches for regions and the group.
2. Revenue drivers
* Covers, guests or transactions.
* Average spend per head by category.
* Day of week and seasonality patterns.
3. Cost drivers
* COGS percentages or recipe cost per item.
* Staff rosters and wage rates.
* Rent, utilities and other operating expenses.
4. Outputs
* Venue P\&L, Cashflow and key KPIs.
* Group level rollups across venues and regions.
***
{% stepper %}
{% step %}
### Create a standard venue template
Start by creating a single venue branch, for example `Venue - Template`, with variables for:
* Revenue - Food - Dine In.
* Revenue - Beverage - Dine In.
* Revenue - Takeaway or Delivery.
* COGS - Food.
* COGS - Beverage.
* Staff - Front of House.
* Staff - Back of House.
* Opex - Rent.
* Opex - Utilities.
* Opex - Local Marketing.
* Opex - Other Operating Costs.
Use this template to define the naming conventions and categories that every venue will use. Once you are happy with the template, duplicate the branch for each real venue and rename, for example `Venue - Site 001`, `Venue - Site 002`, and so on.
{% endstep %}
{% step %}
### Build demand and revenue drivers per venue
In the Data Library, set up drivers such as:
* Average Covers per Day by day of week.
* Average Spend per Cover for Food and Beverage.
* Split of sales between dine in, takeaway and delivery.
* Seasonality factors by month or week.
* Event or holiday uplift multipliers where relevant.
For each revenue variable, use formulas such as:
* Food Revenue = Covers ร Food Spend per Cover ร Seasonality.
* Beverage Revenue = Covers ร Beverage Spend per Cover ร Seasonality.
If you track separate day parts such as lunch and dinner, create separate driver sets for each and sum them for the day or week.
{% endstep %}
{% step %}
### Model COGS and gross margin
For each venue, define COGS drivers such as:
* Food COGS Percentage of Food Sales.
* Beverage COGS Percentage of Beverage Sales.
* Alternative recipe based costs where required.
Implement COGS variables like:
* COGS - Food = Food Revenue ร Food COGS Percentage.
* COGS - Beverage = Beverage Revenue ร Beverage COGS Percentage.
Where you want more precision, use recipe and menu costing in a separate driver table and map those costs into venue level COGS via average cost per menu mix.
{% endstep %}
{% step %}
### Add staff, rent and operating cost models
For each venue, create Staff variables for:
* Front of House staff.
* Back of House staff.
* Managers and supervisors.
* Other key roles.
Attach drivers for:
* Hours per week and hourly rates.
* Salary levels for salaried roles.
* On cost percentages for tax and benefits.
* Payment delays for cash timing.
For non staff costs, use Opex variables with drivers such as:
* Rent per period with scheduled increases.
* Utilities as a percentage of sales or based on historical patterns.
* Local marketing as a fixed amount or percentage of sales.
* Other operating costs with appropriate drivers.
This produces venue level EBITDA before any group wide overhead.
{% endstep %}
{% step %}
### Package the venue pack for repeated use
Create standard dashboards and reports for a single venue, for example:
* Venue level P\&L with key subtotals.
* Charts for revenue, gross margin and staff cost over time.
* KPIs such as sales per cover, gross margin percentage and staff cost percentage.
* Simple cashflow and headroom views if required.
Make sure that all charts and reports reference branches and categories that exist in every venue template. When you duplicate the template for each new venue, the same pack will work automatically, just focused on the selected venue branch.
{% endstep %}
{% step %}
### Use scenarios at venue level
You can treat each venue as a scenario by duplicating the whole model, or you can hold scenarios within a single group model by:
* Duplicating the group model for each funding or strategy case, or
* Using driver toggles for different scenarios and switching sets of assumptions.
For each venue, test scenarios such as:
* Price increases.
* Changes in opening hours.
* Staff and roster adjustments.
* Menu changes and mix shifts.
* New channels such as delivery or catering.
Compare venues and scenarios using the same standard pack so performance is interpreted consistently across the network.
{% endstep %}
{% endstepper %}
***
## Check your work
* Venue revenue and cost patterns reconcile with historical performance for a sample of sites.
* Staff, COGS and rent assumptions reflect actual contracts and practices.
* The template is general enough to apply across venues without customisation, or you have clearly documented where it differs.
* Group rollups from venue branches align with internal group management reports.
***
## Troubleshooting (expandable)
Venue results look inconsistent across similar sites
Check that driver assumptions are consistent for similar venues and that event or seasonality adjustments have been applied correctly.
The pack is too complex for venue managers to maintain
Simplify driver structures, hide non essential detail, and provide clear instructions for which inputs venue managers should update regularly.
Model performance slows with many venues
For long range planning, group smaller venues into representative cohorts and keep per venue detail for near term periods or key sites.
***
## Related guides
* [Valuation](/how-tos/valuation)
* [Build Cross Branch Drivers & Dependencies](/how-tos/data-workflows-and-automation/build-cross-branch-drivers-and-dependencies)
* [Non Current Liabilities](/help/financial-outputs-and-valuation/non-current-liabilities)
* [Entering Delays](/syntax/timing-syntax/entering-delays)
# Group-Level Consolidated Reporting
This use case explains how to build group level consolidated reporting across multiple venues for hospitality groups in Model Reef.
You will:
* Aggregate venue level P\&Ls into regional and group views.
* Combine venue results with any central or head office costs.
* Build dashboards and packs for group management and investors.
* Use scenarios to test portfolio and strategy changes.
Model Reef is not a statutory consolidation system. It is a planning and management reporting environment built on driver based venue models.
## When to use this pattern
Use this pattern when:
* You operate multiple venues, sites or brands.
* You want consistent group level reporting across the portfolio.
* You need to integrate site level plans, central costs and funding.
* You want scenario based group views for decisions and stakeholder communication.
It sits on top of:
* Venue Level Forecasting Pack
* Promotions and Margin Sensitivity
* Staff Rostering and Labour Planning
* Build a Consolidated Forecast Model
## Architecture overview
Group level reporting uses:
1. Branch hierarchy
* Venue branches for each site.
* Regional branches aggregating venues.
* Group branches for corporate and head office.
2. Category alignment
* Shared Revenue, COGS, Staff and Opex categories.
* Common KPIs and ratio definitions.
3. Consolidated reports and dashboards
* Group P\&L, Balance Sheet, Cashflow and Cash Waterfall.
* Regional and brand segment views.
* KPI dashboards for margins, staffing and cash.
4. Scenario overlays
* Alternative portfolios, pricing strategies and labour models.
* Expansion, refurbishment or closure plans.
{% stepper %}
{% step %}
### Confirm branch and category structures
Ensure that:
* Each venue is a branch with a consistent template of variables.
* Regions, brands or concepts have parent branches as appropriate.
* Head office functions have their own branches for central costs.
* All branches share common category structures for P\&L lines.
This enables Model Reef to roll venue results up to regions and then to the group while keeping consistent report layouts.
{% endstep %}
{% step %}
### Build core group P\&L, balance sheet and cashflow views
Use the reporting system to build:
* Group P\&L that aggregates all venues and head office.
* Regional P\&Ls by filtering reports to regional branches.
* Brand or concept P\&Ls where relevant.
* Group Cashflow and Cash Waterfall reflecting all venues, capex and funding.
Check that:
* Revenue and cost categories line up for meaningful comparisons.
* Head office costs are visible and separated from venue level costs.
* One off items such as refurbishments or closures are clearly flagged.
This provides a core set of group reports that all stakeholders can use.
{% endstep %}
{% step %}
### Create dashboards for group and segment KPIs
Build dashboards for:
* Revenue and EBITDA by region, brand and group.
* Gross margin, labour cost and rent cost percentages.
* Capex and refurbishment spend.
* Cash balance, headroom and key funding metrics.
For each dashboard:
* Use filters for region, brand and venue type.
* Allow users to switch scenarios.
* Provide drill down from group metrics to regional and venue level views.
This turns the multi venue model into a management cockpit for the group.
{% endstep %}
{% step %}
### Integrate central and shared costs
Add central cost branches for:
* Group management and administration.
* Marketing and brand support.
* Shared services such as HR, IT and finance.
* Property and lease management where centralised.
Decide how you want to present these in group reports:
* As central cost lines separate from venue performance.
* Allocated back to venues or regions using drivers such as sales, seats or staff count.
* Both, via alternative reporting views.
Implement allocation using driver based formulas so that allocations scale with portfolio changes in scenarios.
{% endstep %}
{% step %}
### Use scenarios for portfolio and strategy decisions
Clone the base model into scenario models to explore:
* Opening new venues in specific regions.
* Closing or refurbishing underperforming sites.
* Changing pricing, promotions or operating hours.
* Adjusting labour models or staffing targets.
* Changing rent structures or property strategies.
In each scenario, adjust:
* Venue level revenue and cost drivers.
* Central cost levels and allocation rules.
* Capex plans and funding assumptions.
Compare scenarios using:
* Group level EBITDA and margin profiles.
* Cash and funding requirements.
* Portfolio composition and performance by region and brand.
* Valuation metrics if you use the valuation engine for group level analysis.
{% endstep %}
{% endstepper %}
## Check your work
* Group level results reconcile with recent management accounts when historic drivers are applied.
* Segment views match internally recognised brand, region and venue groupings.
* Central costs are treated transparently and consistently.
* Scenario outputs support real decisions, not just additional complexity.
## Troubleshooting
Consolidated numbers differ from accounting reports
Reconcile starting balances, ensure all venues and central costs are represented, and confirm that any non trading items from statutory accounts are treated appropriately in the planning model.
Segment reports are hard to interpret
Simplify category structures, ensure naming is consistent, and create a small set of standard views for regular use.
Model performance slows with many venues
Use representative venue cohorts for long range planning and reserve detailed per venue forecasts for near term horizons.
## Related guides
* [Build a Board Reporting Pack](/how-tos/dashboards-and-reporting/build-a-board-reporting-pack)
* [Build a Consolidated Forecast Model](/how-tos/core-modelling/build-a-consolidated-forecast-model)
* [Notes & Comments](/help/permissions-and-collaboration/notes-and-comments)
* [Entering Schedules](/syntax/how-input-fields-work/entering-schedules)
---
[Next Page](/llms-full.txt/1)