Version 2

Specification of the Individualised Learner Record for 2022 to 2023

Updated:

29 June 2022 Summary of changes

Published:

29 June 2022

Overview

Purpose, audience and background

Purpose

To provide a technical specification of the data collection requirements and file format of the ILR to enable the intended audience to be able to meet the requirements for ILR data returns in 2022 to 2023.

Intended Audience

This is a technical document aimed at those responsible for:

• making data returns
• data specification implementation
• MI system design (including MI managers, commercial software suppliers and own software writers)

Background

This specification is produced to assist providers in collecting learner data for the 2022 to 2023 year.

In this specification we use the term ‘you’ or ‘providers’ to mean colleges, training organisations, local authorities and employers who receive funding from the Education and Skills Funding Agency (ESFA) or through a Loans facility or contract for apprenticeships, to deliver education and training. We will use the individual type of provider if the requirements apply only to that specific type of provider.

Summary of changes

A full list of changes to the 2022 to 2023 Specification

Changes can include:

• revisions
• removals
• new items

Use of ILR Data

The further education (FE) and skills sector in England uses the Individualised Learner Record (ILR) to collect data about learners in the sector and the learning undertaken by each of them.

The data collected in the ILR is used to ensure that public money distributed through the ESFA is being spent in line with government targets for quality and value for money, for planning, and to make the case for the sector in seeking further funding. Specifically, the data is used:

• to monitor at an individual level, all learning providers’ delivery against allocation or contract
• to inform local planning and provision
• to inform national planning, including policy development and modelling
• to calculate actual funding earned
• to monitor quality of provision and evaluate the effectiveness of providers across the learning and skills sector
• to make the case to government for levels of funding appropriate to the sector
• to monitor progress against government targets
• to demonstrate the outcomes of the distribution of government funds.

All changes to the ILR specification are approved by the DfE Data Governance Board.

Coverage of the ILR

You should send ILR data if you receive funding through one or more of the following funding models:

• 16-19 (excluding Apprenticeships)
• Adult skills
• Apprenticeships (from 1 May 2017)
• Community Learning
• European Social Funding (ESF)
• Other Adult
• Other 16-19

All providers must send records for learners financed by Advanced Learner Loans.

FE colleges must also send details of all learners who are not in receipt of public funding from the ESFA (apart from learners subcontracted in from a school or Higher Education Institution).

Training organisations are asked to send details of apprenticeships that are not funded by the ESFA where they are delivered within the terms of an ESFA contract. In all other cases, this data can be sent on a voluntary basis.

Higher Education Institutions (HEIs) who receive funding from the ESFA should return data about these learners in their Higher Education Statistics Agency (HESA) student record. For higher and degree level apprenticeships, HEIs must send an ILR return for all apprenticeship standards and for 16-18 apprenticeship frameworks. Please refer to the Provider Support Manual for further guidance.

An individual learner may, during the course of one teaching year, benefit from more than one type of funding. A single learner record must be returned for this learner detailing all of the learning aims that they are undertaking.

ILR Structure

This specification details the structure and individual field requirements for the ILR.

The ILR is based on a data model which defines the entities covered by the ILR and the relationship between these entities and is shown in Figure 1:

Figure 1. ILR entity relationship diagram

In this section the term ‘record’ refers to a group of elements that are based on an entity.

Learner Entity

You should return only one record for each learner. The data recorded in the learner entity contains basic information specific to the learner such as their name, date of birth, sex and ethnicity.

The following entities contain optional data that may not be required for all learners. See the individual field pages for details of when data is required:

• Prior Attainment - the learner's prior attainment when a new learning agreement has been agreed between the learner and the provider
• Contact Preference – indicates the learner’s wishes about contact for marketing, research and survey purposes
• LLDD and Health Problem – additional information about a learner’s disability and/or learning difficulty and/or health problem
• Learner Employment Status and Employment Status Monitoring – monitoring of a learner’s employment status
• Learner Funding and Monitoring – additional data to support funding and learner monitoring
• Learner Provider Specified Monitoring – additional provider data used as required and specified by the provider
• Learner HE and Learner HE Financial Support – Higher Education (HE) data fields.

Each learner record will be associated with one or more learning delivery records.

Learning Delivery Entity

A learning delivery record should be returned for each learning aim that a learner is studying. A learning delivery record contains information such as learning start and end dates, funding and outcome. In addition, for certain types of programme (as listed in the Programme type field), a learning delivery record is returned to describe the programme being followed. This is known as the ‘programme aim’. The programme aim contains information about the overall learning programme being followed. For example:

• Where a learner is studying three A levels, there would be three learning delivery records.
• Where a learner is studying a competency-based qualification and a functional skill there would be two learning delivery records.
• Where a learner is studying on an apprenticeship framework programme comprising a competency-based qualification, three functional skills and a knowledge-based qualification, there would be six learning delivery records one programme aim and five component learning aims.
• Where a learner is studying on a traineeship programme comprising work preparation, work placement, English and maths learning aims, there would be five learning aims – one programme aim and four component learning aims.

