Topic
The anatomy of the ILR
What is actually inside the Individualised Learner Record: the entities, how they nest, and which fields carry the funding.
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.
- Provider headerUKPRN and the funding year the file covers.(Data is created or changed)
- LearnerULN, learner reference number, demographics, home postcode.(Data is created or changed)
- Learner funding and monitoringEligibility and circumstance codes that apply to the person.(Data is created or changed)
- Employment statusEmployment circumstances, dated.(Data is created or changed)
- Learning deliveryAim reference, dates, funding model, aim type, completion and outcome.(Data is created or changed)
- Delivery funding and monitoringSource of funding, support, restart and monitoring codes.(Data is created or changed)
- Apprenticeship financial recordNegotiated price and payment records.(Data is created or changed)
- Destination and progressionWhat the learner did next.(Data is created or changed)
Read this diagram as text
The ILR has a provider header identifying the college by UKPRN. Inside it there is one record per learner, carrying their ULN and circumstances, with learner funding and monitoring records and employment status beneath. Inside each learner there is one learning delivery per aim, carrying the aim reference, dates, funding model and outcome, with learning delivery funding and monitoring records, apprenticeship financial records and destination records beneath.
The record is built in layers
The ILR is built like a set of boxes inside boxes.
The outer box is the college. Inside it there is one box per learner. Inside each learner there is one box per course or aim they are doing. Inside those there are smaller records holding extra detail.
- The college: identified by its UKPRN.
- The learner: who they are, including their ULN.
- The learning delivery: one per aim, with dates, funding model and outcome.
- The detail records: funding and monitoring codes, employment, financial records.
The hierarchy matters because an error high up affects everything beneath it. A learner with the wrong ULN affects every aim they are on. An aim with the wrong funding model is assessed against the wrong rulebook entirely.
The detail records are where most funding subtlety lives. They are small, easy to miss at enrolment, and rarely produce an obvious error when they are wrong: they simply change the money.
The ILR is structured hierarchically: a provider header, then one record per learner, and within each learner one record per learning delivery, with further entities for employment status, destination and outcome, learner funding and monitoring, and learning delivery funding and monitoring.
Funding and monitoring records, held at both learner and learning-delivery level, carry the eligibility, entitlement, support and monitoring information that the funding calculation and assurance reports depend on.
The structure is Header and Source, then Learner, then LearningDelivery, with child entities beneath each.
At learner level: LearnerFAM for funding and monitoring, LearnerEmploymentStatus for employment circumstances over time, LearnerHE where applicable, and provider-specified monitoring fields for the college's own use.
At learning delivery level: LearningDeliveryFAM for funding, eligibility, support and monitoring codes, AppFinRecord for apprenticeship financial detail, DPOutcome for destination and progression, and LearningDeliveryWorkPlacement where applicable.
Header → Source → Learner (LearnRefNumber, ULN, demographics) → LearningDelivery (LearnAimRef, dates, FundModel, AimType) with child entities including LearnerFAM, LearningDeliveryFAM, LearnerEmploymentStatus, DPOutcome and AppFinRecord.
Identity: the fields that say who this is
Two numbers identify a learner. The ULN follows them for life and across colleges. The learner reference number is your own number for them this year.
Getting either wrong causes problems that are hard to unpick later.
The ULN is the join key for everything cross-provider and cross-year: prior attainment, prior learning, activity at another college. A wrong or newly created ULN for someone who already has one splits their record permanently.
The learner reference number must be unique within your college for the funding year. Re-using it for a different person makes the return impossible to reconcile.
The Unique Learner Number identifies a learner across providers and across years, which is how prior attainment, prior learning and cross-provider activity can be recognised.
ULN is a ten-digit Learning Records Service identifier. It should be obtained or verified through the service at enrolment rather than created when a search fails to find an existing record quickly.
LearnRefNumber is provider-assigned, unique per provider per funding year, and is the key used to trace an ILR record back to the student record system.
Date of birth, name and postcode are used for matching as well as for eligibility and uplifts, so a transposed date of birth causes duplicate creation as well as a demographic error.
ULN is a ten-digit Learning Records Service identifier held on the Learner entity. It is the join key for cross-year and cross-provider matching, including in performance and funding-monitoring reports.
The aim: what is being delivered
Each thing a learner is studying is a learning delivery. It records what the aim is, when it started, when it was meant to finish, how it is funded, and how it ended.
Learners usually have several: one representing the whole programme, and others for the qualifications inside it.
Aim type is what distinguishes the programme aim from the components inside it. Getting aim type wrong changes how both funding and performance treat the record.
The dates are the part people most often get wrong. The planned end date is the intention at the start. The actual end date records what happened. They are different fields answering different questions, and the actual end date should only be set when the aim genuinely ends.
A learning delivery carries both a planned end date and, once the learner finishes or leaves, an actual end date. The planned date describes the intention at the start; the actual date records what happened.
Key fields: LearnAimRef identifying the aim on the learning aims database, AimType distinguishing programme from component, FundModel selecting the ruleset, LearnStartDate fixing the applicable funding year, LearnPlanEndDate, LearnActEndDate, CompStatus, Outcome and, on withdrawal, WithdrawReason.
LearnStartDate fixes which funding year's rules apply to the aim, which is why a single submission can contain aims governed by more than one year's rules.
FundModel on LearningDelivery selects the funding calculation. 25 is 16 to 19, 36 apprenticeships, 38 Adult Skills Fund, 11 tailored learning, 37 Skills Bootcamps, 99 non-funded. Legacy models continue only for aims that started under them.
LearnPlanEndDate is set at enrolment from the planned programme. LearnActEndDate is populated only when the aim completes or the learner withdraws, and drives the funding period, the completion status and the performance calculation.
The small codes that change the money
Alongside each learner and each aim there are small paired records: a type that says what kind of information this is, and a code that says which value applies.
They carry things like why a learner qualifies for free funding, whether they are receiving support, and who is paying.
They look trivial. They are where a lot of funding is decided.
These are the funding and monitoring records. Because they change the calculation rather than the validity of the record, a wrong one usually produces no validation error at all. You find it in a funding report, or you do not find it.
The source of funding is the most consequential of them for adult provision: it decides which authority the aim is claimed from and therefore which rules apply.
Funding and monitoring records, held at both learner and learning-delivery level, carry the eligibility, entitlement, support and monitoring information that the funding calculation and assurance reports depend on.
For adult skills provision, the learner's home postcode determines whether their funding is national or devolved to a combined or strategic authority, and therefore which rules apply.
LearnerFAM and LearningDeliveryFAM each pair a type with a code. Types cover areas including source of funding, eligibility, learning support, restart and learning delivery monitoring.
Valid types and codes are defined per funding year in the ILR specification, and additional constraints apply for devolved provision. Take the code list from the specification for the year rather than from an earlier year's configuration.
LearnerFAM and LearningDeliveryFAM pair a type with a code, covering areas such as eligibility, entitlement, learning support, restart and source of funding. Incorrect or missing values commonly change the calculated funding rather than producing a validation failure.
Worked examples
Worked example
Reading one learner's record end to end
An adult learner on a Level 2 qualification, funded from the Adult Skills Fund, living in a devolved area.
- Learner. ULN, learner reference number, date of birth, home postcode. The postcode decides which authority funds them.
- Learner monitoring. Records establishing the basis of eligibility, for example an entitlement or an employment-related condition.
- Learning delivery. Learning aim reference, start date, planned end date, funding model 38, aim type.
- Delivery monitoring. Source of funding identifying the devolved authority; learning support codes if support is being claimed.
- On completion. Actual end date, completion status, outcome, outcome date.
Every funding decision for that learner is visible in about a dozen fields, most of which are captured at enrolment.
A structural illustration. The exact codes and requirements come from the specification and the funding rules for the year.
Common pitfalls
Treating funding and monitoring codes as optional detail
What goes wrong: Codes are left blank or defaulted because they do not stop the record validating.
Consequence: Funding is calculated wrongly with no error to alert anyone, and the cause is invisible until a report or an audit finds it.
Prevention: Make the codes mandatory at enrolment where the funding depends on them, and reconcile them monthly against the claims being made.
Setting the actual end date at enrolment
What goes wrong: Some systems or processes populate the actual end date with the planned date up front.
Consequence: Aims appear to have ended when they have not, distorting funding and performance.
Prevention: The actual end date must only ever be set when the aim genuinely ends.
What this means for your role
MIS or ILR officer
Knowing which layer a field sits in tells you how far an error spreads.
- When investigating, work down the layers: college, learner, aim, detail records.
- Treat the funding and monitoring codes as first-class fields, not as optional extras.
Data, BI or performance analyst
The hierarchy is also the join structure for any analysis you build.
- Build analysis at learning delivery level and roll up, rather than starting at learner level.
- Keep the funding and monitoring codes in your extracts: they explain most unexpected funding.
See it play out
Scenario
A returning learner is enrolled as a new person
A learner returns after two years. The enrolment search does not find them, so a new record and a new ULN are created.
Work through itScenario
An adult learner is recorded under the wrong funding model
An aim has been recorded under a funding model that does not match the provision. Everything downstream is assessed against the wrong rulebook.
Work through itScenario
A learner starts three weeks after the class
A late joiner is enrolled with the class start date rather than their own. It looks tidier and it is wrong.
Work through itKnowledge check
Knowledge check
The anatomy of the ILR
4 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.