Rolling Forecasts on a Fixed Cadence, Not a Once-a-Year Guess

An annual budget is a forecast that stops updating the day it’s approved. By month eight, half of it is describing a world that no longer exists, and the team is either quietly ignoring it or rebuilding the whole model from scratch. A rolling forecast is the alternative: instead of one static plan for a fixed calendar year, the forecast moves forward every time a period closes, so there is always a live view a constant number of periods ahead.

What “rolling” means mechanically

Each time a period closes, two things happen at once. The actuals for that period get seeded forward into the model and locked; they become closed history, not editable anymore. And the as-of boundary that separates “known” from “projected” moves forward by one period, with a fresh forecast period appended at the far end. If you’re running a rolling twelve-month view, closing January doesn’t shrink your forecast to eleven months: it drops January off the front as actuals and adds a new month onto the back, so the horizon stays constant.

This is a different rhythm from a budget cycle. A budget is drafted, approved, and locked as a fixed target for a period. A rolling forecast never gets “done” in that sense; it’s a moving window that’s always current, sitting alongside the locked budget rather than replacing it.

Why the mechanics have to be boring

The interesting part of a rolling forecast isn’t the concept, which is simple. It’s whether the roll-forward is trustworthy enough that nobody has to double-check it every month. Two things matter here.

First, re-running the roll has to produce the same frozen numbers every time. A month-end close that gets re-processed (because someone re-ran the pipeline, or because a report needed regenerating) should not shift already-locked actuals by even a rounding error. If it can, “locked” doesn’t mean anything.

Second, closed-period actuals stay locked. Once a period has rolled from forecast into actual, that number is done. The carry-forward logic for the periods still ahead is deterministic and applies consistently across the whole rolling horizon: the same treatment for month two out as for month eleven out, not a different assumption depending on how far out you look.

What happens when the past changes

Financial data is not always final the first time it’s reported. A filing gets restated, a correction comes in late, a prior period gets revised. When that happens, the forecast needs to re-anchor to the corrected actuals, but without rewriting the sealed history that already existed before the restatement. The forecast picks up the new information going forward; it doesn’t retroactively pretend the old version was never there. That’s the same discipline behind Rexfin’s audit trail: the record of what was known and when doesn’t get erased just because better information arrived later.

Where this feeds

A rolling forecast is only as good as what it’s built on. The KPI and variance work that compares actuals against plan needs a forecast column that’s honest about which period it’s describing, not a stale annual number wearing the current month’s date. And because the roll-forward is deterministic, what-if scenarios run against the same current baseline instead of an assumption set that’s quietly gone stale since the last budget cycle.

Who this is for

Teams that forecast monthly or quarterly and are tired of the annual budget being irrelevant by mid-year, or of rebuilding a forecast model from scratch every cycle because nothing carries forward automatically. It’s for finance functions that want a forecast horizon that behaves the same way every single period, not one that depends on whoever happened to update the spreadsheet last.

To see a rolling forecast advance through a real period close and a restatement, book a demo. For the rest of how Rexfin’s planning tools connect, start at the product tour.