The following entities contain optional data that may not be required for all learners. Please see the individual field pages for details of when data is required:

• Learning Delivery Funding and Monitoring – additional data to support funding and learning delivery monitoring
• Learning Delivery Work Placement – additional data about work placements/work experience learning aims
• Apprenticeship Financial Record – additional data to support funding of apprenticeship standards through the Trailblazer funding model, and all apprenticeships (frameworks and standards) through Funding model 36
• Learning Delivery Provider Specified Monitoring – additional provider data used as required and specified by the provider
• Learning Delivery HE – HE data fields.

Learner Destination and Progression Entity

This entity records destination and progression outcomes for a learner, such as gaining employment or going onto further study. These outcomes will be reported after a learner has completed a programme of learning.

Destination and progression data to be reported in the year in which a learner completes their current programme of learning.

See the Learner Destination and Progression section for further information.

Programme Aims

A programme aim is required for the following programmes:

• Intermediate-level Apprenticeships, Advanced-level Apprenticeships and Higher Apprenticeships
• Apprenticeship standards
• Traineeships
• T-level and T-level transition programmes
• Adult skills
• Skills Bootcamps

A programme aim can be recorded for adult skills provision when combined authorities have responsibility for funding.

A programme aim is not recorded for a 16-19 (excluding Apprenticeships) funded study programme unless it is a traineeship or T-level.

Programme aims must be recorded using code 1 in the Aim type field.

The programme aim records the start date, planned end date, actual end date, completion and outcome data relating to the overall programme or framework.

Some of the learning delivery fields are recorded only on the programme aim (Aim Type 1) and are not required to be recorded on the component learning aims (Aim Type 3) and vice versa. If this is the case then it is described in the collection requirements on each individual field as detailed below.

Collection requirements

Aim	Funding stream
Aim Type 1	Adult Skills Traineeships (FundModel 35 and ProgType 24)
Aim Type 3 and 4	Other Adult (FundModel 81), Adult Skills (FundModel 35)

Additional guidance on the recording of programmes is published in the Provider Support Manual

Guidance on recording valid postcodes

Where the ILR Specification states ‘A valid postcode which must be in upper case’ this means the following;

• All postcodes on the ILR must be in upper case.

• A valid postcode is a combination of between five and seven letters/numbers. The postcodes are an abbreviated form of address.

• Full valid postcodes can be located at the Royal Mail Postcode Finder website

• Each postcode consists of two parts. The first part is the out-code. Separated by a single space from the second part, the in-code. For example: PO1 3AX

  • PO refers to the postcode area of Portsmouth.
  • PO1 refers to a postcode district within the postcode area of Portsmouth
  • PO1 3 refers to the postcode sector.
  • PO1 3AX. The last two letters define the ‘unit postcode’ this identifies one or more small user delivery points or an individual large user.

Guidance

The following is a list of the valid formats of postcode. An ‘A’ indicates an alphabetic character, and an ‘N’ indicates a numeric character.

Spacing

<space> represents a single space

<space><space> represents double spaces

Out-code	In-code	Example Postcode
AN	NAA	M1 <space> 1AA<space><space>
ANN	NAA	M60 <space> 1NW <space>
AAN	NAA	CR2 <space> 6XH <space>
AANN	NAA	DN55 <space> 1PT
ANA	NAA	W1P <space> 1HQ <space>
AANA	NAA	EC1A <space> 1BB

The following characters are never used in the inward part of the postcode: C I K M O V

All of the following postcode fields in the ILR are mandatory. If the postcode is unknown then a generic postcode of ZZ99 <space> 9ZZ must be returned.

• Current Postcode
• Postcode Prior to enrolment
• Delivery location postcode

Format of the ILR file

Figure 2. ILR structure

Filename

ILR files must be given a 36-character filename followed by the XML file extension. The filename format is as follows and is not case sensitive:

ILR-LLLLLLLL-YYYY-yyyymmdd-hhmmss-NN.XML where:

• ILR
• LLLLLLLL is the UK provider reference number (UKPRN)
• YYYY the year of collection (for example 2022 to 2023 would be 2223)
• yyyymmdd-hhmmss Date/time stamp from provider MIS on file generation
• NN The serial number of the file. The serial number element of the filename can be used (if required) to uniquely identify more than one ILR file for amalgamation purposes. For example, providers may have several ILR files for the same return relating to different geographical regions of operation or from providers with whom they subcontract. If the provider is only working with one ILR file, then the serial number element can be ignored and defaulted to 01.

Each element is separated by hyphens.

Format of data required

The format of data returned must conform to the XML schema documents.

Header Record

Each file must have a header record as defined below:

The header record is structured as follows:

    <Header>
        <CollectionDetails>
              <Collection>
              <Year>
              <FilePreparationDate>
        </CollectionDetails>
        <Source>
            <ProtectiveMarking>
            <UKPRN>
            <SoftwareSupplier>
            <SoftwarePackage>
            <Release>
            <SerialNo>
            <DateTime>
            <ReferenceData>
            <ComponentSetVersion>
        </Source>
    </Header>

