Topic
From a learner walking in to funding arriving
The full chain: a learner event, the operational action it triggers, the source data it creates, the ILR fields it populates, validation, funding, reports, evidence, performance and audit.
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.
- Learner eventThe learner enrols, attends, pauses, leaves or achieves.(Something happens)
- Operational actionSomebody in curriculum, registry or admissions does something about it.(Somebody does something)
- Source dataA record is created or changed in the student record system.(Data is created or changed)
- ILR fieldsThe record becomes fields on the learner and the learning delivery.(Data is created or changed)
- ValidationThe file is checked against the published rules for the year.(A check or a rule)
- FundingEarnings are calculated across the whole year to date.(A result)
- ReportsFunding, data quality and monitoring reports are produced.(A result)
- EvidenceThe records that demonstrate it genuinely happened as recorded.(A check or a rule)
- PerformanceRetention and achievement measures are calculated from the same data.(A result)
- AuditA sample is tested back to the evidence.(A check or a rule)
Read this diagram as text
Something happens to a learner. Somebody takes an operational action in response. That action creates a record in the college's own system. The record becomes fields in the ILR. The ILR is validated. Funding is calculated from it. Reports are produced. Evidence is expected to support what was claimed. Performance measures are calculated from the same data. Finally, an audit tests whether the claim was earned and can be demonstrated.
The chain, end to end
Everything that happens to a learner turns into data, and that data turns into money, results and evidence.
The chain runs: something happens to the learner, somebody does something about it, that creates a record in the college's system, that becomes a field in the ILR, the ILR is checked, funding is calculated, reports are produced, evidence is expected, results are measured, and eventually somebody audits it.
Understanding the chain is what lets you work backwards from a symptom to a cause. A funding report that looks wrong is a symptom; the cause is almost always further up the chain, in an operational action that did or did not happen.
It also explains why fixing the ILR rarely fixes anything permanently. If the operational step is broken, the same error is regenerated next month.
The ILR is generated from the student record system. It is an output of the college's own data, which is why almost every ILR problem is really a problem in enrolment, curriculum or registry data.
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.
Learner event, operational action, source system record, ILR field, validation outcome, funding calculation, funding and monitoring reports, evidence expectation, performance measure, audit test.
Every diagnostic in this Academy maps to a position on that chain, which is why the correction is always specified at the source-system step rather than at the file step.
Generating the file
The ILR is produced by the college's own student record system. Nobody writes it by hand.
That means the file is only ever as good as what has been recorded in the system it comes from.
Generation is a point of failure in its own right: a record that exists in the system but does not appear in the file is usually caused by a missing value that the generation logic requires, not by an absent learner.
Compare counts between the system and the generated file each period. A silent drop of a group of records is far more common than people expect.
Generation produces an XML file conforming to the specification for the funding year. Records may be excluded where required elements cannot be produced, which is why a reconciliation of expected against generated record counts belongs in the monthly routine.
Editing the generated file directly is never the correction: the change is lost at the next generation and the source system remains wrong.
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.
Validating and submitting
Before submitting, the file is checked against a published set of rules. You can run that check yourself first, on your own machine, using the Funding Information System.
Then the file is uploaded to the Submit Learner Data service, which checks it again and produces reports showing what it earns.
Validating locally first is the difference between a calm return and a fraught one. It costs nothing, surfaces the same errors, and gives you time to fix causes rather than symptoms.
You can normally submit more than once within a collection window, and the last valid submission before the deadline is the one that counts. Submitting early is therefore a low-risk habit with a high payoff.
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.
The Funding Information System applies the published validation rule set for the funding year locally and produces funding reports without submitting. Submit Learner Data validates on upload and produces the validation error report and the funding reports for the period.
Work the validation error report grouped by rule identifier. A large report almost always resolves to a small number of underlying causes.
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.
What happens after submission
Once the return is in, the funding reports show what it earned. Finance reconciles those against the accounts.
The same data later becomes your published achievement rates, and it is the pool an auditor picks from.
The post-submission step that most colleges skip is keeping the reports. They are the record of what each submission earned, and they are what you will want when somebody asks why the position changed three months later.
Reconciling monthly, and writing down the explanation for any movement, is the single habit that prevents year-end surprises.
Each ILR return is a complete restatement of the funding year to date, not an increment. Every return replaces the last, which is why an error introduced late can change earnings already reported.
Retain the submitted file, the validation output and the funding reports together per period. That triple is the evidence of the position at each point in the year and answers most retrospective questions without re-derivation.
At the final return the same data becomes the qualification achievement rate input and the funding assurance sampling frame.
R14 is the final hard close for the funding year. Post-close, the year's earnings, the qualification achievement rate population and the audit sampling frame are drawn from the closed return.
The qualification achievement rate is calculated from the closed ILR return, forming a cohort of aims expected to complete in the year and measuring achievement against it. Completion status, outcome, dates and withdrawal recording all drive the result.
Worked examples
Worked example
A learner stops attending: the chain in full
A 16 to 19 student stops attending in the third week of November.
- Learner event. The student stops coming. Their last date of attendance is 21 November.
- Operational action. The tutor notices, the register shows the absence, and a leaver notification is raised.
- Source data. The withdrawal is recorded in the student record system with the actual last date of attendance.
- ILR fields. Actual end date, completion status and withdrawal reason are populated on the learning delivery.
- Validation. The record validates: the dates and status are internally consistent.
- Funding. Earnings for the aim stop at the actual end date and earlier periods are restated.
- Reports. The learner no longer appears on the in-learning reports.
- Evidence. The register supports the actual end date.
- Performance. The aim enters the achievement rate as a non-achievement.
- Audit. The record and the register agree, so the test passes.
Done promptly, the chain holds together at every step and there is nothing to correct later.
The funding effect depends on the stream and on whether a qualifying period applies.
Common pitfalls
Fixing the file instead of the system
What goes wrong: A correction is made to the generated file to get past a deadline.
Consequence: The error returns at the next generation, and the source system is still wrong.
Prevention: Correct in the source system, always, even when it is slower.
Validating for the first time on deadline day
What goes wrong: The first validation run of the period happens with hours to spare.
Consequence: A systemic failure cannot be properly fixed, so records are excluded or a workaround is applied.
Prevention: Validate early in the window. It costs nothing and buys the whole difference.
What this means for your role
MIS or ILR officer
Every problem has a position on the chain. Find the position and the fix is obvious.
- Validate locally early in every collection window.
- Keep the file, the validation output and the funding reports together for every period.
Enrolment, admissions or registry staff
The front door of the chain is enrolment. Most of the fields that matter are captured there.
- Capture identity, eligibility and evidence at enrolment rather than chasing them later.
Knowledge check
Knowledge check
The ILR lifecycle
2 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.