HESA season isn’t where your data goes wrong. It’s where you find out.

Every year, around the same time, a particular kind of tiredness settles over data teams across the sector. HESA season. The credibility reports, the quality rules, the fields that won’t reconcile, the evening someone loses trying to work out why the figures are forty students short. If you’ve lived through it, you know the exact flavour of it.

And every year, the story we tell ourselves is that the return is the hard part. It isn’t. The return is just where you find out how the rest of the year went.

Here is the uncomfortable truth about a HESA return. By the time you’re staring at a failing quality rule in the collection window, the mistake is already old. It was made months earlier, somewhere upstream, by someone who wasn’t thinking about HESA at all, and had no particular reason to be.

The mode of study coded wrong when the course was set up in a hurry. The field left blank at enrolment because the student record system didn’t insist on it, even though HESA does. The fix someone worked out last year that solved the problem beautifully and then never made it into the actual process, so here it is again. The record entered correctly according to everything the person could see, and incorrectly according to a coding definition they’d never been shown.

None of these are return problems. They’re everyday-running problems that the return simply drags into the light, all at once, under a deadline, months after the fact. Which is the worst possible moment to meet them.

Because by then, you’re not really fixing data. You’re doing forensic archaeology. You’re trying to reconstruct what should have been recorded in the first place, often about students who enrolled the better part of a year ago, sometimes with the help of a colleague who has since moved on, or who genuinely can’t remember why that cohort was set up the way it was. Every correction is slower, more uncertain and more expensive than it would have been at the point of entry, and you’re making them against the clock.

The move to more continuous, in-year collection has sharpened this rather than solved it. There’s less of a single calm window at the end in which to quietly put everything right. Problems surface more often, which is healthier in principle, but only if the data underneath is in decent shape to begin with. If it isn’t, you’ve just swapped one annual crisis for a rolling one.

And the stakes attached to this data have only gone up. The figures in your return don’t stop at HESA. They feed regulatory metrics, funding, the numbers that get quoted back to you in judgements about your provision. A field someone filled in without much thought, on an ordinary Tuesday in October, can end up shaping a picture of your institution that follows it around for years. The data travels a great deal further than the person entering it ever realises.

The shift that actually helps is to stop treating HESA as a season and start treating it as a by-product. A good return isn’t something you produce in the collection window. It’s something that falls out, almost quietly, of running your data well all year. The window is where you confirm that. It shouldn’t be where you achieve it.

In practice that means a few things, none of them dramatic.

When you fix something at return time, don’t stop at the fix. Trace it back to how it got in, and deal with that – the system setting, the process step, the bit of training nobody had – so you’re not paying the identical tax again next year. A correction that isn’t baked back into the process is just a problem you’ve agreed to keep having.

Move the expertise to where the data is created. The person setting up a course or enrolling a student is the one who decides whether the return will be clean, whether they know it or not. They need either to understand the coding implications of what they’re doing, or to be working in a system that quietly enforces them. Expecting the data team to catch everything at the end is asking them to inspect quality in after the fact, which has never really worked in any field.

Validate through the year, not just at the deadline. The best time to catch an error is while the person who made it is still there, still remembers the case, and the fix takes two minutes rather than two hours of investigation.

And someone needs to own this across the whole year, not just assemble the return at the end. Data quality is a standing responsibility, not a seasonal role.

None of this makes a HESA return exciting, and thank goodness for that. The thing I work towards with providers is a return that’s genuinely boring – one where the collection window is a formality, because the work was done steadily, months before, in the ordinary running of the place. For anyone who has lived through a bad HESA season, a boring one is about the most appealing thing I can offer.

The return was never the hard part. It’s just where the year catches up with you. The useful news is that where the year catches up with you is also where you get to decide, for next year, what it finds.