Why Does the Mid-Year Reforecast Feel Like Starting the Budget Over Again?

In a spreadsheet-based process, five things tend to repeat:

1. The budget model was built to produce one approved number: so it has fixed values, a tab for each department and a frozen final version.
2. Actuals live somewhere else: and have to be exported from the finance system and brought in by hand.
3. Assumptions are typed in more than one place: so a change to enrolment or wages means finding every copy.
4. Contributors are asked for everything again: not only for what has changed.
5. The approved budget has to stay unchanged: so the reforecast becomes a second model beside the first.

Nearly every stage of the budget process comes back. The table shows what repeats, and what a light update would do instead:

Because it was designed for a different job. A budget model is built to reach an approved figure by a deadline, and once the Board approves it, the model's purpose is complete. Values get fixed, versions get locked, and the working logic becomes hard to reopen without risking the approved numbers.

That is a sensible way to protect an approved budget. It just means the reforecast has to be built next to it rather than from it, and that is where the duplicated effort comes from.

A reforecast combines what has already happened with a fresh view of what is left. Closed periods use actuals, the remaining periods use updated assumptions, and the approved budget stays unchanged beside it for comparison. Here is a simple example using four lines:

Only the second-half column needs fresh judgement. The first half is a fact, and the budget column doesn't change. When the model is set up this way, the reforecast is mostly a matter of updating what has moved.

Light reforecasts tend to share the same five features:

1. It uses the same model as the budget: rather than a copy that has to be maintained separately.
2. Actuals come in directly: for closed periods, so only the remaining months are forecast.
3. Assumptions live in one place: each with a source and a date, so a change is made once.
4. Contributors are asked only about what has changed: so most departments are not disturbed at all.
5. The approved budget stays visible beside the reforecast: so the comparison is always one click away.

You can reduce the rebuilding even before changing any tools. These steps help, and they are the thinking behind the readiness checklist at the end of this post:

1. Confirm which actuals are closed and reconciled: and state the cut-off date.
2. List the assumptions that have moved: enrolment, fees, wages and any one-off items.
3. Identify the departments with material changes: so you only contact the ones that matter.
4. Keep the approved budget untouched: as the baseline for every comparison.
5. Decide what the Executive and Board need to see: before you build the pages.

Imagine the model that produced the budget is still there, still live, and ready to be used again. Actuals for the closed months come in from the finance system. You change the wage assumption once and watch the full-year result update. Only the department heads with real changes get a request, and the Board sees the approved budget, the reforecast and the variance side by side.

That's what PULSE, Feoda's planning, budgeting, forecasting and reporting platform built for schools, is designed to support. The model used for the annual budget becomes the model used for the reforecast, rather than starting again. It works alongside the school's finance system, existing workbooks can be the starting point, and the finance team keeps control of the assumptions and the story.

The judgement in a good reforecast still comes from the people who know the school. The difference is that their time goes into that judgement, not into rebuilding a model they have already built once.