Sign in

Blog · Data quality and reconciliation · Education

Multi-academy trusts and the contracting entity: getting the institution level right in education sales data

Why an education provider's coverage and renewal numbers depend on rolling schools, academies and legacy codes up to the entity that signs the contract, how to keep sites as a dimension underneath it, and the checks that catch a trust counted as ten small institutions.

The short answerRoll every school, academy and legacy code up to the entity that signs the contract, a trust, a district or a university, and keep the individual sites as a dimension beneath it. Coverage, renewal watch and programme fit are measured at the contracting entity, because that is where the decision is made; site-level detail explains it. A trust counted as ten separate institutions shows nine renewals nobody is working and a programme fit that is wrong at every one.

An education provider's CRM usually has an institution record for every school it has ever sold to, plus the trusts those schools joined, plus a set of legacy codes from the last system. The renewal watch built on that data shows ten small renewals where there is one trust-level decision, and programme fit measured against ten partial pictures of one customer. This guide sets out the entity roll-up that fixes both.

The principle

Measure at the contracting entity. Explain at the site.

Level Example Used for
Contracting entity Multi-academy trust, district, university Coverage, renewal watch, programme fit, revenue
Site Academy, school, campus, department Where the programme is used; contact detail

Revenue, renewals and contact are rolled up to the entity. Sites are kept as a dimension so the account manager can see that eight of the trust's twelve academies use the programme and four do not.

The rows you need

  • Institution master: every identifier the CRM holds, with its parent entity where known and its address.
  • Orders: institution or entity, programme, revenue, renewal date.
  • Contacts: institution or entity, date, type.

Institution identifiers only.

Building the hierarchy

  1. Parent mapping: every site identifier to its contracting entity. From the CRM's parent field where it exists; from public registers of trusts and districts where it does not.
  2. Legacy codes: mapped to the current identifier, dated.
  3. Probable duplicates: same address or postcode under different identifiers, listed for confirmation.
  4. Orders and contacts rolled up to the entity, with the site kept.

The assertions

invoiced revenue = Σ entities = Σ sites

And every site maps to exactly one entity. A site under two trusts, which happens when a school moves trust and the CRM keeps both, fails the second and is listed.

A worked example

Before the roll-up, one trust as the CRM held it.

Identifier Name Programmes Renewal Last contact
INS-2201 Oakfield Academy Core maths March 210 days
INS-2202 Oakfield Trust Core maths, English March 14 days
INS-2209 Riverside School Core maths March 400 days
INS-0887 Riverside Sch (legacy) English
… eight more

After: one entity, Oakfield Trust, twelve sites, three programmes, one March renewal worth £41,000, last contact fourteen days ago at the trust. The renewal watch drops nine phantom silent renewals. Programme fit is measured once, against the norm for trusts of that size, and shows the intervention programme missing at all twelve sites.

Where it goes wrong

Contact logged at the site. A conversation with the trust's procurement lead logged against one academy leaves eleven silent. Log at the entity, or roll contacts up.

Legacy codes not mapped. The old code's orders vanish from the entity's history and the renewal date with them.

Automatic merging. Two schools at one address are sometimes two schools. List probable duplicates; let a person confirm.

Trusts that devolve buying. If academies sign their own orders, the academy is the contracting entity for those. Record the signing level on the order.

Every term, at the right level

Mapped once, the institution master and the orders produce the entity roll-up, and the renewal watch and fit measures run at the level where decisions are made. Covirage builds this from the exports as they are. The education page describes the setup, and the programme fit guide covers the measures this hierarchy makes right.

Questions people ask

What is the contracting entity?

The organisation whose signature is on the order: a multi-academy trust in England, a school district in the United States, a university rather than a department, an employer rather than a training site. It is where the renewal decision is made and where contact should be logged.

What if a trust lets each academy buy separately?

Then each academy is a contracting entity for those programmes, and the trust is a parent above them for reporting. The hierarchy has three levels, and the roll-up handles it as long as the level at which each order was signed is recorded.

How do we find the duplicates?

Institutions with the same postcode or address under different identifiers, legacy codes from a migrated system, and academies whose name contains the trust's. The report lists probable duplicates for someone to confirm; it does not merge them automatically.