How Often to Re-Forecast, and Why Most Teams Get It Wrong

The cadence question sounds procedural. It is not. How often to re-forecast determines whether the forecast is a decision tool or an artifact — something leadership steers by or something that gets rebuilt the week before each board meeting and ignored in between. Most teams default to a cadence inherited from whoever built the last model, then defend it as discipline. The defensible answer depends on two variables only: how volatile the business is, and how fast actuals land.

Everything else is noise.

The three cadences, and what they actually cost

Start with the honest accounting. A re-forecast is not free, and the cost is mostly analyst time plus leadership attention — two of the scarcest resources in a growth-stage finance org.

Quarterly. The light-touch option. One full reforecast per quarter, usually anchored to the board cycle. For a Series B team running a driver-based model, expect 15–25 analyst hours per cycle: pulling actuals, reconciling drivers, updating assumptions, packaging the variance walk. Leadership review is one or two meetings. The failure mode is obvious — a quarter is a long time to be wrong. A SaaS business that misses net revenue retention in month one of a quarter won't see it reflected in plan until month four.

Monthly. The default for most VC-backed companies. Roughly 20–40 analyst hours per month once you include the close dependency, plus a standing FP&A-to-leadership review. The math gets uncomfortable fast: if a two-person FP&A team spends 30 hours each on the monthly reforecast, that's the better part of two full weeks gone to model maintenance, every month, before anyone has answered a single strategic question.

Continuous / rolling weekly. The aspiration. Drivers update as actuals land; the forecast is never stale because it is never "done." Done well, the per-cycle cost drops because nothing is rebuilt from scratch — you're nudging assumptions, not reconstructing the model. Done badly, it is a treadmill that consumes the team and produces forecasts nobody trusts because they change too often to anchor a decision.

The over-forecasting trap

There is a real failure mode on the high-frequency end, and it gets too little attention. Teams that move to weekly reforecasting before their data infrastructure can support it end up forecasting off partial actuals, then revising every week as the rest of the numbers settle. The forecast oscillates. Leadership learns to discount it. The whole exercise inverts: instead of reducing uncertainty, frequent revision broadcasts it.

This is the cadence equivalent of measuring a system more often than it changes. The Federal Reserve doesn't re-estimate GDP daily, and not because it lacks the staff — re-estimating faster than the underlying signal moves adds noise, not information. The same logic governs a finance team. A business with smooth, predictable revenue and 45-day payment terms gains nothing from weekly reforecasts. A usage-based infrastructure company where revenue swings 20% on a single enterprise customer's consumption needs to see that movement in days, not at quarter-end.

Match the cadence to the volatility of the thing you're forecasting. McKinsey's work on agile planning makes the same point in different language: planning frequency should track the rate of change in the operating environment, not the calendar — an argument Deloitte echoes in its case for continuous, scenario-driven planning.

The constraint nobody names: close speed

Here is where most cadence debates collapse, because they skip the binding constraint. You cannot reforecast faster than your actuals arrive.

If your monthly close takes three weeks, your monthly reforecast is built on actuals that are already three weeks old on the day you publish it. By the time leadership reviews it, you're forecasting the back half of a month you can barely see. The cadence on the calendar says "monthly." The effective cadence — the rate at which fresh information enters the model — is far slower.

The data backs the severity. APQC's benchmarking research puts median monthly close at five to six business days, with bottom-quartile teams stretching past ten. Every one of those days is latency between reality and the forecast. A team closing in eight days and reforecasting monthly is, in practice, steering a growth-stage business off a picture of the world that's a third of a month stale before review even starts.

This is the quiet reason "monthly" satisfies almost no one. It's not that monthly is the wrong interval. It's that the actuals feeding it lag so far behind that the interval is theoretical.

Where live actuals change the math

The way out is not a faster close in the heroic sense — nobody fixes a ten-day close by working weekends. It's decoupling the forecast from the close entirely for the metrics that move fastest.

Revenue, billings, pipeline, headcount, cash position — these don't need to wait for a full reconciled close. They can flow from source systems continuously. When forecasting works off live actuals rather than a periodic static snapshot, the cadence question reframes itself: you stop reforecasting on a schedule and start reforecasting when something material moves. The model is always current because the inputs are always current, and the analyst hours shift from rebuilding to interpreting.

That shift also fixes the accuracy-versus-honesty tension that plagues frequent reforecasting. When the forecast updates from live data, a revision isn't an admission that last week's number was wrong — it's the system reflecting new reality. That distinction matters more than it sounds, as we argued in measuring forecast accuracy without punishing the team for honesty.

Tools have caught up to this. Anaplan and Pigment built around continuous planning; warehouse-native stacks like dbt feeding a planning layer achieve similar effect. A growing class of platforms now wire the forecast directly to live actuals rather than waiting on the close — worth a look if your effective cadence has quietly fallen behind your calendar one. →

The answer

Set cadence by volatility, then check it against close speed. If your business changes faster than your actuals arrive, the cadence problem is really a data problem — and no calendar discipline fixes it. The fuller treatment of how this fits into a modern planning rhythm lives in our pillar on rolling forecasts for high-growth finance teams and the broader operations coverage.

Most teams get cadence wrong because they argue about the interval. The interval was never the constraint.