The Quarterly Account Status Sweep: Renamed, Acquired, or Dissolved

This playbook is for the recruiting or revenue operations owner who answers for the account base. Once a quarter, the job is to find every account that has quietly been acquired, renamed, or shut down, fix each record the right way, and stop mail to domains that may now belong to someone else. The guide gives you six statuses and the evidence each one requires, a seven-step sweep, the right fix for each status, and a precision check you can defend to an auditor.

What does the account status sweep produce?

Each account comes out of the sweep with exactly one of six statuses. Each status has a minimum bar of evidence and one fix. If any row is still blank, the sweep isn't finished.

Two terms come up throughout. Dormant here is a sweep status: the account shows early signs of ending but isn't confirmed dead. It is not the UK filing category of the same name. Unresolved means the evidence conflicts or is missing, so a person has to look.

Contact suppression does not depend on status. If a domain has been re-registered by someone new, its contacts get suppressed straight away, whatever the account's status. That rule is covered under the fixes below.

How much change should one quarter turn up?

Nobody has published how often accounts in a B2B CRM get acquired, renamed, or dissolved. The best available starting point is US Census data: about 8% of firms exit each year, roughly 2% a quarter, and that figure overstates exits for a base of larger accounts.

The Census Business Dynamics Statistics (BDS) counts a firm as dead when it had positive employment in March of the previous year and none in March of the current year. By that measure, about 8% of firms exit in a typical year, but they account for only 2% of employment. Exits are driven mainly by very small firms and establishments, those with fewer than 5 employees. If your base leans toward larger accounts, expect fewer than 8% to exit in a year.

A caveat on the table: BED and BDS are separate datasets and are not directly comparable. Use the rows as a sense of scale, not as a forecast.

That comparison drives the most important rule in this guide. If temporary closures happen about as often as permanent exits, one quarter's evidence can't tell them apart. Census data also shows establishments can re-activate up to 7 years after an exit. So a dead domain alone is never enough to archive an account.

BDS doesn't count acquisitions or renames separately, so there is no public base rate for those two statuses. Your first sweep produces your own. Record the counts for each status and use them as the baseline for the next quarter.

Which evidence proves which status?

Registry and filing records tell you what happened to the legal entity. DNS and HTTP checks tell you what happened to the domain. You need both, because each one misleads in its own way.

The table below gives, for each signal, what it proves and how it can mislead you.

Reading Companies House status

The Companies House Public Data API is free with an API key. Its company_status field can take these values: active, dissolved, open, closed, converted-closed, receivership, administration, liquidation, insolvency-proceedings, voluntary-arrangement, registered, and removed. One third-party snapshot of live UK companies gives a sense of how they split:

The shares are calculated over 5,688,497 listed rows, which include small receiver and voluntary-arrangement counts. The figure to note is the 7.1%. Roughly one listed live company in fourteen is on its way to being struck off, yet the word "Active" still appears in its status.

Here is how I map registry status to sweep status:

• active, with current filings: Active, unless the name has changed (then Renamed).
• active, with overdue accounts or no recent filings: Dormant candidate. Active describes the company's legal life, not whether it trades.
• Active - Proposal to Strike off: Dormant. Recheck next quarter.
• liquidation, administration, receivership, insolvency-proceedings, voluntary-arrangement: Dormant, with the registry status kept as the reason. These come before dissolution, not after it.
• dissolved, closed, removed: Dissolved, once the domain evidence agrees.
• converted-closed, open, registered, or anything you don't recognise: Unresolved. Read the full record before you act.

Reading US filings

For US public companies, Form 8-K Item 2.01 is filed on completion of an acquisition or disposition of assets. EDGAR full-text search covers all EDGAR filings submitted since 2001, so a search on an account's name can surface its acquirer. The limit is that this only finds deals where a party files with the SEC. A private company buying another private company leaves no 8-K.

I have not verified how US state Secretary of State portals or other national registers expose status. Before you build them into the sweep, look up ten accounts you already know have closed in each register you depend on, and confirm the register shows them correctly.

Reading DNS and HTTP

The usual web checks are no A record, no MX record, a parking nameserver, an expired TLS certificate, and a "for sale" page title. No one has published a false-positive rate for any of these checks on its own. The only measured figure is for a combined parked-page classifier. The NDSS "Parking Sensors" model reports a 1.5% false-positive rate and a 98.6% true-positive rate at its default threshold, and 0.5% and 97.9% at a stricter one. Treat any single check as a hint that the classifier or a person has to confirm.

The sweep procedure, step by step

Run these seven steps in order against a frozen snapshot. Each step has a test for when it's done, so the work can be handed between people without losing track.

Notes on the steps where people most often stumble:

