Planning Cloud Use Case

Rolling Forecasts in Planning Cloud — Configuration and Best Practices

Rolling forecasts represent a fundamental shift in how organizations approach financial planning. Rather than a single annual budget created each year, rolling forecasts maintain a continuous planning horizon—typically 12 to 18 months—that rolls forward as time progresses. This guide explains how to implement rolling forecasts in Oracle Planning Cloud and shares best practices from real implementations.

What Is a Rolling Forecast?

Rolling Forecast vs. Static Annual Budget

A static annual budget is created once per year and remains fixed for the entire fiscal year. For example, in January 2026, you create a detailed budget for all of 2026. This budget is reviewed quarterly against actuals but isn’t updated with new forecast periods as the year progresses.

A rolling forecast maintains a continuous planning window. As of April 2026, your planning horizon spans April 2026 through September 2027 (18 months out). In June 2026, the horizon rolls forward to June 2026 through December 2027. The planning window continuously shifts.

Visual Comparison

Static Budget:

Year 2026:  Jan  Feb  Mar  Apr  May  Jun  Jul  Aug  Sep  Oct  Nov  Dec
            |<------- Budget (created Jan 2026, fixed for 12 months)------>|

Rolling Forecast (18-month window):

April 2026:   Apr  May  Jun  Jul  Aug  Sep  Oct  Nov  Dec  Jan  Feb  Mar  Apr  May  Jun  Jul  Aug  Sep
              |<----------- Active Planning Window (18 months) --------->|

June 2026:    Jun  Jul  Aug  Sep  Oct  Nov  Dec  Jan  Feb  Mar  Apr  May  Jun  Jul  Aug  Sep  Oct  Nov
              |<----------- Active Planning Window (18 months) --------->|

Business Case for Rolling Forecasts

Agility

Rolling forecasts allow organizations to respond quickly to market changes. If demand drops unexpectedly in month 3, you can adjust forecast for months 4-18 immediately, rather than waiting for next year’s budget cycle.

Continuous Planning

Instead of intense budgeting activity in Q4 that consumes significant time, rolling forecasts distribute planning work across the year. Each month or quarter, you update the forecast as new actuals close and add new months to the horizon.

Predictive Advantage

By maintaining 18 months of forecast visibility, leadership has better insight into future trends and can make proactive investment decisions. A rolling forecast updated monthly is more likely to reflect current business conditions than a budget created 6+ months prior.

Reduced Budget Cycle Duration

Organizations typically reduce annual budget cycle time from 3+ months to 2-3 weeks when using rolling forecasts. Less time on process means more time for actual planning and analysis.

Better Variance Analysis

Monthly forecast-to-actual comparisons reveal whether your planning assumptions are accurate. If your Q2 forecast (made in Q1) doesn’t match Q2 actuals, you adjust Q3+ forecasts accordingly.

Implementing Rolling Forecasts in Planning Cloud

Step 1: Designing the Period Structure

Rolling forecasts require careful planning around your period dimension. You have two approaches:

Approach 1: Extended Period Dimension (Simplest)

Create a Period dimension that extends well into the future:

Period dimension members:
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec (current year)
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec (next year)
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec (year after)
Plus: Quarter1, Quarter2, Quarter3, Quarter4 (consolidated periods)
Plus: FY2026, FY2027, FY2028 (annual consolidated)
Plus: Total (all periods)

With this structure, as months pass and close, users naturally work with future periods. The “planning horizon” is simply which periods planners update in any given period—initially months 1-18 open for forecast, earlier months locked for actuals.

Advantages:

  • Simple structure
  • All periods pre-exist; no need to dynamically add periods
  • Easy to model multi-year scenarios

Disadvantages:

  • Dimension grows long with many future period members
  • Requires discipline to manage which periods are open vs. locked

Approach 2: Generic 18-Month Period Structure (More Sophisticated)

Create a Period dimension with generic, rolling periods:

Period dimension members:
M01, M02, M03, M04, M05, M06, M07, M08, M09, M10, M11, M12, M13, M14, M15, M16, M17, M18
Plus: Q1, Q2, Q3, Q4, Q5, Q6 (rolling quarters)
Plus: Total

