# How a UK dissolution shows up in open data

The free company file is a snapshot of the live register, so a struck-off company is removed rather than marked dissolved. What to watch instead.

Date: 2026-09-10

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](/status) 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 `sources` is 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_detail` is 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](/docs/business-verification) for the full monitor contract, the alert rules and the retention window.
- Set one up with [POST /api/v1/entity/monitors](/docs/api/create-entity-monitor) and let the first run take the baseline.
- Check when each register was last synced on the [dataset status page](/status).
- See what happens when the two registers describe one company differently in [when two registers disagree about a company](/guides/when-two-registers-disagree-about-a-company).

Reference: https://spaw.co/guides/how-a-uk-dissolution-shows-up-in-open-data