• Step 1. Revenue operations owns the export. If you don't freeze it, an account reparented by hand in the middle of the sweep will get reparented again.
• Step 2. The Companies House limit is up to 600 requests in a 5-minute window, shared across all endpoints. If you go over, you get a 429 response. The developer guidelines invite you to get in touch if you need more. One practitioner says there is no paid tier to raise the limit. Those two statements don't contradict each other, but don't plan on a higher limit. At 120 requests a minute, 10,000 single-call lookups take about 83 minutes. If you also pull filing history, that's two calls per account and about 167 minutes.
• Step 3. The filing pass gives you candidate matches, not confirmations. A name in an 8-K might belong to a different company with a similar name, so check each hit against the account's domain or address.
• Step 4. Keep the raw values, not just a pass or fail. You will need the WHOIS creation date again in step 6, and next quarter's sweep needs this quarter's values to compare against.

account_id,account_name,domain,registry_country,registry_number,snapshot_date,
company_status,date_of_cessation,last_filing_date,accounts_overdue,
filing_hit,filing_form_item,acquirer_name,acquirer_account_id,
a_record,mx_record,nameservers,http_status,final_host,parked_verdict,whois_created,
prior_sweep_status,sweep_status,deciding_evidence,reviewer,fix_applied,fix_date

How do you make the status call?

Read the legal evidence first and the domain evidence second. The legal evidence decides between Renamed, Acquired, and Dissolved. The domain evidence decides whether you can act on that call this quarter.

Make the call in this order. The first rule that fits wins:

1. Registry is dissolved, closed, or removed, the domain is dead or parked, and the previous sweep showed the same: Dissolved.
2. Same as above, but this is the first sweep showing it: Dormant.
3. A merger filing or announcement names an acquirer, and the domain redirects to the acquirer or still works: Acquired.
4. The registry shows a name change, or the company announced one, and the domain redirects to the new name: Renamed.
5. The registry shows a pre-dissolution or insolvency status: Dormant.
6. The domain redirects, is dead, or is parked, and the registry and filings show nothing: Unresolved. A person checks it.
7. The registry is live with current filings and the domain serves the company's own site: Active.

Fill in the reason field with the evidence that triggered the rule, for example "CH dissolved; NXDOMAIN Q-1 and Q0". Salesforce field history records a reparent as old and new values with no reason attached. The reason field is the only place the explanation survives.

How do you apply the fix for each status?

Reparent acquired accounts. Update renamed accounts and alias the old domain. Archive dissolved accounts and suppress their contacts in the same change. In Salesforce, don't merge an acquired account into its acquirer, because the merge deletes the history you may later need to account for.

How each CRM handles a merge is what decides the right fix:

Acquired: reparent, don't merge

In Salesforce, the merged record keeps the Created By user and Created Date from the oldest record. The history entries of the merged accounts are lost, including every tracked field. Reparenting through the Parent Account field keeps the acquired account, its ID, and its history, and adds a change entry for the parent. Choose the fix for audit reasons, not because it's quicker.

If someone does need to merge, check permissions first. In Salesforce Classic, merging needs Delete permission on business or person accounts, and the user must be a Salesforce admin, the account owner, or above the owner in the role hierarchy.

Sources disagree on one point of order. One hierarchy-audit guide says to merge overlapping customers before any reparenting. Here's how I reconcile it: if the "acquired" account and an acquirer account are really duplicates of the same legal entity, merge those first, then reparent the separate legal entities. Don't merge two different legal entities just because one now owns the other.

Renamed: update and alias

Update the account name and primary domain, and keep the old domain so that records and inbound activity still match. In HubSpot, merging companies keeps the secondary company's domain as a secondary domain name, so a merge does keep the alias. HubSpot merges can't be undone, though. Use the Merged IDs property to see earlier records, and copy those IDs to a store outside HubSpot. Community reports conflict on whether the surviving record keeps its ID, so don't let integrations assume it does.

Nobody has published how long an old domain should stay as an alias. Review every alias at each sweep, and check the old domain's WHOIS creation date before you drop it.

Finding the people after the account moves

When an account is renamed or acquired, the contacts on it don't disappear. Some of them now work at the acquirer, some have new titles, and some have left. The record fix takes ten minutes. Rebuilding the contact list is the slow part. Refolk handles that step: you describe the role and the company situation in plain English and get current people back from LinkedIn, GitHub, and the open web, so you don't have to read through an org chart by hand.

Dissolved: archive and suppress together

Archive the account and suppress every contact at its domain in the same change. Suppress at domain level in your sending tools as well as on each contact, so that a newly imported contact at that domain is blocked too. When a contact leaves a dissolved company, they still count as a relationship worth keeping. Refolk can find where they work now, so the relationship moves to a live account and doesn't go into the archive with the dead one.