Map each generic period to actual calendar periods using substitution variables that shift monthly. For example, M01 always represents “current month”, M02 represents “next month”, etc. A substitution variable maps M01 to Jan in April, Feb in May, and so forth.

Advantages:

  • Cleaner dimension structure
  • Explicit rolling mechanics via substitution variables
  • Easy to copy last year’s forecast structure

Disadvantages:

  • Requires substitution variable management
  • More complex form design to map generic periods to calendar periods

For this guide, we’ll focus on Approach 1 (extended periods) as it’s most common and easiest to implement initially.

Step 2: Configuring Substitution Variables for the Rolling Window

Substitution variables are key to rolling forecast automation. They allow you to dynamically reference periods that shift each month.

Key Substitution Variables

CurrentMonth: Represents the month you’re currently in

  • Definition: An alias that maps to “Apr” in April, “May” in May, etc.
  • Usage: Reference @CurrentMonth in forms or business rules to always target the current month

ForecastStartMonth: The first month of the forecast window

  • Definition: Usually 1-2 months ahead of current month
  • Usage: Forms can dynamically lock all periods before this month

ForecastEndMonth: The last month of the planning horizon

  • Definition: 18 months ahead of current month
  • Usage: Forms open periods from ForecastStartMonth to ForecastEndMonth for editing

How to Create Substitution Variables

In Planning Cloud, navigate to Substitution Variables and create:

Variable Name: CurrentMonth Type: Month Default Value: Apr (April, representing the current month at time of definition)

This variable is updated manually each month (April 1st → Apr, May 1st → May) or via EPM Automate command:

setSubVarValue -dim Period -memberName Apr -subVarName CurrentMonth

Automate this via scheduled job each month-end to shift the variable automatically.

Similarly, create:

  • ForecastStartMonth: Default to Jun (2 months ahead)
  • ForecastEndMonth: Default to Sep (18 months ahead)

Step 3: Form Design for Rolling Forecasts

Rolling forecast forms require special design to:

  1. Lock periods with actuals (past months) from editing
  2. Open forecast periods for user entry
  3. Show comparison data (prior year, budget)
  4. Provide visual cues about which periods are open

Form Layout Example

Columns: January through December (2 calendar years’ worth of months) Rows: Your accounts (revenue, expenses, etc.) Point of View: Entity, Scenario (Actual, Forecast), Version, Year

Cell-Level Formatting and Validation

For each cell, apply conditional formatting:

  • Actual data (past months): Background color gray, locked against editing, display only
  • Forecast data (future months): Background color white, editable
  • Transition period (current month): Background color light yellow, locked (actuals not yet closed), shows as forecast-ready
  • Beyond planning horizon: Background color light red, locked (too far in future for accurate planning)

Visual Guide for Users:

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug
[Gray=locked actuals] [Yellow=current] [White=forecast] [Red=beyond horizon]

Cell Validation Rules

Configure cell-level validation on forecast period cells:

Rule 1: Decimal Precision

  • Revenue entries must be to nearest dollar (no cents)
  • Headcount must be whole numbers (no partial employees)

Rule 2: Range Validation

  • Revenue cannot be negative
  • Expense percentages must be between 0% and 100%

Rule 3: Formula Validation

  • “Gross Margin % must equal (Revenue - COGS) / Revenue”
  • If a derived calculation is wrong, the form won’t submit

Right-Click Menus

Add context menu options:

  1. View Prior Year: Show the same account/month from prior year for comparison
  2. View Budget: Show the annual budget value (from last year’s annual budget process)
  3. Run Forecast Rule: Trigger the automated forecast seeding rule
  4. Submit Forecast: Confirm entry and lock the data
  5. Create Exception Report: Flag items outside normal ranges for review

Step 4: Business Rules for Rolling Forecasts

Rolling forecast automation relies on several business rules executed on a schedule.

Rule 1: Seed Forecast from Prior Year Actuals + Growth

When you open a new forecast period, seed it with prior year actual plus a growth rate.

// Seed forecast: PY Actual * (1 + Growth Rate)

