The Account Status Standard: Verified-Active, Re-Parent, or Retire

Before I let a company stay on a working account list, I need to confirm one thing: it is still a real, active, standalone business that has not been acquired, merged, renamed, or shut down. This guide is for the data steward, revenue operations manager, or data quality analyst answerable for that record in an audit. It defines a pass/fail bar and a checklist so two people grading the same record reach the same verdict: verified-active, needs-re-parenting, or retire.

Existing hygiene guides cover deduping, identifier keys, list reconciliation, and re-verification cadence. None of them names the liveness test itself. This is the document you keep open to settle "is this account still real?" in a way that survives review, instead of a generic "clean your CRM" checklist that ranks a record today and never says what pass looks like.

What "account status" means and why it needs a standard

Account status is the answer to a single question: does this record still point at a live, standalone legal entity? A standard turns that from a judgement call into a graded verdict two reviewers can reach independently.

The reason this needs a written bar is that the underlying facts rot on a schedule. B2B data decays at about 2.1% a month, or 22.5% a year, on the MarketingSherpa research that HubSpot uses as its benchmark, with the typical range running 20% to 30% a year. Company-level firmographics like acquisition, rename, and closure decay slower than contact fields, but they ride the same events. And the pressure is one-directional: Companies House recorded 787,120 dissolutions in the most recent full year, up 8.31% year on year, against an effective register of 4,872,293 companies. The "retire" bucket is growing faster than the register itself, so a static list decays toward being wrong by default.

The trap most teams fall into is treating "recently checked" as "still true." A record verified eight months ago is meaningfully likely to be wrong at a 22.5% annual rate. A standard fixes this by pairing a verdict with an evidence trail and a re-verification clock, so the record carries its own proof and its own expiry.

Who owns this work and what rigor to borrow

Account-status grading sits with data stewards, data quality analysts, and revenue operations managers, and where these roles concentrate tells you what evidence standard to adopt. In Refolk's index, US data stewards cluster at regulated firms like JPMorganChase, Citi, UnitedHealth Group, and Siemens, which is exactly where audited know-your-business checks already live.

That concentration is the tell. The audit-survivable checklist should borrow registry-grade evidence standards from finance and healthcare, not marketing-hygiene ones. When a bank grades a counterparty, it captures the current registry status field and a URL, not a vibe about whether the website looked alive.

