Academy trusts now educate more than half of pupils in England. The structure keeps growing larger. Most trusts are still small, with one to five schools. The largest run dozens, and the biggest manages more than ninety. A trust is not a bigger school. It is a different organisation. It holds central responsibility for finance, safeguarding and standards across every school. Its board answers personally to the ESFA for all of it. Software built for one school does not become trust software by being installed five times. This guide covers three things. What a trust needs from its systems. Where single-school products fall short. How the main options compare in 2026.
Connect with us about a trust system · · Replies within 24 hours
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 must see across its schools. It must report as one body. It must move resources between schools. It must do all of this while each school still runs its own day.
The pressure is not abstract. Trust finances are under real strain. Sector analysis of budget forecasts says more than a third of trusts could fall below five per cent revenue reserves within a few years. Margins that tight change what a board needs. A board that cannot see its true position across every school, close to the moment, 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 one view of attendance, exclusions, behaviour and safeguarding marks across every school. It must also move from the trust-wide number down to one school, one year group or one pupil. Persistent absence across the trust. A rise in fixed-term exclusions at one school. The spread of SEN need. These should be one view, and not a spreadsheet built from each school's own export.
The Academy Trust Handbook governs trust finance. You report through statutory returns. They are the budget forecast return and the academies accounts return, consolidated across every academy. The finance system must produce trust-level reporting and school-level detail from the same data. It must also support central funding allocation 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 and DBS expiry tracking. It also needs contracts that accept a person belonging to the trust, and not only to one school.
A trust safeguarding lead needs assurance across every school: open cases, referral patterns, and gaps in the same view. This does not override the restricted DSL records at each school. It sits above them. The trust gets the oversight it answers for, and the protections at school level stay in place. We cover the underlying record-keeping duty in the safeguarding software guide.
The point of a trust is that schools learn from each other. A trust compares attendance, progress and spending between its schools, on the same measures. That is how it finds which school is doing something right, and which needs support. That works only if the data is truly comparable. The figures must come from one shared definition. Five systems each counting differently will not do.
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. A trust grows by taking on schools, and each arrives on the MIS it already used. The trust then holds two or three different products, with no common data layer. Second, definitions that differ. Each school records attendance or behaviour in its own way. The trust totals are then not comparable, and the comparison that justifies the trust structure fails.
| 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.
Two problems in this article are the same problem. Mixed estates, and definitions that differ.
A trust can join two systems and still fail. The numbers arrive, and they mean different things. One school counts a late arrival as present, another as absent. The trust total is then a figure nobody should act on.
Adding a connection does not fix that. A connection moves a number, and it does not agree what the number means.
On engage.re every record type is declared in one shared dictionary, and the server refuses a write outside that declaration. Attendance therefore means one thing in every school in the trust. A comparison between schools is then sound, and a new school joins the definition rather than bringing its own.
We explain why a protocol alone does not solve this in MCP and A2A move messages. We compare the four ways to record meaning in semantic layer, ontology or knowledge graph.
A system from ESRE starts from the trust's own way of working, and not from a product. We build it on the engage.re graph, instead of configuring it inside somebody else's MIS. Every school runs on one shared foundation. The trust view is therefore not a total collected from separate systems. It is the same data, seen at trust level. 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. The system records every action across the trust in a signed log that nobody can alter. The governance and financial audit trail the ESFA and auditors expect therefore exists by design. The system also records every change to the trust's data. The board can then see whether what the trust does works. Did the school-improvement strategy move outcomes at the school it targeted? 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. The trust does this itself. Every build comes with documentation exact enough for the trust's team to extend the system without us. An AI can follow it too. The alternative is paying each year to move more schools onto a vendor's product. The trust owns the code outright, on secure UK servers it controls. It also ends the per-pupil renewal that grows 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. Then one layer above it. Trust-wide attendance, exclusions and safeguarding. Central ESFA financial reporting. HR across schools. Comparison between schools. 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.
Connect with us about a trust system · · Replies within 24 hours