try {
    def grid = Rule.getDataGrid("ForecastGrid")

    if (grid == null) {
        Rule.raiseException("ForecastGrid not found")
    }

    String sourceYear = "2025"
    String targetYear = "2026"
    String sourceScenario = "Actual"
    String targetScenario = "Forecast"

    // Fetch growth rate (could come from parameter, account, or variable)
    double growthRate = 0.03  // Default 3% growth

    def iterator = grid.getGridIterator()
    int seedCount = 0

    while (iterator.hasNext()) {
        iterator.next()

        // Get prior year actual
        double pyActual = grid.getCellValue(sourceYear, sourceScenario)

        if (pyActual <= 0) {
            iterator.skip()
            continue
        }

        // Calculate forecast as prior year + growth
        double forecast = pyActual * (1 + growthRate)

        // Write to target
        iterator.setValue(forecast)
        seedCount++
    }

    Rule.sendMessage("Seeded ${seedCount} forecast periods from prior year")

} catch (Exception ex) {
    Rule.raiseException("Seed forecast rule failed: ${ex.message}")
}

This rule is typically executed when you open a new month’s forecast (e.g., monthly on the 1st).

Rule 2: Copy Latest Actuals to Rolling Window

As actuals finalize (typically 5-10 days after month-end), copy them to the planning application.

This is typically handled via Data Exchange or Data Management, not a Groovy rule, but if you use Groovy:

// Copy finalized actuals to Planning

try {
    def grid = Rule.getDataGrid("ActualsGrid")

    if (grid == null) {
        Rule.raiseException("ActualsGrid not found")
    }

    String sourceScenario = "GL_Actual"
    String targetScenario = "Actual"

    def iterator = grid.getGridIterator()
    int copiedCells = 0

    while (iterator.hasNext()) {
        iterator.next()

        double glValue = iterator.getValue()

        if (glValue == 0 || glValue == null) {
            iterator.skip()
            continue
        }

        // Copy GL actual to Planning actual
        iterator.setValue(glValue)
        copiedCells++
    }

    Rule.sendMessage("Copied ${copiedCells} GL actuals to Planning")

} catch (Exception ex) {
    Rule.raiseException("Copy actuals rule failed: ${ex.message}")
}

Execute this rule immediately after GL close, typically on the 8th-10th of the following month.

Rule 3: Rolling Period Advancement

At the start of each month, advance the rolling window: close the oldest month in the forecast, open a new month 18 months ahead.

// Advance rolling window monthly

try {
    String closingMonth = "Apr"  // Month to lock (oldest in window)
    String openingMonth = "Sep"  // Month to open (newest in window)

    // Lock the closing month for actual data only
    List<String> accountsToLock = ["Revenue", "COGS", "OpEx"]  // Accounts to lock

    for (String account in accountsToLock) {
        // Set cell validation to read-only for closingMonth
        Rule.sendMessage("Locking forecast for ${closingMonth} ${account}")
    }

    // Open the opening month for forecast entry
    for (String account in accountsToLock) {
        Rule.sendMessage("Opening forecast for ${openingMonth} ${account}")
    }

    // Update substitution variables
    Rule.sendMessage("Rolling window advanced: closed ${closingMonth}, opened ${openingMonth}")

} catch (Exception ex) {
    Rule.raiseException("Period advancement rule failed: ${ex.message}")
}

Step 5: Sandboxing for What-If Scenarios

Rolling forecasts allow sandboxing: create hypothetical scenarios to test “what if” questions without affecting the main forecast.

Sandboxing approach:

  1. Designate one Scenario for “Main Forecast” (the active, approved forecast)
  2. Create additional scenarios for “Scenario_1”, “Scenario_2”, etc. (what-if sandboxes)
  3. Copy the main forecast to a sandbox scenario
  4. Users modify the sandbox (e.g., “what if revenue drops 20%?”)
  5. Analyze the impact without touching the main forecast
  6. If satisfied, promote the sandbox changes back to main, or discard

Form design for sandboxing:

  • Add a POV selection for Scenario
  • Color-code the scenario name (blue for main, orange for sandboxes)
  • Add variance columns showing sandbox vs. main

Step 6: Reporting on Rolling Forecasts

Rolling forecasts enable rich analytical reporting.

Variance to Plan

Compare rolling forecast to actual:

  • Variance: Forecast amount - Actual amount
  • Variance %: Variance / Actual
  • Trend: Compare variance this month to last month’s forecast-to-actual

Trend Analysis

