Every planning estate eventually grows a five-year model. It usually starts as a spreadsheet owned by one person in corporate development, gets rebuilt every time the board asks a new question, and quietly diverges from the operating budget that finance actually runs. Meanwhile the annual plan in Anaplan is immaculate and stops at twelve months.
Long-range planning (LRP) is worth building properly in Anaplan for one reason: it is the only place where strategy, capital, and scenario arithmetic meet the same driver set the budget uses. And once the structure exists, bolting on acquisition and divestiture scenarios costs far less than most teams assume — an M&A case is just another set of driver overlays with its own timing.
This tutorial walks the build. It assumes you are comfortable with lists, subsets, time ranges, and versions, and that you already have an operating plan model producing a P&L by entity and cost centre.
Scope before structure
Write down the questions the model must answer before you create a single list. A workable LRP scope is narrow:
- What does the base business look like in years 1–5 if current drivers persist?
- What happens under named strategic initiatives (new region, new product line, pricing reset, footprint consolidation)?
- What happens if we acquire or divest a business, including deal timing, synergies, and financing?
- What does each case do to the metrics the board actually tracks — revenue CAGR, EBITDA margin, free cash flow, leverage, ROIC?
Anything that requires cost-centre-level detail belongs in the budget model, not here. The most common LRP failure is building at operating-plan granularity, producing a model nobody can flex in a meeting.
Step 1: Time, versions, and the seam with the budget
Create a dedicated time range for the LRP — for example LRP5, starting at the current fiscal year, five years, years only, no months. Monthly granularity across five years multiplies your cell count by twelve and buys nothing: nobody defends a month-37 seasonality assumption.
The seam with the operating plan matters more than the granularity. Pick one rule and document it:
- Year 1 = current forecast. The LRP inherits the live reforecast so the first year always ties to what finance is telling the board today.
- Years 2–5 = driver-derived. Nothing is typed as an absolute; every year is a growth, rate, or ratio applied to the prior year.
Import year 1 through a summary module (LRP01 Y1 Anchor) that pulls from the operating plan's total-year line items, mapped at entity and P&L line only. One anchor module, one direction of flow, no circularity.
For cases, resist the urge to use native versions for everything. Versions are a fixed, model-wide dimension and LRP cases multiply. Build a Cases list instead:
| Case | Purpose |
|---|---|
Base | Current trajectory, no new initiatives |
Strategic | Base plus approved initiative portfolio |
Upside / Downside | Macro flex on a small set of drivers |
M&A – Target A | Strategic plus a specific transaction |
Keep the list short and production-managed. A Case Properties module holding Include Initiatives?, Include M&A?, Macro Multiplier, and Board Case? booleans lets one calculation engine serve every case without duplicated logic.
Step 2: The driver tree
The heart of the model is a small driver module dimensioned by Entity × Driver × LRP5 × Cases. Use a Drivers list rather than line items when you want drivers to be reportable and comparable side by side:
Volume Growth %
Price / Mix %
Gross Margin %
Opex as % of Revenue
Headcount Productivity (Rev per FTE)
Capex as % of Revenue
Working Capital Days (DSO, DIO, DPO)
Tax Rate %
Calculation module LRP20 Base Financials then walks the P&L from those drivers:
Revenue = PREVIOUS(Revenue) * (1 + Volume Growth %) * (1 + Price / Mix %)
Gross Profit = Revenue * Gross Margin %
Opex = Revenue * Opex as % of Revenue
EBITDA = Gross Profit - Opex
For year 1, the PREVIOUS chain has to seed from the anchor rather than calculate:
Revenue = IF ISFIRSTOCCURRENCE(...) THEN 'LRP01 Y1 Anchor'.Revenue
ELSE PREVIOUS(Revenue) * (1 + Volume Growth %) * (1 + Price / Mix %)
In practice use a boolean Is Anchor Year? in a time-settings module rather than testing the period inline — it reads better and it is one place to change when the plan year rolls.
Two rules keep this maintainable. First, no hardcoded absolutes in years 2–5; if someone needs to type a number, it belongs in the initiative layer. Second, every driver has an owner and a source note — add a text line item for rationale, because the first question at the board meeting is always "where did 6% come from?"
Step 3: The initiative overlay
Strategic initiatives should never be baked into base drivers. Build them as an additive overlay so the base is always recoverable.
Create an Initiatives list (production-managed, with properties for owner, category, and status) and a module LRP30 Initiative Impacts dimensioned Initiatives × LRP5 × P&L Line:
Revenue UpliftCost ImpactCapex RequirementStart Year,Ramp Profile(Fast / Linear / Back-loaded)Approval Status(Proposed / Approved / Rejected)
A ramp profile applied through a lookup module — rather than typed year by year — is what lets a sponsor move an initiative's start year and see the whole case rebuild instantly. That single interaction is usually what sells the model to the executive team.
Then gate inclusion by case:
Included Uplift = IF 'Case Properties'.Include Initiatives?
AND Approval Status = "Approved"
THEN Revenue Uplift * Ramp Factor ELSE 0
Aggregate initiative impacts back to entity and P&L line in LRP35, and add them to the base in a LRP40 Combined P&L module. Keep Base, Initiative, and M&A as separate line items that sum to Total — the bridge between cases falls out for free, and you will never have to reverse-engineer a variance.
Step 4: Capital, cash, and the metrics that matter
An LRP that stops at EBITDA is a revenue model with ambitions. The board cares about cash and returns, so extend:
- Capex and depreciation. Capex from the driver tree plus initiative capex; depreciate on a simple straight-line vintage schedule (
Capex Year × Useful Life) rather than asset-level detail. - Working capital. DSO/DIO/DPO days converted to balances, with the year-on-year change flowing to cash.
- Financing. Opening debt, scheduled amortisation, revolver draw as the plug, interest on average balances. Avoid a full circular interest solve at LRP granularity — interest on opening balance, or a single-pass average, is accurate enough and does not require iteration.
- Returns. NOPAT, invested capital, ROIC, leverage (Net Debt / EBITDA), and free cash flow.
If you have already built a three-statement model in Anaplan, reuse its structure here at annual granularity rather than inventing a second cash engine.
Step 5: The M&A scenario layer
This is the part teams postpone and then rebuild under deadline pressure during live diligence. Build it once, generically.
Create a Transactions list and a module LRP50 Transaction Assumptions:
| Assumption | Notes |
|---|---|
Close Year | Drives partial-year inclusion |
Close Month Fraction | 0–1; year-of-close proration |
Type | Acquisition / Divestiture |
Purchase Price, Net Debt Assumed | Enterprise-to-equity bridge |
Funding Mix % (Cash / Debt / Equity) | Feeds the financing block |
Standalone Revenue, Standalone EBITDA | Target's own trajectory |
Cost Synergies, Revenue Synergies | With their own ramp profile |
Integration Costs | One-off, usually years 1–2 |
Goodwill, Intangible Amortisation | Purchase accounting effects |
Two modelling points do most of the work.
Proration. Year-of-close contribution is Standalone × Close Month Fraction. Divestitures are the mirror image: subtract Standalone × (1 − Close Month Fraction) in the close year and the full amount thereafter. Handle both signs in one formula driven by Type so you do not maintain two code paths.
Synergy phasing. Cost synergies almost never land at 100% in year one. Use the same ramp lookup you built for initiatives, with a conservative default (30/70/100) and integration costs front-loaded against them. Make synergy ramp a visible, editable assumption — it is the number that gets challenged hardest in the boardroom, and burying it is how models lose credibility.
Gate all of it on Case Properties.Include M&A? and a transaction-to-case mapping module so one case can carry several transactions (a roll-up strategy) without duplicating logic.
Step 6: Making it usable in the room
The build is only half the job. LRP models are used live, in front of executives, under questioning. Design the UX for that:
- A case comparison page: a card grid of headline metrics with a page selector for two cases, plus a waterfall from Base to Selected Case by driver of change.
- A driver page where all assumptions for the selected case are editable, with the rationale text visible beside each input — not hidden in a comment.
- A transaction page per deal showing sources-and-uses, accretion/dilution, and pro-forma leverage against covenant thresholds.
- Selective access and Dynamic Cell Access on the M&A layer. Live transactions are the most confidential data in the company; scope the
Transactionslist by role and make the page invisible to anyone outside the deal team. This is not optional.
Publish a Board Case flag and lock it once approved. If the case shown in the January deck cannot be reproduced in March, the model has failed regardless of how elegant the formulas are.
Performance notes
LRP models are small by Anaplan standards, and that is exactly why they degrade quietly — people bolt on dimensions because the cell counts look harmless:
- Do not dimension the driver tree by product or customer. If the strategy genuinely needs product-level detail, add a small
Strategic Segmentslist of ten to twenty items, not the operational product master. - Watch the Cases × Entity × Time cross-product. Cases proliferate; archive rejected ones out of the production list rather than leaving them live.
- Keep
PREVIOUSchains short. Five annual periods is fine. If you find yourself chainingPREVIOUSthrough sixty monthly periods for an LRP, revisit the granularity decision in Step 1. - Separate calculation from reporting. Thin reporting modules with only the metrics the pages need keep the board deck responsive when the CFO clicks through ten cases in a row.
A sensible build sequence
- Time range,
Caseslist, case properties, and the year-1 anchor from the operating plan. - Driver module and base P&L walk. Validate year 1 ties to the live forecast exactly.
- Cash, capex, working capital, financing, and the returns metrics.
- Initiative overlay with ramp profiles and approval gating.
- Transaction layer, proration, synergy phasing, purchase accounting, funding.
- UX pages, selective access on the deal layer, and the case comparison waterfall.
- A regression check: freeze the board case, re-run it next cycle, and confirm it reproduces.
Steps 1–3 take a competent model builder a couple of weeks. Steps 4–5 are where the value is, and they are impossible to retrofit cleanly onto a model built as a five-year spreadsheet port.
Where this usually goes wrong
The failure modes are consistent. Granularity creep turns a strategy tool into a slow second budget. Initiatives get baked into base drivers, so nobody can say what the business does without them. M&A cases get built ad hoc in a copy of the model during diligence and are never reconciled back. And the assumptions have no owners, so the model gets treated as an opinion rather than a plan.
Fix those four and the LRP stops being a once-a-year fire drill and becomes the model the board actually asks for by name.
If you are standing up long-range planning, scenario management, or transaction modelling in Anaplan — or you have an LRP model that has quietly turned into a spreadsheet with a login — get in touch. Our consultants build these end to end and hand them over with the documentation to keep them alive.