Versions, Scenarios, and Time Ranges: Building an Anaplan Rolling Forecast That Doesn't Bloat

Ask ten Anaplan teams how they handle Actual, Budget, Forecast, and last year's plan, and you will get ten answers. Some use native Versions for everything. Some banned Versions on day one and use a scenario list. Most have a hybrid that nobody can explain, plus a Time range that quietly doubles the size of every module in the model.

This tutorial is about the three decisions that sit underneath every rolling forecast: how you use Versions, how you dimension scenarios, and how you set up Time. Get them right and a 12-month rolling forecast is a small, fast, boring part of your model. Get them wrong and you rebuild in eighteen months.

Native Versions: what they actually give you

A Version in Anaplan is a special dimension. Every module can either apply Versions or not, and Versions come with behaviour you cannot replicate with a plain list:

• Formula scope. A line item can calculate for All Versions, Current Version Only, or All Versions Except Actual — so actuals can be imported while forecast versions calculate from drivers, in the same line item.
• Switchover. Set a switchover date on a version and Anaplan reads Actual data up to that date and the version's own data after it. This is the single most useful native Version feature, and it is what makes a rolling forecast work without any IF logic on Time.
• Version formulas. Variance versions (Forecast - Budget, % of Budget) are defined once at the version level rather than as extra line items.
• Version settings. Each version has flags for whether it is the current version, whether it is read-only, and whether it is the actual version.

The cost is that Versions are a global model dimension. Adding one adds cells to every module that applies Versions, whether that module needs the version or not.

Scenario lists: what they give you instead

A scenario list is an ordinary list — Base, Upside, Downside, FX Shock — used as a dimension on the modules that need it.

• You add scenarios per module, so a scenario dimension on three driver modules does not inflate the other eighty.
• Business users can add scenarios if you make it a production list, so a new scenario does not need a builder or a release.
• You can hold many more of them without pain, because they are scoped.

What you lose: switchover, formula scope, version formulas, and the built-in version selector on UX pages. You rebuild what you need with a SYS module and boolean flags.

The decision rule

Use this split and most arguments disappear:

Use native Versions for	Use a scenario list for
Actual	What-if variations of a plan
Budget (the approved plan)	Sensitivity cases (FX, price, volume)
Forecast (the live rolling one)	User-created sandboxes
Prior Year / Prior Budget, if genuinely needed everywhere	Long-range planning cases
Variance versions computed by version formula	Anything only a handful of modules need

The test: does this thing need to exist in every module, or only in a few? Model-wide states of the plan are Versions. Variations on a plan are a list. Three or four native Versions is healthy. Twelve is a design smell — and if a version exists mainly so one team can play with numbers, it is a scenario, not a version.

Time settings before you build anything

Time in Anaplan is a model-level setting and it is expensive to change later. Three parts matter.

Calendar type. Calendar months, 4-4-5 (and its 4-5-4 / 5-4-4 siblings), weeks-general, or a custom calendar built from a list. Retail and manufacturing usually need 4-4-5; most finance models do not. Choose the calendar the business closes on, not the one that is convenient.

Model calendar span. Past years, current year, future years. Every extra year multiplies the time-dimensioned cell count across the whole model. Three years of history is usually enough inside the planning model; older actuals belong in the warehouse or a reporting model, not in the engine that recalculates every time a planner types.

Time ranges. This is the feature most teams under-use. A Time Range is a named subset of the model calendar — FY26 Only, Rolling 24M, Hist 3Y — that you apply to a module or a line item instead of the full calendar. A module that only needs the current year should never carry ten years of quarters, half-years, and years.

Model calendar : FY2023 .. FY2029   (monthly, with Quarter and Year totals)
TR_ACT36       : 36 months of history       -> DAT modules
TR_PLAN24      : current + next 12 months   -> INP and CAL modules
TR_FY          : current fiscal year only   -> OUT budget report
TR_LRP         : 5 years, Year summary only -> long-range plan modules

Also turn off the summary levels you do not use. If nobody reads half-years, disable them in the calendar settings — you have just deleted a whole aggregation layer from every time-dimensioned module.

Building the rolling forecast

Here is the pattern, end to end, for a rolling 12-month forecast that never needs a manual reset.

1. Versions

Create three: Actual, Budget, Forecast. Mark Actual as the actual version. Mark Forecast as the current version. Set Budget to read-only once it is approved.

2. Switchover on Forecast

