Topic
What validation does, and what it does not do
Validation checks that the data is internally consistent and conforms to the specification. It does not check that the data is true, that the learner was eligible, or that the funding is correct.
Enough detail to do the job and hold a sensible conversation with MIS or Finance.
- Official requirement: Stated by the official funding document named in the sources for this page.
- FEFunding explanation: Our plain-English explanation. Helpful, but the official document is the rule.
- Worked example: An illustration of how the rule applies in one situation. Not a universal rule.
- Recommended good practice: Operational advice from FEFunding. Not itself a funding requirement.
What validation actually checks
Validation is a published list of rules your file is tested against. Each rule checks one thing, like whether a date makes sense or whether a code is one of the allowed values.
A record that fails a rule may be rejected, which means it is not funded until you fix it.
Rules check structure and internal consistency: that required fields are present given the other values recorded, that dates are in a sensible order, that codes are valid for the funding year, that combinations that cannot coexist do not.
They cannot check anything they cannot see. Whether the learner actually attended, whether they were eligible, whether the hours were really delivered: none of that is visible to a rule.
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.
Passing validation means the data is internally consistent and structurally acceptable. It does not mean the data is true, that the learner is eligible, or that the funding claimed is correct.
Each rule has an identifier, a message and a defined field scope, and carries a severity determining whether a failure rejects the record or warns about it.
The rule set is published per funding year and can be reissued within a year. Check the published set for the year rather than assuming continuity, particularly in the first returns after rollover.
Validation runs both locally, through the Funding Information System, and on submission to the Submit Learner Data service. Each rule has an identifier, a severity and a defined field scope; failures appear in the validation error report.
A clean report is not a correct return
This is the most important thing to understand about validation, and it is the thing most often misunderstood.
A file with no validation errors can still be completely wrong. Validation checks the shape of the data. It does not check whether what the data says happened, happened.
A learner who left in October and has never been withdrawn produces a perfectly valid record. Every field is present, every date is consistent, every code is allowed. The record says the learner is in learning, and it is wrong.
This is why the monthly routine has to include checks that validation cannot do: learners in learning past their planned end date, aims ended with no outcome, claims without evidence.
Passing validation means the data is internally consistent and structurally acceptable. It does not mean the data is true, that the learner is eligible, or that the funding claimed is correct.
Validation tests conformance, not veracity. The assurance layer that tests veracity is the combination of your own data-quality reporting, the funding and monitoring reports, and audit.
Designing your monthly checks to cover what validation cannot see is the highest-value data-quality work available.
Passing validation means the data is internally consistent and structurally acceptable. It does not mean the data is true, that the learner is eligible, or that the funding claimed is correct.
Appearing on a data-quality or funding-monitoring report usually means a record has been flagged for investigation, not that it is confirmed wrong. Some flagged records are entirely correct and simply need evidence.
How to work a validation error report
Do not work down the list. Group the errors by rule, and fix the cause of the biggest group first.
- Group by rule identifier.
- Take the largest group first.
- Look at two or three records in it to find the single cause.
- Fix the cause in the source system.
- Regenerate, revalidate, confirm the group has gone.
A report with two hundred failures usually has four or five causes. Working record by record takes days and fixes nothing permanently; working by cause takes hours and stops the errors recurring.
Read the rule's own published wording before investigating. It usually identifies the cause immediately and saves an hour of guessing.
Export the report, pivot by rule identifier and by curriculum area. The intersection normally localises the cause to a cohort, an import or a configuration change.
Track the number of distinct causes resolved per period rather than the number of errors cleared: the first is a control measure, the second is activity.
Worked examples
Worked example
Two hundred errors, one cause
A validation run after the funding year rollover produces over two hundred failures of the same rule.
- Group. All failures are of one rule and all affect adult learners on one programme.
- Read the rule. The published wording identifies a code combination that is no longer valid for the new funding year.
- Find the cause. The programme template still carries last year's configuration.
- Fix the cause. Update the template in the student record system and re-apply it to the affected enrolments.
- Confirm. Regenerate and revalidate. The group is gone.
Two hours of work instead of two days, and the error does not recur next month.
An illustration of method. The specific rule and code will depend on your own configuration and funding year.
Common pitfalls
Ignoring warnings
What goes wrong: Only rejections are worked, and warnings are dismissed because the record still submits.
Consequence: Warnings exist because something looks unusual. Unusual and unchecked is precisely what an audit finds.
Prevention: Review warnings by rule each period and record the explanation for the ones that are legitimate.
What this means for your role
MIS or ILR officer
Validation is your first filter, not your quality assurance.
- Work the report by rule, not by record.
- Add the checks validation cannot do to your monthly routine.
Funding or compliance officer
A clean validation report tells you nothing about eligibility or evidence.
- Sample eligibility and evidence separately, on a cycle, regardless of the validation position.
See it play out
Knowledge check
Knowledge check
Validation
3 questions. Nothing is recorded unless you are signed in, and there is no time limit.
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.