Table 1 - US roles that grade company records (Refolk's index)

Populations come from Refolk's index; the share is derived against the 3,048 total. The data quality analyst leads the count, but the data steward role is the one that most often carries formal audit responsibility for a record.

Table 2 - Who owns account-status work, by market (Refolk's index)

US and UK counts come from Refolk's index; the ratio is derived. The roughly five-to-one skew matters when you set cadence policy across regions: the US has far deeper role coverage to run frequent re-verification, so a global team often has to design a leaner, more automated check for its UK book.

The three verdicts and the exact bar for each

Every record resolves to one of three verdicts, and each has a bar stated so two reviewers grade the same case the same way. The verdict is a function of two independent signals - registry status and domain liveness - plus one event scan.

• Verified-active. Registry status is active or in good standing, the domain resolves to a live site carrying the company's own name, and no acquisition, merger, or closure event appears inside the record's date window. All three must hold.
• Needs-re-parenting. An acquisition, merger, or change-of-control event is confirmed, but the entity is still reachable: the registry entry may remain active and the domain often redirects to the acquirer. The account is real; its parent is wrong.
• Retire. The registry shows the entity as dissolved, revoked, administratively dissolved, or suspended, and the domain is dead or in redemption. The entity has no current business capacity.

The registry statuses to grade against are fixed vocabulary: active or good standing, dissolved, revoked, administratively dissolved, and suspended. Dissolved and revoked mean retire. Active does not automatically mean verified-active, because an acquired subsidiary can keep an active entry for months.

How each signal proves status, and when it lies

Each signal in this standard proves something specific, and each has a failure shape you can name in advance. Knowing the lie is what separates grading from guessing.

The domain proves current operating presence, and it lies when a parked page or a mail-only domain masquerades as alive or dead. A practical validator rule: a domain needs both DNS records and a live site to be Valid; a domain with an MX record but no live site is Risky; a parked domain is always Invalid. A strong parking heuristic is that the server stops responding to HTTPS and responds only to HTTP, and in one sample every domain on Amazon's ASN 16509 came back parked. At scale, backlinks beat page-scraping: dropping domains with fewer than 10,000 backlinks removes 87% of parked domains and 63% of domains returning 404s.

Table 3 - Domain-status liveness thresholds

The registry proves current legal status, and it lies when it lags. A domain can go dark inside a 30-day redemption window while the registry stays active for months. The reverse also happens: an acquired firm keeps a live domain redirect long after control changed. Because the two signals fail on different clocks, you need both. Neither alone resolves the retire-versus-re-parent fork.

The event scan proves the reason a signal changed. This is the signal that most often gets skipped, and skipping it is what turns a re-parent into a wrongful retire. For US public companies the fastest hard signal is the 8-K, filed within four business days. For everyone else, the signal is news, press releases, and a distinctive pattern in employment data: the employer string that reads "X now part of Y" or "X by Y."

That employer-string feed is the highest-leverage re-parent signal because it is human-maintained and current. In Refolk's index the pattern shows up directly, with live examples like "SafeAI (now part of Pronto)" and "Sertifi by Flywire." I use Refolk to surface these ownership strings across a whole account book in one pass, which flags the re-parent candidates before I ever open a registry.

The verification procedure, step by step

Run these eight steps in order. The first freezes the identifiers so both reviewers grade the same entity; the last stamps the verdict and sets the clock. The whole pass runs in about an hour, most of it in the registry lookup and the event scan.

The registries to reach for are jurisdiction-specific. The US has no single registry: search the Secretary of State database for the state of registration, use EDGAR for publicly traded companies, or a verification tool that aggregates them. The UK uses Companies House, Australia uses ASIC, and India uses the MCA. A registry aggregator holds 230M-plus entities across 140-plus jurisdictions and is a reasonable first stop when you do not know the home state or country.

How this goes wrong: the seven failure modes

Most bad verdicts come from a handful of repeatable mistakes, and each one has a false positive or false negative you can defend against. This section carries the weight of the standard, because a wrong retire deletes a live account and a wrong verified-active hides a dead one.

• Active registry read as alive. A dissolved entity can still show genuine formation documents, which are misleading if presented as current business capacity. Grade the current status field, not the certificate.
• Parked page mistaken for a live site. NXDOMAIN gives the same DNS error whether a domain is free or taken, so browsing alone cannot tell you. Confirm with WHOIS status before you trust "the site loaded."
• Acquired-but-alive filed as retire. An acquired subsidiary often keeps an active registry entry and a domain redirect, so retiring it deletes a real, reachable account. Cross-check the 8-K or news event before any deletion.
• MX-only false positive. A domain with mail but no website grades Risky, and it is frequently a live business mid-migration. Do not auto-retire on site-down alone.
• Stale-by-cadence false negative. A record verified eight months ago is meaningfully likely to be wrong at 22.5% annual decay. Treating "recently checked" as "still true" hides that decay. Enforce the 90-day clock.
• Rename read as closure. A rebrand changes certificate, DNS, and name at once, the same signals as an ownership change, and those can also shift for unrelated reasons like a certificate renewal. Require a corroborating rename source, not just a certificate change.
• Two reviewers, different keys. If reviewer A keys on domain and B on legal name, they grade different entities. Freeze the identifier set in step one before either starts.

The failure modes cluster around a single root cause: reading one signal as the whole answer. The domain, the registry, and the event scan each answer a different question, and the verdict is only defensible when all three agree or when their disagreement is explained by a named event.

The audit-survival checklist

Run this before you call any record graded. It is built to be applied identically by two people, which is what makes the verdict survive an audit. If any item fails, the record is not graded, it is escalated.

The second-reviewer replay is the item people cut under time pressure, and it is the one that makes the standard audit-proof. When two people grade blind and disagree, the disagreement itself is the finding: it means the identifier set was ambiguous, the event scan missed something, or one reviewer read a lagging signal as current.

The re-verification clock and how to keep it current

A verdict is only true as of its stamp date, so every record needs a re-verification date, not just a last-checked date. Set the interval from the decay arithmetic, then let sector volatility move it inside a floor and a ceiling.

The floor is 90 days. At the 22.5% benchmark, roughly 625 of every 10,000 records rot per quarter, so any interval longer than 90 days guarantees a known error rate in a list you are calling verified. The ceiling is annual, reserved for genuinely stable entities: long-established firms in slow sectors with no recent event history. Fast-moving sectors, early-stage companies, and anything with a prior event flag stay on the 90-day clock.

STATUS: verified-active | needs-re-parenting | retire
GRADED_ON: YYYY-MM-DD
DOMAIN: Valid | Risky | Invalid  (evidence URL)
REGISTRY: active | dissolved | revoked | suspended  (evidence URL)
EVENT: none | acquisition | merger | rename | bankruptcy  (date, source URL)
REVIEWER_1: initials
REVIEWER_2: initials  (blind replay matched: yes/no)
RE_VERIFY_BY: YYYY-MM-DD  (90d fast | annual stable)

To keep the queue ahead of decay rather than behind it, watch the leading feeds, not just the record clock. The re-parent signal is already sitting in employment data: when a person's employer string flips to "now part of" or "acquired by," that record needs re-grading regardless of its scheduled date. Pulling former employees who left a company in the last twelve months is a cheap way to confirm whether an entity is still operating when the registry and domain disagree. I run these employment scans in Refolk to catch re-parent candidates between scheduled checks, which turns the clock from a fixed cadence into an event-driven one.

kind: note
title: The re-parent feed often beats your CRM hierarchy
Ownership changes show up in employment data before the account hierarchy updates. A record whose people already say "by Flywire" or "now part of Pronto" should jump the queue, even if its 90-day clock has not expired.