DEV Community

ImmigrationGPT
ImmigrationGPT

Posted on

ILR Eligibility in 2026: Modelling Route-Specific Qualifying Periods Across UK Visa Categories

Building a system that tracks ILR eligibility correctly is harder than it looks. The qualifying period isn't a single countdown — it's route-specific, it resets on a visa switch, and there's a parallel track (the Long Residence route) that follows completely different rules. Most compliance tools get at least one of these wrong.

The qualifying period by route

The table below captures the primary routes and their qualifying periods for ILR as of 2026:

Route Qualifying Period Notes
Skilled Worker 5 years Clock starts at leave grant date
Global Talent 3 years Requires active endorsement
Innovator Founder 3 years Subject to business conditions
Scale-Up 5 years First 2 years require sponsor
Spouse/Civil Partner 5 years Combined route with FLR(M)
Long Residence 10 years Multiple route types count

For most HR compliance use cases, the Skilled Worker route is the dominant one. Five years from the date of first leave grant in the Skilled Worker category — not from the applicant's date of arrival in the UK, not from their first Skilled Worker application.

The route-switch reset problem

When someone switches routes — most commonly from Student to Skilled Worker — their qualifying period for the new route starts at zero on the date the new leave is granted. Their prior UK residence doesn't carry over for route-specific ILR eligibility.

This creates a modelling problem. If you're building an eligibility tracker and using the applicant's total UK residence time as a proxy for qualifying period, you'll produce incorrect results for anyone who switched routes. The correct model requires tracking leave history, not UK presence history.

The code implication: you need a leave history array, not just a start date. Each leave entry has a route, a grant date, an expiry date, and accompanying flags. The qualifying period calculation should iterate over that history and compute contiguous qualifying time within the target route.

def compute_qualifying_period(leave_history: list[dict], target_route: str) -> int:
    """
    Returns qualifying days for ILR under target_route.
    leave_history: sorted by grant_date ascending.
    Each entry: {route, grant_date, expiry_date}
    """
    qualifying_days = 0
    last_contiguous_end = None

    for leave in leave_history:
        if leave['route'] != target_route:
            last_contiguous_end = None
            continue

        start = leave['grant_date']
        end = leave['expiry_date']

        if last_contiguous_end and start <= last_contiguous_end:
            qualifying_days += (end - last_contiguous_end).days
        else:
            qualifying_days += (end - start).days

        last_contiguous_end = end

    return qualifying_days
Enter fullscreen mode Exit fullscreen mode

This is simplified — real implementation needs to handle FLR extensions that aren't technically new leave grants, 3C leave (overstay protection during pending applications), and cases where the Home Office grant date differs from the BRP issue date.

The Long Residence parallel track

Long Residence is a fundamentally different model. Rather than requiring continuous time on one specific route, it requires ten years of continuous lawful residence across any combination of valid leave grants. Student, Skilled Worker, spouse — all count toward Long Residence, which they don't for route-specific ILR.

The qualifying conditions are stricter on absences (more than 540 days total, or 180 in the final year, breaks the Long Residence clock), and the route carries additional conditions around good character.

For compliance tools, Long Residence eligibility should be computed as a separate track running in parallel with route-specific ILR eligibility. Both should surface in a complete eligibility model — an applicant might become eligible for Skilled Worker ILR in year five while also running down a Long Residence clock that started on their first Student visa.

KOLL validation layer

Beyond the qualifying period, ILR requires satisfying the Knowledge of Language and Life check. Two-part requirement:

  1. Life in the UK test — 24 questions drawn from the official handbook, £50 per attempt in 2026
  2. English language — approved qualification at B1 CEFR level or above, OR national of a majority English-speaking country, OR exempt (age 65+, certain disabilities)

KOLL exemptions need to be stored against the applicant profile and checked before flagging KOLL as a blocking condition. English language proofs have expiry considerations — some qualifications are accepted indefinitely, others are time-limited.

Application state machine

The ILR application (SET(O) for most work routes) is submitted via the UKVI online service. Key validation states to track:

  • Qualifying period met? (route-specific calculation)
  • Absences pass 180-day-per-rolling-year test?
  • KOLL satisfied or exempt?
  • Current leave still valid? (cannot apply with expired leave unless 3C protection is active)
  • Biometric information enrolled?

A successful grant issues a BRP with no expiry date on the leave. For HR right-to-work verification: an ILR BRP still requires a valid share code check — employers must not rely on the physical card under the current RTW regime.

Processing times in 2026 are typically 8–12 weeks for standard applications. Priority services exist (five working days for super priority, ten working days for priority), at additional cost.

What breaks in practice

The five most common modelling errors I see in HR compliance tools:

  1. Using UK entry date instead of leave grant date as the qualifying period start
  2. Not resetting the clock on route switches (especially Student → Skilled Worker)
  3. Computing absence limits as a rolling total across the entire qualifying period rather than per rolling year
  4. Not tracking Long Residence as a parallel eligibility path
  5. Treating ILR grant as end-state rather than modelling the post-ILR naturalisation window

If you're building or auditing a compliance tool, those five are worth testing against explicitly with edge-case data.

ImmigrationGPT provides AI-powered guidance on UK immigration based on official GOV.UK sources.

Not legal advice. Immigration rules change frequently — consult a qualified adviser for individual cases.

Top comments (0)