I suspect issues may arise because providers have become increasingly dependent on HESA to generate what they consider ‘management information’, but relatively little is based on internally generated data (e.g. processing). It’s only return compilers who have to cobble that together into a ‘valid’ return, for HESA to enrich and provide to data customers, to populate their data warehouses and dashboards.

I suggested HESA share their derived data after introduction of the old Student Return in 2007/8, and ‘HESA Core Data’ has been provided since 2008/9. That made the Student Return an annual source of validated and enriched data for internal data customers, not just statutory ones. But it’s created a co-dependency and consensus among data customers to shift as much reporting burden as possible to the Student Return that produces enriched data for them — the conventional wisdom for a decade.

That’s why a reliable data return to a competent statistics agency that added value to data has bloated into an a perpetual funding return (orbiting around a model Session Year), with JISC as the new Designated Data Body. Designed to carry any new reporting burden data customers may have, where compilers must respond to every auto-generated query fired at them. The links in the article suggest this was all baked into HEDIIP’s vision for an auto-querying, multi-period return to carry everyone else’s reporting burden in 2016, and confirmed in OfS requirements in 2020 (Annex C: 3, 8. & 9.)