Company verification decay: which fields go stale and how to schedule a recheck

A verification is not a state a counterparty enters. It is a photograph, and the fields in it fade at very different rates. Some never change. One can go stale overnight without anybody filing anything. Treating the whole check as equally fresh is what produces the file that says "verified" over a record that stopped being true two quarters ago.

This page is about the clock: which findings decay, how fast, what restarts them, and how to build a re-check schedule that costs almost nothing.

What to take away

The decay table

The last row is why this page exists. Every other field changes because somebody filed something, so there is at least a document to find.

Status can change because nothing was filed and the office acted on a deadline. It is the only field that moves in silence, and the one most often wired into an automated gate.

What sets the clock

The register runs on due dates, not on events. Offices set a periodic report cadence for each entity type.

The same discipline appears where registers publish it: a central registrar states plainly when a company must file its annual accounts, and a state office publishes the equivalent for its own periodic report. Meeting those obligations is part of the routine maintenance the Small Business Administration groups under staying legally compliant.

Two consequences for your schedule. Anything you learned about people or addresses is bounded by that cadence and cannot be fresher than the last report. And the useful moment to re-check is shortly after each expected report date, because that is when you find out whether the report arrived, which is more informative than the report itself.

Event triggers that beat any calendar

Re-verify on these, whatever the schedule says.

Building the schedule

Three tiers cover almost everything, and deciding them once is the point.

Watch. Status only, checked at the register, on a light rhythm and after each expected report date. Cheap, and it catches the field that moves silently.

Refresh. Status, name, agent, address, and any new rows in the history. Run this when the exposure changes and once between report cycles for anything you rely on continuously.

Rebuild. The full sequence in company verification, including the questions the register cannot answer. Reserved for material commitments and for any counterparty that approached you.

Key every tier on the entity number and jurisdiction rather than the name, so that a name change between checks reads as a change rather than as a different company.

What a re-check should produce

Not a replacement. A dated addition. Keep the previous capture, add the new one, and write one line on what differed.

Over a few cycles, that line becomes a record of how the counterparty handles its paperwork. That beats any single photograph. A company that files on time for four years running tells you something a one-off check never can.

Where nothing changed, write that too, with the date. "No change since the last check" is a finding, and its absence is what makes an old file impossible to interpret.

Obligations that appear and disappear

Reporting regimes are added, amended, and paused. A company's obligations are not fixed for the life of the entity. Where a new regime applies, the body running it usually publishes its own plain-language material, as with the FinCEN small entity compliance guide for beneficial ownership reporting.

Read the body's own current page rather than a summary of it, including this one. The state of any such regime on the day you are reading is a question only that body can answer.

The agent field has its own clock

An agent can resign, and after a resignation an entity may have no valid agent until it appoints another. That gap means an address you recorded is not a safe place to deliver anything.

If the agent field or status looks like it has moved, check the history for a resignation row before relying on the address. See registered agent lookup for the reasons.

Common questions

How often is often enough?

Tie it to the entity's report cadence and to your own exposure, not to a fixed interval. A quarterly status check on anything you rely on continuously, plus event triggers, covers most situations without anyone maintaining a calendar of fifty different due dates.

Can I automate the status check?

Sometimes, and the terms of the source decide it. Where a register offers no programmatic channel, a person opening a page once a quarter is perfectly adequate and considerably less likely to store a rate-limit error as a clean result.

Should an automated system block on a stale status?

It should block on a status it could not refresh, which is a different thing. A pipeline that treats "no answer" as "no problem" will approve exactly the cases you built it to catch.

What do I do with the old captures?

Keep them. They are the only evidence of when the register showed what, and the current page has no memory of its own previous states.