That figure is the reason suppression can't wait for the archive. The Domain-Z study found 27,758 domains from public blacklists and 238,279 domains resolved by malware that expired and were then maliciously re-registered. Taking over a domain's email addresses is one documented use. No one has published a rate for company domains specifically. Because re-registration usually happens on release day, check the WHOIS creation date, not just whether the domain resolves. A domain that resolves again with a creation date after the company stopped trading is in a stranger's hands.

How does the sweep go wrong?

The sweep mostly goes wrong in two ways: someone treats one signal as proof, or someone applies the fix in a way that destroys evidence. Each of the eight failure modes below has a specific check that prevents it.

1. Treating Companies House "Active" as operating. A company can be dormant and still show Active, because the status describes its legal existence, not whether it trades. Before you call an account Active, check its filing history and whether its accounts are overdue.
2. Treating date_of_cessation as proof of death. The Companies House developer forum documents active companies that still carry the field, typically after restoration. Always read it alongside company_status, never on its own.
3. Treating "Proposal to Strike off" as Dissolved. It is a status that comes before dissolution, and in one snapshot it covered 7.1% of listed live companies. Classify it as Dormant and recheck next quarter.
4. Treating a 301 as a rebrand. The 301 versus 302 split is a heuristic, not a test. Find a registry name change or an 8-K before you classify the account as Renamed or Acquired.
5. Calling a domain dead after one failed check. About 2% of establishments close temporarily each quarter, roughly the same as the quarterly exit rate. Require two consecutive sweeps before you archive.
6. Merging the acquired account into the acquirer in Salesforce. The merge deletes the loser's tracked history and the non-master record. Reparent instead, and put the reason in a field.
7. Archiving the account but still emailing its contacts. Re-registered domains are a documented way to take over email. Suppress contacts in the same change as the archive, and check the WHOIS creation date even for accounts you are not archiving.
8. Assuming HubSpot IDs stay stable after a merge. Community reports conflict on whether the surviving record keeps its ID. Store Merged IDs outside HubSpot and map external systems through them.

A redirect tells you where the traffic goes. It does not tell you who owns the company.

Two smaller false positives come up regularly. An 8-K hit on a common company name can point at the wrong entity, so match on domain or address before linking it. A parked-page verdict on a domain whose MX record still works may mean the company stopped running its website but still uses email. Send it to Unresolved rather than Dissolved.

How do you check precision and set the time budget?

Before the sweep starts, agree a precision target with whoever answers for the data. At the end, check 50 hand-verified records against it. The registry pass takes about 83 minutes for 10,000 accounts. The rest of the time depends on how big the Unresolved queue is, so measure your review speed before you promise a date.

Precision is the share of accounts given a status that really have that status. No published target exists, so the target is yours to set, and you should record who signed it off. Set a separate bar for each status, because the errors cost different amounts. A wrong Dissolved call archives a live customer. A wrong Active call only postpones a fix.

Draw the 50 records from the statuses that trigger action: Renamed, Acquired, Dissolved, and Dormant, plus a few Active records as a control. Active will dominate the base, so a purely random sample would mostly check the easy calls.

For timing, only the registry pass has a figure derived from a published limit. I haven't seen published times for the export, filing pass, DNS pass, or fixes. Time a pilot instead: review 20 Unresolved records by hand, average the minutes per record, and multiply by the size of the Unresolved queue. That gives the number of working days you can commit to.

PRECISION TARGET (agreed before sweep)
Renamed: ___%   Acquired: ___%   Dissolved: ___%   Dormant: ___%
Signed off by: __________   Date: __________

SAMPLE (50 records across Renamed, Acquired, Dissolved, Dormant, plus Active control)
record_id | assigned_status | verified_status | correct Y/N | evidence checked
__________|_________________|_________________|_____________|_________________

RESULT
Status | sampled | correct | precision | meets target Y/N | action if N

TIME BUDGET
Registry pass: ___ accounts x calls per account / 120 per minute = ___ min
Pilot: ___ min for 20 Unresolved reviews / 20 = ___ min per record
Unresolved queue: ___ records x ___ min / ___ review min per day = ___ days
Fix application: ___ days (from last quarter's actuals)
Working days committed to stakeholders: ___

How do you keep the sweep current?

Treat each sweep as the baseline for the next one. Carry forward the Dormant list, the alias list, and every domain's evidence row, because the two-sweep rule and the re-registration check only work if last quarter's values are kept.

At the next sweep, recheck every Dormant account first. These either become Dissolved or go back to Active. Compare your status counts with the roughly 2% quarterly exit prior. A quarter far above that usually means one signal is misfiring, not that a wave of companies has died. Recheck the WHOIS creation date on every archived domain, so you catch re-registration that happened after you archived.

Once the checklist passes, send the stakeholders three things: the status counts, the precision result, and the actual working days against the committed budget. The third figure improves next quarter's budget more than any rule in this guide.