Parent/Child Behaviour

This article focuses on the behaviour of parent and child branches in Model Reef, beyond the basic hierarchy rules.

You will learn:

• How parent results are calculated from children.

• How to combine parent level and child level variables.

• How branch changes flow into consolidated outputs.

• How to sandbox changes inside child branches.

1

Parent branches as rollup views

A parent branch is primarily a rollup of:

• Its own variables.

• All variables in its child branches (and their descendants).

For example:

• Parent branch Retail has its own overhead variables.

• Child branches Store Sydney and Store Melbourne hold store level revenue and costs.

• The Retail branch P&L, Balance Sheet and Cashflow show:

  • Retail overheads (parent variables).

  • Plus the sum of Sydney and Melbourne (child variables).

This pattern lets you:

• Model detail where you need it (children).

• Keep a high level view at the parent level without duplicate work.

2

Combining parent and child variables

Parent and child branches can both hold variables of the same type and category. For example:

• Parent branch Group has corporate head office costs (Opex).

• Child branches Entity A and Entity B each have their own Opex.

In this case:

• Each child branch P&L shows only its own Opex.

• The parent shows head office Opex plus the sum of both entities.

• The root branch shows the final consolidated view.

You do not need to avoid overlapping categories. The branch location, not the category alone, determines where values roll up.

3

How changes propagate up the tree

Any change in a child branch automatically flows upwards to its ancestors. Examples:

• Adding a new revenue variable to Store Brisbane increases revenue for Store Brisbane, Retail, and the root branch.

• Changing timing or drivers for Project B changes cashflows for Project B, its parent entity, and the consolidated group.

• Disabling a branch removes its contribution from all parent branches.

There is no manual linking required. The branch tree defines the consolidation path.

4

Using children as sandboxes

Child branches are a good place to experiment with changes:

• Create a new child branch under an entity for a potential project or business line.

• Add variables and drivers to simulate its effect.

• Toggle the branch on or off to see impact on parent and root branches.

• When you are done, either keep the branch as part of the model or remove it if the scenario is not pursued.

This lets you use the existing structure as your base case while exploring structural changes in a contained way.

5

Parent behaviour and tax or valuation

Parent-child relationships also affect:

• Tax grouping

  • Depending on how you structure entities, you can treat certain branches as part of a shared tax group or keep tax separate by entity.

  • The parent entity view will reflect the combined tax position of its children.

• Valuation

  • Free cashflows at the parent entity level already include child branch contributions.

  • You can run valuation at any level of the tree, from individual projects to entire groups, by selecting the relevant branch.

Design your hierarchy to match how you want to think about tax and valuation units.

6

When to create an extra parent layer

Consider inserting an extra parent layer when:

• You want a group view that sits above several different country or entity branches.

• You want to group a set of projects or stores under a regional or segment parent.

• You want to report both at the entity level and at a cross-entity business line level (using separate branch trees or mirrored structures).

Adding a parent branch is usually cheaper than trying to retrofit cross-cutting logic with only categories.

---

Related articles

• Inventory Replenishment Cycles

• Build a Stress Test / Downside Case

• Branch Level Permissions

• Multi-Branch Driver Behaviour