If you are watching a UK company for the moment it stops existing, the obvious thing to watch for is a status of dissolved. It is also the wrong thing to watch for, and a monitor built on it will stay quiet through exactly the event it was bought to catch. This guide explains why, what the event actually looks like in the data, and how to read the statuses that do appear.
The file is a snapshot of the live register
UK company data here is the Companies House free company data product, used under the Open Government Licence v3.0. It is a snapshot of the live register: the companies that are on it today.
A company that is struck off is not marked dissolved in that file. It is removed from it. So the statuses the file carries are Active, Active - Proposal to Strike off, Liquidation, In Administration and similar — and effectively never Dissolved. There is no row left to carry a status.
That is not an omission by the publisher. A register of live companies is exactly what it says it is. But it means the shape of the event you are looking for is a disappearance, not a change of value, and every integration that watches this data has to be built around that fact.
What a single lookup answers after a strike-off
Once the company is off the file and a copy without it has been synced, POST /api/v1/entity answers found: false with reason: unknown_identifier, and that answer is free.
Read that carefully, because it is the same answer a company number that never existed gets. A single lookup cannot tell the difference between "struck off last month" and "never a company at all" — both are absences from the same file. Spaw does not guess between them, and neither should your integration: unknown_identifier means this register does not carry it, and nothing more.
The difference is only visible over time — which is what a monitor is for.
left_register is the dissolution status
A monitored entity list re-checks up to 500 identifiers on a weekly or monthly cadence. There is no daily option: the company file is republished monthly, so a daily run would bill for data that cannot have changed.
The first run sets the baseline and never alerts, so saving a list does not email you about what was already true when you saved it. From the run after that, an entry that was fine last time and is not any more raises an alert, and the statuses are these:
status |
What happened |
|---|---|
left_register |
A register carried the identifier at the last run and does not carry it now. For the UK, this is what a dissolution looks like. |
dissolved |
The register records the entity as dissolved. Rare on the UK file, for the reason above; it is the ordinary case on registers that keep dissolved entries. |
inactive |
The register no longer records the entity as active. |
registration_lapsed |
The identifier's registration is no longer current — about the identifier, not the company. |
registers_disagree |
The two registers have stopped agreeing about the name or the status. |
unverifiable |
No register on this server could answer for it. Never alerted on. |
ok |
Nothing to report. |
An entity matching several is reported as the first of those it matches, so the strongest fact is the one you are told.
The reason left_register exists as its own status is the point of this whole guide. Without it, the disappearance would land in unverifiable and pass in silence — a company striking off with your unpaid invoices on it, reported as "we could not check this one". That is the single worst thing this product could get wrong, so the two cases are kept apart: one is a change from carried to not carried, and the other is a register that never answered in the first place.
unverifiable is never alerted on for the same reason inverted. It is a limit of the data installed on this server, not a fact about the company, and an alert on it would be an alert about us.
Active - Proposal to Strike off is the earlier warning
Strike-off is not instantaneous. A company that is on its way off the register carries the register's own wording — Active - Proposal to Strike off — and by a wide margin it is the most common non-plain status on the file.
Spaw folds that to status: active, because the company is still on the register and still a legal person, and puts the register's exact words in status_detail. If you want to act before a company goes rather than after, status_detail is the field to read. A monitor will not alert on it — it is still ok, and it would be wrong to say otherwise — so this is a check to run in your own code against the field.
The same applies to Liquidation and In Administration: they fold to a status that says the entity is still carried, with the register's wording beside it. The folded value tells you what kind of thing it is; the detail tells you what is happening to it.
Up to five weeks behind
The free company data product is republished monthly, within five working days of the previous month end. An answer here can therefore be up to five weeks behind the live register, and a company struck off yesterday is still on the copy this server holds.
Nothing about that is hidden. Every response names the date of each copy in sources, and the dataset status page lists both registers with the date each was last synced. Two consequences worth designing around:
- A weekly monitor over a monthly file is mostly free. A repeat of the same identifier on the same account inside seven days does not bill, so a weekly cadence costs about what a monthly one does after the first run — while catching a new copy within days of it landing rather than within weeks.
- Do not build a same-day process on this file. If you need the register as it stands this minute, this is not the dataset for it, and the copy date in
sourcesis how you can tell.
What a struck-off answer does not tell you
- Why the company went. A voluntary strike-off, a compulsory one and a liquidation are not the same event, and once the row is gone the file carries none of that. Before it goes,
status_detailis your only distinction. - Whether it came back. UK law allows a company to be restored to the register. If that happens it reappears in a later copy and the next run reports it as
ok. The monitor alerts on going from fine to not fine, so a restoration is quiet. - Who was behind it. This product carries no officers, no ownership and no addresses — a registered address is very often somebody's home, and an identifier alone does not say whether a company or a sole trader stands behind it.
- Anything at all, when the file is missing. A register that has not been synced answers
register_unavailable, which is free and never cached, so the next lookup answers as soon as the file lands. Absence of data is never reported as absence of the company.
What to do next
- Read the business verification guide for the full monitor contract, the alert rules and the retention window.
- Set one up with POST /api/v1/entity/monitors and let the first run take the baseline.
- Check when each register was last synced on the dataset status page.
- See what happens when the two registers describe one company differently in when two registers disagree about a company.