DEV Community

ImmigrationGPT
ImmigrationGPT

Posted on

UK Right to Work Checks in 2026: What Your HR System Needs to Handle (And What Manual Processes Get Wrong)

If you're building or configuring an HRIS that operates in the UK, right to work compliance is not optional and not trivial. Since February 2024, civil penalties for employing someone without right to work have been capped at £60,000 per worker — a three-times increase from the previous maximum. And since the shift from Biometric Residence Permits (BRPs) to eVisa-only status for non-UK nationals, the technical requirements for compliant checking have changed significantly.

Here's what you need to know if you're on the HR tech or compliance side.

Two check types with different data requirements

UK right to work checks split into two categories with fundamentally different data flows:

Manual checks apply to British/Irish citizens presenting physical passports or specific documents (e.g., birth certificates + National Insurance letters for UK nationals without a passport). These are document-in-hand reviews.

Online checks are required for anyone whose immigration status is held digitally — which, post-BRP phase-out, is the majority of non-UK nationals. These use either:

  • The Home Office online checking service (share code + date of birth)
  • An Identity Document Validation Technology (IDVT) provider for British/Irish citizens (commercial services like Yoti, Onfido, etc.)

The system implication: you cannot treat all non-UK workers as "do manual check." You need logic in your onboarding workflow to route workers to the correct check type based on their nationality and immigration status.

Share codes: the technical flow

A worker with eVisa status generates a share code through their UKVI account. The employer inputs that code plus date of birth at gov.uk/view-right-to-work to get a result.

Key technical points:

  • Share codes are valid for 90 days from generation
  • The result must be stored as a dated record — typically a screenshot or PDF — tied to the worker's employment record
  • For time-limited right to work (visa expiry), your system needs to flag the expiry date and trigger a follow-up check before it lapses
  • The check result page shows name, DOB, right to work type, and any time limit — your record must capture all of these

If you're automating any part of this via API: the Home Office does not currently offer a public API for bulk employer right to work queries. Share code validation happens through the employer-facing web interface. Any vendor claiming to automate this via a backend API without user authentication is worth scrutinising carefully.

Statutory excuse and what breaks it

Statutory excuse is the legal shield that protects employers from civil penalties if a worker turns out not to have the right to work. Checks that fail to create this shield offer false confidence.

Statutory excuse is lost if:

  • A manual check was done on someone whose right to work is digital-only (eVisa, no physical BRP)
  • The check was done on a copy rather than an original (manual checks)
  • The check was done after the employment start date
  • The share code was entered but no dated record was stored

For HR systems: the date stamp on the check record should be auto-generated at the time of check, not editable by users post-hoc.

Follow-up checks for time-limited right to work

Workers on time-limited visas (Skilled Worker, Graduate, Health and Care, etc.) must have their right to work rechecked before their visa expires. If the check isn't done and they're still employed after expiry, the employer loses statutory excuse from that date.

Your system needs:

  • A field for the worker's visa expiry date, populated at initial check
  • Automated reminders at 90 and 30 days before expiry
  • A workflow that triggers a new share code check and updates the dated record

This is where many HR systems rely on manual tracking — and where compliance gaps compound. An employer who was meticulous at onboarding can find themselves in breach 18 months later because no one tracked the expiry.

Discrimination avoidance in system design

One legal requirement that often gets missed in technical implementation: all workers must be checked using the same process. You cannot build a workflow that routes British nationals through a lighter check compared to non-UK nationals.

Practical implementation: check type differs based on document type, not nationality. Your HR system should present the same initial prompt to all new starters and branch based on what documents they can provide — not based on where they're from. Filtering by nationality at the workflow-routing stage is an Equality Act problem.

Sponsor licence cross-referencing

If your organisation holds a UK sponsor licence and sponsors Skilled Worker or other visa holders, right to work checks are the floor, not the ceiling. Sponsors must also maintain sponsorship records, report changes in circumstances, and keep visa documents tied to CoS (Certificate of Sponsorship) records within defined timescales.

Tools like immigrationgpt.co.uk can help HR and compliance teams search the sponsor register and understand obligations — but the underlying compliance infrastructure needs to live in your HRIS and be maintained there.

The compliance architecture for right to work in 2026 is more complex than it was pre-eVisa. Systems built before 2024 that haven't been updated to handle digital-only immigration status are carrying silent risk.


This post is for technical and informational purposes. For legal compliance advice, consult a UK immigration solicitor or registered adviser.

Top comments (0)