Data	Description	Length	Data type	Mandatory field
<Collection>	ILR	3	RestrictedString	Y
<Year>	Year of collection	4	RestrictedString	Y
<FilePreparationDate>	Date of preparation of the file in yyyy-mm-dd format. The file preparation date is used in validation rules such as the ULN and Employer number checks	10	xs:date	Y
<ProtectiveMarking >	OFFICIAL-SENSITIVE-Personal	30	RestrictedString	Y
<UKPRN>	The UK provider reference number for the provider	8	xs:int	Y
<SoftwareSupplier>	Name of the provider’s software supplier. Providers who write their own software for producing ILR files should use ‘Own Software’	40	RestrictedString	N
<SoftwarePackage>	The name of the software product used to generate the ILR file	30	RestrictedString	N
<Release>	The version number of the software product used to generate the ILR file	20	RestrictedString	N
<SerialNo>	The serial number of the file. The serial number element of the header can be used (if required) to uniquely identify more than one ILR file for amalgamation purposes. For example, providers may have several ILR files for the same return relating to different geographical regions of operation or from providers with whom they subcontract. If the provider is only working with one ILR file, then the serial number element can be ignored and defaulted to 01	2	RestrictedString	Y
<DateTime>	Date/time stamp from provider MIS on file generation in yyyy-mm-ddThh:mm:ss format	10	xs:dateTime	Y
<ReferenceData>	Added by the Funding Information System (FIS) on export and not required from provider MIS. Gives details of versions of reference data such as LARS, EDS and LRS used	100	RestrictedString	N
<ComponentSetVersion>	Added by FIS on export and not required from provider MIS	20	RestrictedString	N

Source Files

ILR files that are created as a result of the amalgamation of separate files in the Funding Information System (FIS) also include a separate ‘Source Files’ section following the header that gives details of the originating files. This is described in the XML Schema. FIS creates this on export and it is not required in files supplied from a provider’s management information system (MIS).

Field Collection Requirements

Each field page details whether or not the data must be collected for learners and learning aims funded by a combination of funding models, and/or other characteristics. For example:

Collection requirements

• 16-19 (excluding Apprenticeships) (FundModel 25)
• Community Learning (FundModel 10)
• Non-funded (FundModel 99)
• Apprenticeship Standards (ProgType 25)

The funding agency recorded in the Source of funding field in the Learning Delivery Funding and Monitoring entity does not affect the collection requirements. If a learner has learning aims funded using either ‘16-19 (excluding Apprenticeships)’ or ‘Other 16-19’ funding models and the source of funding is the Education and Skills Funding Agency (ESFA) - Adult, then the ‘16-19 (excluding Apprenticeships)’ or ‘Other 16-19’ funded collection requirements apply.

For some fields that are collected for apprenticeships, such as the Apprenticeship pathway, the requirements relate to the type of apprenticeship and are not specific to any particular funding model.

For example, the Apprenticeship pathway field is required for all apprenticeship framework aims. This includes aims on Funding models 35, 36 and 99. The collection requirements for this field are:

Collection requirements

• Apprenticeship Frameworks

Data that is not required for collection

Data that is not required for collection must not be included in the ILR files returned. This is enforced where possible through the validation rules for the following reasons:

• to collect data there must be a mandate and Data Science Governance Board approval to do so
• data protection legislation says data should be collected only where there is a purpose in doing so
• the presence of additional data that is not required can make the validation requirements more complicated
• only requested data is subject to reliable and rigorous data quality checks
• it is unhelpful to data users and analysts to have data included that is not required.

Learning Delivery data that is not required is validated. Learner data fields that are not required are not validated as the learner may receive funding through more than one funding model which have differing collection requirements.

Data types and null values

The required data type for each field is detailed on the field specification. All code lists are numeric fields and should be returned without leading zeros (apart from the Learning Delivery Monitoring codes in the Learning Delivery Funding and Monitoring (FAM) entity which are stored as a string and so should retain any leading zeros). The schema defines the different data types and rules that these must meet.

The different data types that are used within the ILR Specification are listed in the table below:

Data type	Description
xs:int	A signed 32-bit number
xs:long	A signed 64-bit number
xs:string	A string; typically Unicode
xs:decimal	A decimal number that includes a fractional part but is not specified using an exponent; for example, 123.45
xs:dateTime, xs:date	Date and time related types
RestrictedString	Any of the following characters A-Z, a-z, 0-9, Space, Full stop, Comma, Semi-colon, Colon, ~!”@#$%&’()\/*+-<=>?_[]^£€

Dates are formatted according to W3C and UK government schema standards (YYYY-MM-DD). Details of standard XML schema data types (date, decimal, int, long, string) are found within the W3C schema standards.

Where data is not collected or is not required, the XML element must not be returned. Empty tags such as <NINumber></NINumber> or </NINumber> must not be included.

Appendices, validation rules, and schema

Technical documents that define the ILR data that publicly funded providers must collect and return including ILR data returns calendar

Entities and fields

Technical requirements for submitting valid data