A large number of validation errors appeared suddenly
This has been flagged because it is worth checking. It may be entirely correct. Investigate before assuming anything is wrong.
In plain English
Validation has produced a large number of failures that were not there before. A sudden change in volume almost always has one cause rather than many.
Why it matters
Records that fail validation may be excluded from funding, so a large volume of failures is a funding problem as well as a data problem, and it usually appears close to a deadline.
Funding
Records rejected at validation are not funded for that period. A large volume close to a deadline is a material funding risk.
Performance
Indirect: records missing from a return are missing from everything calculated from it.
Audit
A pattern of unresolved validation failures is treated as a control weakness and invites wider testing.
Most likely causes
Ranked, because in practice a few causes explain most cases.
- commonThe funding year rolled over and the new specification appliesCodes and combinations that were valid last year may not be valid this year. This is the classic cause in the first returns of a funding year.
- commonA system upgrade or configuration change altered how data is generatedCheck what changed in the student record system since the last successful return before investigating records.
- occasionalA bulk data change introduced the same error across many recordsA data import or a bulk update applied to a cohort produces a cohort-sized error.
- occasionalThe validation rule set itself was updated during the yearRule sets can be reissued within a funding year. Check the published rule set for the year before assuming your data changed.
Check these first
- Group the errors by rule. A large volume almost always resolves to a small number of rules.
- Check what changed since the last successful validation: the year, the software, the configuration, or the rule set.
- Check whether the affected records share a characteristic such as a cohort, a programme or an import.
- Check the severity: rejections are urgent, warnings need judgement.
How to investigate
- Never work a large error report record by record. Group by rule and fix causes.
- Establish the timeline: the last clean validation and everything that changed since.
- Look up the failing rule in the published rule set for the funding year. Its exact wording usually identifies the cause immediately.
- Where a system change is responsible, involve the supplier early rather than working around it.
In your system
These steps are system-neutral: they describe what has to be true in the data, which is the same whatever software your college runs. We do not publish supplier screen paths we have not verified, because menu locations differ by version and by local configuration, and a confidently wrong instruction is worse than none.
System-neutral
- Export the validation error report and group by rule identifier.
- Take the largest group first and examine two or three records from it in detail.
- Establish the single underlying cause for the group before touching any record.
- Fix the cause in the source system, regenerate, and revalidate to confirm the group has cleared.
- Repeat for the next largest group.
Building your own map of where each of these lives in your system is the most useful induction document an MIS team can have. How to build one.
How to fix it
- Correct the cause in the source system, not the symptoms in the file.
- Regenerate and revalidate to confirm the group has cleared before moving on.
- Where the volume cannot be cleared before the deadline, submit what validates and document the rest for the next return.
Stop this happening again
Fixing the record clears this case. A control is what stops the next one, so each of these names what to do, who owns it and how often.
Validate early in every collection window, so a systemic failure is found with time to fix it properly.
Review the published specification and validation rule changes before the start of each funding year.
Validate a test extract after any system upgrade, before the upgrade reaches a live return.
The rules behind this
An ILR file is validated against the published validation rules for the funding year. Records that fail a validation rule are rejected or excluded from funding until the underlying data is corrected.
Corrections should be made in the source system that owns the data, then regenerated into the ILR. Editing an ILR file directly leaves the source system wrong and the error returns at the next generation.
Sources
These are the official documents this page rests on. Where a figure, a deadline or an exact rule matters, the document is the authority and this page is the explanation.
Content reused from GOV.UK is Crown copyright, used under the Open Government Licence. FEFunding is not endorsed by the Department for Education.