Academy trusts now educate more than half of pupils in England, and the structure keeps consolidating: most trusts are still small, running between one and five schools, but the largest run dozens, with the biggest trust managing more than ninety. A trust is not a bigger school. It is a different organisation with central accountability for finance, safeguarding and standards across every school it runs, and a board personally answerable to the ESFA for the lot. Software built for one school does not become trust software by being installed five times. This guide sets out what a multi-academy trust actually needs from its systems, where single-school products fall short, and how the main options compare in 2026.
Speak to us about a trust system · +44 7494 618 651 · Mon to Fri, 9am to 6pm
The defining feature of a multi-academy trust is central accountability. A single legal entity, the trust, is responsible for the finances, the safeguarding, and the educational standards of every school under it. The board and the accounting officer answer to the Department for Education and the ESFA for the whole organisation, not school by school. That central responsibility creates needs a single school never has: the trust has to see across its schools, report as one body, and move resources between schools, all while still running each school's day-to-day operation.
The pressure is not abstract. Trust finances are under real strain: sector analysis of budget forecasts has projected that more than a third of trusts could fall below five per cent revenue reserves within a few years. When margins are that tight, a board that cannot see its true position across every school in close to real time is governing partly blind. The software is not a back-office convenience; it is how the trust knows where it stands.
Five capabilities separate genuine trust software from a single-school product run multiple times.
The trust needs to see attendance, exclusions, behaviour and safeguarding flags rolled up across every school, and to drill from the trust-wide number into a single school, year group or pupil. Persistent absence across the trust, a spike in fixed-term exclusions at one school, the spread of SEN need, these should be one view, not a spreadsheet assembled from each school's separate export.
Trust finance is governed by the Academy Trust Handbook and reported through statutory returns: the budget forecast return and the academies accounts return, consolidated across every academy. The finance system has to produce trust-level reporting and per-school detail from the same data, and support central allocation of funding where the trust pools its General Annual Grant. We go deeper on this in the academy finance software guide.
Trust staff are not always tied to one school. Central services, executive leaders, specialist teachers and cover staff may work across two or three sites, which a single-school HR record cannot represent cleanly. The trust needs employment records, DBS expiry tracking, and contracts that recognise a person can belong to the trust rather than only to a school.
A trust safeguarding lead needs assurance across every school: open cases, referral patterns, and gaps in the same view. This does not override each school's restricted, confidential DSL records; it sits above them, giving the trust the oversight it is accountable for without flattening the protections at school level. We cover the underlying record-keeping duty in the safeguarding software guide.
The point of a trust is that schools learn from each other. Comparing attendance, progress and spend between schools in the trust, on consistent measures, is how a trust identifies which school is getting something right and which needs support. That only works if the data is genuinely comparable, which means it has to come from a shared definition, not five systems each counting slightly differently.
Most MIS products were designed around one school. Run a trust on them and each school becomes a separate installation with its own data store. The trust-level view is then a reporting layer bolted on top, or worse, a monthly spreadsheet. Two specific problems recur. First, mixed estates: trusts grow by taking on schools that arrive on whatever MIS they were already using, so a trust ends up with two or three different products and no common data layer at all. Second, definitional drift: when each school records attendance or behaviour slightly differently, the trust-level totals are not truly comparable, which undermines the benchmarking that justifies the trust structure in the first place.
| Option | Trust dashboards | Central finance | Cross-school HR | Shared data layer |
|---|---|---|---|---|
| Arbor | Strong, cloud-native | Via Arbor Finance / partners | Add-on / partner | Within Arbor schools |
| Bromcom | Yes, MIS + finance | Built in | Module | Within Bromcom schools |
| Single-school MIS x N | Manual roll-up | Separate finance system | Per school | No |
| Bespoke trust platform (ESRE) | Built to the trust's model | Central + per-school from one source | Trust-level by design | Yes, one architecture |
For many trusts, standardising every school on Arbor or Bromcom is the pragmatic route to a consolidated view, and a sound one. The product carries the trust dashboards, and the trade-off is accepting the product's model of how a trust works.
A bespoke system from ESRE starts from the trust's own operating model rather than a product's, because it is built on the engage.re graph rather than configured inside someone else's MIS. Every school runs on one shared architecture, so the trust-level view is not a roll-up assembled from separate systems; it is the same data seen at trust scope. Central finance allocates and reports from the same source the schools spend against. Safeguarding oversight sits above confidential school-level records without breaking their restrictions. HR recognises that staff belong to the trust. And the benchmarking is genuinely like-for-like, because every school is counting the same way by construction, not because three products were forced to agree.
Two capabilities a standardised product cannot match come with the architecture. Every action across the trust is recorded automatically in an immutable, signed log, so the governance and financial audit trail the ESFA and auditors expect exists by design. And because every change to the trust's data is measured, the board can see, for the first time, whether what the trust does works: whether the school-improvement strategy moved outcomes at the school it was aimed at, and which efforts caused the change. That is efficacy across a whole trust, and no consolidation dashboard built over separate systems can produce it.
The decisive difference is that the trust owns the platform and keeps growing it. A growing trust adds a school, a new return, a new board report or an entire workflow as data in days. It does this in-house: every build comes with documentation precise enough for the trust's team, or an AI following it, to extend the system without us, rather than paying to standardise more schools onto a vendor's product year after year. The trust owns the code outright, on secure UK servers it controls, and ends the per-pupil renewal that scales with every school it takes on. The wider argument, and what a bespoke build covers, is on the School Management Software hub.
Everything a single school needs across every school, plus a consolidated layer: trust-wide attendance, exclusions and safeguarding visibility, central ESFA financial reporting, cross-school HR, and benchmarking. Single-school MIS products treat each school as a separate installation with no native roll-up.
Arbor is widely used across MATs, especially primary-heavy trusts, for its cloud-native trust dashboards. Bromcom is strong where secondary and attendance dominate and offers MIS and finance together. The right choice depends on the trust's phase mix and how closely it wants MIS and finance to share data. Trusts with workflows no product fits also consider a bespoke platform.
No, but mixed estates are harder to run. Different MIS products mean the trust cannot see one live picture without exporting and reconciling. Many trusts standardise on one MIS to get a consolidated view; a shared data architecture is what makes trust reporting immediate.
GAG pooling centralises the General Annual Grant for flexible allocation across academies. It raises the need for finance software that models funding at trust level, redistributes to schools, and still reports per academy. Trust finance platforms and bespoke systems handle central allocation and per-school reporting from the same data.
Speak to us about a trust system · +44 7494 618 651 · Mon to Fri, 9am to 6pm