Model Structure Principles
This article explains how to design the overall structure of a Model Reef model before you start importing data or adding variables.
You will learn how to:
Decide what the model is for and what it should cover.
Choose the right branches and hierarchy.
Align period, currency and horizon with your use case.
Set up categories so that reports and dashboards stay clean.
Avoid common structure mistakes that are hard to fix later.
The goal is to make sure your model is clear, scalable and maintainable as it grows.
1. Start with the modelling objective
Before creating structure in Model Reef, write down a simple objective for the model, for example:
Single company three statement forecast.
Multi entity group consolidation.
Store level profitability and expansion planning.
Project finance and funding plan.
Investor or board reporting model.
This will influence:
How many branches you need.
How you name and group those branches.
What level of detail you actually care about.
Which imports (Xero, QuickBooks, PDF, Ticker) you should lean on.
If you are not sure, start small and add detail later rather than over engineering the first version.
2. Choose model level settings
When you create a model, you choose:
Currency
The reporting currency for the entire model.
All variables and reports are expressed in this currency.
There is no automatic multi currency consolidation.
Periodicity
Daily, weekly, monthly, quarterly, semi annual or annual.
This is the base frequency for calculations and timing.
You can later view outputs in higher level aggregations such as quarterly or annual, even if the base is monthly.
Start date and end date
Where the model timeline begins and ends.
How far back historical data should be aligned.
How far forward you want to forecast and value the business.
You can change these settings later and Model Reef will recompute the timeline, but it is still worth picking sensible defaults up front.
3. Design the branch structure
Branches are the backbone of a Model Reef structure. They represent:
Legal entities.
Divisions or business units.
Stores, clinics, venues or locations.
Projects or initiatives.
Any other unit you want a separate P&L, Balance Sheet and Cashflow view for.
At minimum, every model has a root branch (the consolidated total). Under that you can add child branches.
Design rules of thumb:
Use one branch per legal entity if you care about entity level reporting or tax.
Use child branches for divisions, channels or stores within each entity.
Avoid modelling every tiny cost centre as its own branch unless you really need that detail.
Keep branch names aligned with real world organisational names to reduce confusion.
You can always add more branches or rename them later, but it is much harder to simplify an overly complex tree once variables are attached everywhere.
4. Decide on your category scheme
Categories determine how variables roll up into:
P&L lines.
Balance Sheet sections.
Cashflow Statement and Cash Waterfall lines.
Dashboards and custom reports.
Good practice:
Define a small set of top level categories that matches how you present external reports.
Use sub categories for extra detail that matters to management or investors.
Keep names consistent across branches so consolidated reporting is clean.
Avoid creating a new category for every small expense. Use tags or descriptions instead.
You do not need to perfect this on day one, but a simple, consistent category scheme saves a lot of rework later.
5. Decide where imports will land
If you plan to import data, think through where it should land in your structure:
Xero or QuickBooks
Typically mapped into one branch per entity, with some accounts mapped to sub branches for divisions or stores.
PDF or Excel
Historical financials or operating metrics mapped into specific branches and categories.
Stock Ticker Fundamentals
Each listed company gets its own branch that can sit inside a group or portfolio.
Google Finance or Yahoo APIs
External series imported as drivers in the Data Library, then referenced in formulas for relevant branches.
Write down a simple mapping plan: which data source populates which branch and category.
6. Plan for scenarios and versions
In Model Reef, each scenario is a separate model. That means structure decisions should be made at the template or base model level, then cloned into scenarios.
If you expect to reuse the structure for multiple clients or entities, consider turning the model into a template once structure is stable.
7. Checklist before you start adding variables
Before you start importing or creating lots of variables, run through this checklist:
Once these are in place, you can safely start bringing in data and building drivers without constantly restructuring.
Related articles
Last updated
Was this helpful?