Naming & Structure (High Level)

This article gives practical rules for naming and structuring models in Model Reef so they stay readable as they grow.

You will learn how to:

• Name models, branches, variables and drivers.

• Keep structure aligned with how the business is actually run.

• Make models easy for other people to read and review.

• Avoid common naming and organisation pitfalls.

These are guidelines, not hard rules, but following them will make large models easier to live with.

1. Naming models

A model should be named so that someone else can tell what it is for without opening it.

Good patterns include:

• Company Name - Group Model - FY2025

• Client Name - SaaS Model - Base Case

• Fund I - Portfolio Forecast - Q3 2024

• Project Alpha - Project Finance Model

Avoid vague names like New Model, Copy of Model or Test once a model becomes important.

When you use scenarios, treat each scenario as a separate model and name them explicitly, for example:

• Company Name - Base Case

• Company Name - Downside Case

• Company Name - Upside Case

This keeps scenario comparisons clear in dashboards and reports.

2. Structuring branches to match how you manage the business

Branches should reflect how you think about the business operationally and how you report it.

Common branch patterns:

• By legal entity

  • Parent Group

    • Entity A

    • Entity B

• By division or business line

  • Group

    • Division - Retail

    • Division - Online

    • Division - Wholesale

• By geography

  • Group

    • Region - UK

    • Region - Europe

    • Region - US

• By store, site or project

  • Group

    • Store - Sydney

    • Store - Melbourne

    • Store - Brisbane

Pick a primary dimension that matches how you usually review performance. You can still use categories and naming to represent secondary dimensions.

Use clear, stable names. For example, prefer Store - Sydney over Store 1 so future readers know what that branch represents.

3. Naming variables

Variables should be named so that you can search and understand them quickly.

A simple pattern that works well is:

Type - Category - Qualifier

Examples:

• Revenue - Subscriptions - UK

• COGS - Hosting - Cloud Provider A

• Opex - Marketing - Paid Search

• Staff - Engineering - Salaries

• Asset - Plant - Line 1 Upgrade 2025

• Liability - Loan - Bank A Term Facility

Guidelines:

• Start with the variable type so that sorting and search group similar items.

• Use plain language for categories and qualifiers.

• Avoid cryptic abbreviations unless they are standard in your organisation.

• Use dates in names sparingly for one off items like specific capex.

If you inherit models from others, you can progressively rename variables as you touch them to improve clarity without changing behaviour.

4. Naming drivers

Drivers usually represent assumptions that may be shared across many variables. Make that intent clear in the name.

Patterns:

• Driver - Volume - Units Sold - UK

• Driver - Price - Subscription - Standard Plan

• Driver - Growth - Revenue - Base Case

• Driver - Wage Inflation

• Driver - FX - USD to GBP

Guidelines:

• Include Driver in the name or tag field so it is easy to spot in search.

• Make it clear what the driver is applied to (for example which region, plan or product).

• Distinguish between base case and scenario specific drivers if you keep them in the same model.

Because drivers live in the Data Library, good naming and tagging make it much easier to reuse existing assumptions rather than creating duplicates.

5. Categories and sub categories

Categories and sub categories control how variables show up in reports, not how they behave.

Use them to create clean layouts in P&L, Balance Sheet and Cashflow, for example:

• Revenue

  • Revenue - Subscriptions

  • Revenue - Services

• COGS

  • COGS - Direct Costs

• Opex

  • Opex - Marketing

  • Opex - Operations

  • Opex - G and A

Guidelines:

• Keep the category scheme consistent across branches.

• Avoid mixing fundamentally different items in one category.

• Do not use category as a substitute for branch or variable naming.

If you get categories right early, your standard reports and custom packs will be much easier to build and maintain.

6. Structuring for templates and reuse

If you expect to reuse model patterns across clients or business units, design structure with templates in mind:

• Use consistent branch layouts for similar businesses.

• Use the same variable naming patterns across models.

• Store reusable drivers (for example inflation, FX) in clearly named Data Library entries.

• Build standard dashboards and reports that assume a common structure.

This allows you to:

• Clone models or templates for new entities quickly.

• Compare performance across businesses more easily.

• Reduce onboarding time for new team members.

7. Avoiding common pitfalls

A few anti patterns to avoid:

• Using branches for everything Branches should represent meaningful organisational units, not every small dimension. Use categories, variable names and drivers for finer detail.

• Embedding meaning only in free text notes Notes are helpful, but try to capture primary meaning in names, branches and categories first.

• Overusing generic names Names like Revenue 1 or Cost A are hard to search and understand later. Be explicit.

• Letting naming drift over time Periodically tidy names and categories as the model evolves. Small cleanups prevent big refactors later.

8. Example: pulling it all together

For a multi store retail business, you might end up with:

• Model name: Retail Group - 3 Store Model - FY2025.

• Branches: Store - Sydney, Store - Melbourne, Store - Brisbane under Group.

• Variables:

  • Revenue - Retail Sales - Store Sydney

  • COGS - Merchandise - Store Sydney

  • Opex - Rent - Store Sydney

  • Staff - Store Team - Store Sydney

• Drivers:

  • Driver - Volume - Transactions - Store Sydney

  • Driver - Price - Average Basket - Store Sydney

The same pattern repeats for each store, making the model easy to read, extend and compare.

Where to go next

Once you are comfortable with naming and structure, continue with:

• Importing and Data Inputs to see how to populate a model from your existing files and systems.

• The Core Modelling how tos for step by step recipes.

• Workspace and Organisation if you plan to manage many models and templates.