The same learner appears twice
This is wrong and needs correcting. It is not a judgement call.
In plain English
One person has been recorded twice, usually with two different learner reference numbers, and sometimes with two different ULNs. The system treats them as two people.
Why it matters
Aims are split across two records, so prior learning is not seen, progression is broken, funding may be claimed twice or not at all, and the achievement rate is calculated against a population that does not exist.
Funding
Funding may be claimed twice, which is recoverable, or lost entirely where aims are split so neither record qualifies.
Performance
Split aims distort the achievement rate in both directions and make the learner's progression invisible.
Audit
Duplicate records are straightforward to detect and are a standard test.
Most likely causes
Ranked, because in practice a few causes explain most cases.
- commonThe learner enrolled twice, for example through two different routesCommon where a learner applies through more than one route or returns after a gap.
- commonA name or date of birth difference prevented the match at enrolmentA shortened first name or a transposed date of birth is enough.
- occasionalA new ULN was created rather than the existing one being foundThe most damaging version, because it splits the learner's record across providers and years as well as within the college.
Check these first
- Confirm the two records are genuinely the same person, using date of birth, address and the aims recorded.
- Check whether both records carry the same ULN or two different ones.
- Check which record carries which aims, and whether funding has been claimed on both.
- Check whether one of the ULNs was newly created when an existing one should have been found.
Learner reference numberULNDate of birthName
How to investigate
- Prove identity before acting. This is the one diagnostic where a hasty fix does real harm.
- Establish how the duplicate was created, because the cause is usually repeatable.
- Check for other duplicates created the same way, particularly around the same enrolment period.
- Check the funding position on both records before merging, so the effect is understood in advance.
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
- Confirm identity from evidence before merging anything. Merging two different people is far worse than two records for one.
- Establish which record should survive, normally the one with the correct ULN and the most complete history.
- Follow the supplier's documented merge process for your system rather than deleting a record.
- Where two ULNs exist, resolve the duplicate through the Learning Records Service.
- Regenerate and confirm the learner now appears once with all of their aims.
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
- Merge the records using the supplier's documented process, keeping the correct ULN.
- Where two ULNs exist, resolve the duplicate through the Learning Records Service.
- Confirm all aims have moved to the surviving record and that funding is claimed once.
- Record what was done and why, because the merge will be visible as a change between returns.
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.
A mandatory duplicate search at enrolment, on ULN, name and date of birth, before a new record can be created.
A monthly duplicate detection report run across the learner population.
A rule that a new ULN is only created after a documented search has failed to find an existing one.
The rules behind this
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.
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.