Reporting System for Multi-Academy Trusts & Schools

A multi-academy trust is a parent organisation with anywhere from two to sixty schools underneath it. Each school builds its own budget. The trust has to consolidate all of them, apply one set of assumptions across the group, and file a three-year forecast with the Department for Education that its trustees have formally approved.

The platform that does this work had been in service for over fifteen years. Our client asked us in as a development partner: not to rebuild it, but to take on feature work and architectural improvements on a system thousands of schools depend on to set their spending for the year ahead.

It is a forecasting tool, not a ledger. Actuals live in the trust's finance system and are pulled across so that plan can be tracked against spend. That distinction shaped everything we did. A wrong number here does not show up as a failed transaction. It shows up as a budget a trust cannot afford.

Staff in a trust often hold contracts at more than one school. A teacher on £30,000 at one academy and £30,000 at another is a single employee earning £60,000 across the group.

The system calculated employer National Insurance independently for each contract, as though the two were different people. Because employer NI is only charged above a secondary threshold, every duplicated contract silently granted that employee a second NI-free allowance. The error was not an approximation. It was exactly one threshold's worth of National Insurance, per extra contract, missing from the forecast.

Trusts share staff across sites as a matter of routine: part-time specialists, cover supervisors, central finance and HR. Every one of them carried the error, every year, with nothing in the system flagging it.

We aggregated contracts by employee number across every school in the trust, calculated the National Insurance once on the combined salary, then apportioned it back to each school by that school's share of the pay. A school carrying a third of someone's salary now carries a third of their National Insurance. The behaviour sits behind a per-employee toggle, so the extra lookup only runs where it is needed.

Every academy trust files a Budget Forecast Return with the Department for Education. It has to be approved by trustees before submission and it has a hard annual deadline. The platform generated it by populating an official template and handing back the spreadsheet.

Then the DfE changed that template. It now wanted the prior year alongside the current and forecast years, and the export could only produce the two it already knew about. The gap between what the tool could generate and what the regulator would accept had to close before the deadline.

Setting one assumption centrally and pushing it down to every school is the whole point of a trust-level budgeting tool. Applying an inflation uplift from the parent trust to its child schools was matching contracts on their type, a field with only two possible values: teacher or support.

A school with six distinct teacher contract types therefore had all six collapsed into one, and its existing rows deleted in the process. Our client had hidden the button from customers and was patching the database by hand.

We changed the identifier from the contract type to the contract name, so every row propagates intact, and added a reconciliation message naming any contract type the child school does not have. A mismatch now surfaces as a list to resolve rather than as silent data loss.

Schools were being moved off an old four-digit budget coding structure onto a new descriptive ledger structure. Until they moved, expenditure landed in the wrong place on their reports. In practice everything defaulted into fixed assets, with somebody picking it up by hand afterwards.

Because a wrong code is worse than a missing one, the remap validates every row against that school's financial reporting codes and rejects anything that does not match rather than guessing, flagging those rows for the support team to correct.

Budget setting is seasonal. A platform serving thousands of schools is quiet for months and then everybody arrives in the same fortnight, running scenarios across every school in their trust at once.

We began with a technical review to find where the architecture would give way, then reworked it to improve how container instances scale, which is what turns a spike from an outage into a busy afternoon. We integrated the K6 load testing suite into the staging environment so the next spike is something the team can rehearse rather than discover.

Getting to that point meant getting productive inside somebody else's fifteen-year-old finance platform. Environment setup took ten and a half hours, after which the first job was scoped on a call and scheduled within the week.

The work is ongoing. Our client's own user research reports half of finance leads saving at least an hour a week, 49% spending less time on data input and reconciliation, and trusts reporting up to a 30% reduction in budgeting workload from planning centrally rather than school by school.

Those are the platform's numbers, not ours. What we contribute is that the calculations underneath them are right, the statutory returns come out on time when the regulator moves the goalposts, and the trust-wide functions work without anyone touching the database.