Visualize how your forecast changes over time:

  • April forecast for June: $500K
  • May forecast for June: $480K (slight downward revision)
  • June actuals: $475K

This shows whether forecast accuracy is improving (forecast converging to actuals) or worsening (increasing variance).

Predictive Performance

Key metrics:

  • Forecast accuracy: How close was the forecast to actual?
  • Forecast drift: How much did you revise the forecast month-over-month?
  • Closure quality: How quickly does the forecast stabilize near the actual?

Use these metrics to evaluate forecast quality and identify areas for improvement.

Step 7: Predictive Planning Integration

Oracle’s Predictive Planning (machine learning-based forecasting) can seed rolling forecasts automatically.

How it works:

  1. Predictive Planning analyzes historical actuals (2-3 years of data)
  2. Uses time-series analysis and machine learning to forecast future periods
  3. Automatically populates the forecast with ML-generated values
  4. Planners review and adjust as needed

Benefits:

  • Reduces manual forecast entry time
  • Identifies seasonal patterns automatically
  • Generates baseline forecasts for new products (where historical data is limited)

Configuration:

  • Enable Predictive Planning integration in Planning Cloud settings
  • Map which accounts/dimensions should use ML forecasting
  • Set parameters (confidence level, seasonal adjustment factors)

Rolling Forecast Implementation Timeline

A typical rolling forecast implementation follows this timeline:

Month 1: Design Phase

  • Define rolling window length (12, 15, or 18 months)
  • Design period and scenario structure
  • Document substitution variable strategy
  • Design form layouts and validation rules

Month 2: Build Phase

  • Create dimensions and configure Planning Cloud application
  • Build forms with conditional formatting
  • Create and test business rules
  • Create substitution variables

Month 3: Pilot Phase

  • Roll out to finance team only (10-20 people)
  • Test monthly rolling mechanics
  • Gather feedback on form usability
  • Refine business rules based on actual usage

Month 4: Full Rollout

  • Expand to full planning community
  • Train all users on rolling forecast process
  • Establish governance (who updates when, approval workflows)
  • Monitor and optimize

Ongoing: Operations

  • Execute monthly rolling mechanics
  • Monitor forecast accuracy
  • Quarterly process reviews
  • Annual cycle for continuous improvement

Real Implementation Best Practices

Practice 1: Start Smaller Than You Think

Don’t try to forecast every account for 18 months in the first year. Start with:

  • 6-12 account categories
  • 12-month horizon
  • Quarterly roll cycles (instead of monthly)

Expand as the process matures.

Practice 2: Establish Clear Data Ownership

Assign each forecast area to an owner:

  • “John owns Revenue forecast for the Western region”
  • “Sarah owns Operating Expense for Corporate”

Clear ownership improves forecast quality and responsiveness.

Practice 3: Track Forecast Accuracy

Maintain a simple tracking mechanism:

  • Monthly: Record actual results
  • Compare to forecast from 3 months ago
  • Calculate variance as % of actual
  • Target: 80%+ accuracy within 10% variance

Use accuracy metrics to improve forecast methodology.

Practice 4: Version Before Rolling

Always version your forecast before advancing the rolling window:

  • “Version 1” = the initial forecast for a period
  • “Version 2” = the revised forecast 1 month later
  • Keep all versions for historical analysis

This history shows how assumptions evolved and whether revisions improved accuracy.

Practice 5: Create Exception Reports

Automatically flag anomalies:

  • Revenue growth > 15% month-over-month (likely data error)
  • Forecast variance > 20% from prior forecast (requires explanation)
  • Accounts with zero forecast but non-zero actuals (oversight)

Exception reports reduce manual review work and catch errors early.

Conclusion

Rolling forecasts shift organizations from backward-looking budgets to forward-looking, continuously updated forecasts. Oracle Planning Cloud provides the dimensional structure, forms, business rules, and substitution variables needed to implement rolling forecasts effectively.

The key to success is starting simply (6-12 accounts, 12-month horizon), establishing clear ownership, and tracking forecast accuracy. From there, you can expand sophistication gradually—add Predictive Planning, implement sandboxing, refine methodology—as the organization matures.

Rolling forecasts require discipline and process discipline, but the payoff is significant: more agile financial planning, better decision-making insight, and reduced budgeting cycle time.