Set the switchover date on Forecast to the last closed period. From that point on, Forecast shows actuals for closed months and calculated forecast for open ones, in the same line item, with no formula logic. At each close you move the switchover date forward by one month. That is the entire monthly maintenance of the rolling window.

3. A time SYS module

Build SYS00 Time Settings, dimensioned by Time only, applying no versions. It holds the booleans everything else reads:

Current Period?        Boolean   = ITEM(Time) = Current Period Item
Is Closed?             Boolean   = END(ITEM(Time)) < Current Period Start
Is Open Forecast?      Boolean   = NOT Is Closed? AND Months From Current <= 12
Months From Current    Number    = PERIOD(ITEM(Time)) - PERIOD(Current Period Item)
In Rolling Window?     Boolean   = Months From Current >= 0 AND Months From Current < 12

Drive the current period from a single input line item in a one-line-item module (SYS Model Settings), not from CURRENTPERIODSTART() scattered through formulas. One place to change, one place to check.

Now the rolling window is data, not structure. Every module that needs "the next twelve months" reads In Rolling Window? rather than hard-coding dates, and dashboards filter on it.

4. Lock what should not be typed

Use Dynamic Cell Access on your input modules with Is Open Forecast? as the write driver. Closed months become read-only automatically at close, and no one edits history by accident. Combine with a version-level read-only flag on Budget and your governance is structural rather than procedural.

5. Scenario dimension where — and only where — it is needed

Add a Scenario list (production list, so planners can create their own) to the driver input module and the calculation module that consumes it. Leave it off the actuals modules, the system modules, and the reporting modules that only ever show the committed case. If a report needs to compare scenarios, that report module carries the dimension; the other ninety do not.

Give every scenario a flag in SYS Scenario Properties for whether it is the committed case, and have the P&L output read the committed one by LOOKUP. Then "promote a scenario to the plan" is a single click, not a data copy.

Cell count: why this matters in numbers

A single module dimensioned by 5,000 products x 40 cost centers x 84 months, with 30 line items:

• With no versions and no scenarios: 504 million cells.
• Apply 4 versions: 2 billion.
• Add a 6-item scenario list on top: 12 billion.

Now apply a 24-month Time Range instead of 84 months, drop the scenario dimension from everything except the two modules that need it, and set summary methods to None on intermediate line items, and the same logic runs in a fraction of that. Versions and scenarios are multiplicative; Time Ranges and Applies To are how you divide back down. Our DISCO blueprint covers the module-level side of the same arithmetic, and the engine choice between Hyperblock and Polaris changes how much sparsity you can afford here.

Mistakes we keep finding

• A version per month. Forecast Jan, Forecast Feb, Forecast Mar... Twelve versions on every module in the model to keep forecast snapshots. Use one Forecast version plus a snapshot module dimensioned by a Forecast Vintage list, populated by a copy action at close.
• No switchover, so IF logic everywhere. IF Is Closed? THEN Actual ELSE Forecast repeated across two hundred line items. Switchover does this natively and costs nothing.
• Scenarios as versions. The fastest way to a model that cannot be opened. Scope them.
• Ten years of monthly history in the planning model. Keep three, and put the rest in a reporting model or the warehouse — see our modern data architecture guide.
• Hard-coded current period. IF ITEM(Time) >= Jan 26 THEN... in forty formulas. Every rollover becomes a release. Drive it from one line item.
• Time Ranges never used. The most common single cause of avoidable model size in models we review.
• Switchover moved by hand and forgotten. Put it in the close checklist alongside the actuals load, and confirm it in the smoke test — the same release discipline that governs structural change.

A ten-minute audit of your own model

1. List your versions. How many are genuinely model-wide states of the plan? Anything else is a scenario in disguise.
2. Open the model calendar. How many past and future years? Could reporting-only history live elsewhere?
3. Count your Time Ranges. Zero is a finding on its own.
4. Sort modules by size. For the top ten, ask whether they need Versions applied at all — many system and data modules do not.
5. Search formulas for hard-coded dates and month names.
6. Check whether closed periods are writable. If they are, you do not have a controlled forecast.
7. Check the switchover date on your forecast version. Is it last month?

Anything you find here is fixable, but the version and calendar decisions are the ones that get expensive with age. Fix them before the model gets bigger, not after.

Where we help

We run rolling-forecast redesigns, version and scenario rationalisation, and Time Range retrofits on models that have outgrown their original design — usually as part of Performance Optimization for Anaplan Models or Anaplan Model Designing and Building. If your monthly rollover involves more than moving one switchover date and loading actuals, get in touch and we will show you what it should look like.