DEV Community

ImmigrationGPT
ImmigrationGPT

Posted on

UK Sponsor Register Verification in 2026: Data Sources, Update Cycles, and Edge Cases for HR and Compliance Tools

The UK Home Office publishes a list of every organisation approved to sponsor overseas workers. It's a CSV. It updates on working days. And if you're building an HR compliance product, a recruiting platform, or any tool that touches Skilled Worker sponsorship decisions, you need to understand what's in that file — and where it breaks.

The data structure

The register download from gov.uk contains these fields (as of 2026):

  • Organisation Name
  • Town/City
  • County
  • Type and Rating (A or B rating, plus sponsor type)
  • Route (Skilled Worker, Senior or Specialist Worker, Scale-Up, International Students, etc.)

That's it. No company registration number. No incorporation date. No CoS allocation figures. No historical status records.

For a developer, this means you're matching on organisation name and geography. There's no canonical identifier tying the register to Companies House data, HMRC, or any other government database. Name normalisation is your first engineering problem.

Update cadence and lag

The Home Office states the register is updated "on working days." In practice: once daily, typically mid-morning UK time. There is no API. There is no webhook. If you want current data, you poll.

The lag between a Home Office decision and the register reflecting it can range from a few hours to several working days. A licence suspension doesn't necessarily appear in the download the same day it takes effect.

If you're building any kind of real-time verification flow, this is a hard constraint. An "Active" status in the register is a "last-updated-as-of" signal, not a live check. Build your UI language accordingly — showing a freshness timestamp matters more than most implementations bother with.

Name matching edge cases

This is where most implementations break:

Trading name vs registered name. Limited companies often operate under a different name than their registered one. "Smith Healthcare Ltd" might appear on offer letters as "Smith Care Group." The register uses the registered company name only.

Group and subsidiary structures. A large employer might hold the licence at parent company level. New hires whose offer letter names the subsidiary won't find it on the register — because it isn't there.

Non-ASCII characters. The register includes organisation names with accented characters and non-standard punctuation. Depending on how the CSV was exported and how your parser handles encoding, these can silently break a match.

Geographic disambiguation. Two legitimately different companies can have similar names. If you're trying to use town/city to disambiguate, you'll hit normalisation issues — the register doesn't standardise location format consistently.

A fuzzy match with a confidence threshold and a manual review queue for borderline cases is the realistic architecture here, not a simple string equality check.

Status values

Three meaningful states appear in the register:

Active — Standard licensed status. The organisation can assign CoS.

Active (with conditions) — Licensed, but the Home Office has imposed specific compliance requirements. The register doesn't detail what those conditions are. For compliance tooling, this state should trigger a flag rather than a clean pass.

Absent — If an organisation doesn't appear, they're not currently licensed. Either they were never granted a licence, or it's been fully revoked. Historically suspended licences may appear with a Suspended marker, but fully revoked ones typically drop off the register.

A B-Rating (vs A-Rating) indicates the licence is active but compliance standards have fallen below the required level. The employer can't normally assign new CoS until they've resolved whatever triggered the downgrade. If your tool is making any hiring recommendation, this distinction matters.

What the register doesn't expose

CoS allocation — how many certificates the employer can issue — is not public data. Nor is CoS usage history. An employer with an Active A-Rated licence might have zero remaining allocation for the current year. You cannot determine this from the register.

There's also no historical status endpoint. If you need to know whether a company held an Active licence on a specific date six months ago — for audit or retrospective compliance purposes — the only way to know is if you archived the register yourself on that date.

A working implementation pattern

The most useful sponsor verification tools combine:

  1. Register polling — daily download, stored with a timestamp
  2. Companies House API — company number, active/dissolved status, SIC codes, registered address
  3. Fuzzy name matching — normalise both sides (strip Ltd/Limited, lowercase, collapse whitespace), compute similarity, set thresholds
  4. Manual review queue — anything below confidence threshold gets flagged for human review rather than auto-failing

ImmigrationGPT's sponsor search at https://immigrationgpt.co.uk runs this pattern against the full 125,000+ entry register, indexed for fuzzy search by company name, route, and geography. If you're evaluating what a production implementation looks like, that's a useful reference point.

The practical takeaway

The register is a useful compliance signal. It is not a real-time system, it has no company ID linking it to other government data sources, and its name data requires normalisation work to be reliable.

Build with those constraints in mind rather than discovering them in production when an employer's licence lapses between your last poll and a user's verification request.


Not legal advice. For compliance-critical decisions, confirm sponsor status through official Home Office channels.

Top comments (0)