Filing history updates: comparing saved captures

Filing history updates can appear even when the company did nothing: a filing history you saw last year is not necessarily the one on the register today. Registers change: rows arrive late, types get re-labeled, and images are added for old rows. Whole systems get migrated too.

This page covers the ways a history moves on its own. It shows how to compare an old copy against a current one without mistaking the register's housekeeping for the company's activity.

What to take away

Changes made by the company

The straightforward kind: a new periodic report, an amendment, a change of agent, a reinstatement. Each arrives as a row with a filing date after your last capture.

Reading these is the ordinary work of the filing history pillar. Place the row in the rhythm, open the document if it changes the entity, note the gap it closes or opens.

One wrinkle: a row can arrive with a filing date before your last capture. That is a document the office accepted but had not indexed when you looked. It is still a company filing. It just tells you the register runs behind, and by how much.

Changes made by the office

These are the ones that cause false alarms.

Re-labeling. An office that upgrades its system often maps old document types onto a new vocabulary. A row that read "Amendment" may now read "Certificate of Amendment" or "Articles of Amendment", and a row that read "Annual Report" may split into two types depending on the entity's category. Nothing about the filing changed.

Backfilled images. Offices digitize old paper in batches. A row that showed no image last year may show one now. That is new access to an old document, not a new document.

Migration rows. A system conversion sometimes adds a placeholder row, or a summary row covering "filings prior to" a date, or removes a placeholder that has been replaced by real rows. The history looks longer or shorter without the company having done anything.

Corrections. A document indexed against the wrong entity is moved. A row with a mistyped date is fixed. A duplicate is removed. These are rare, unannounced, and the only office-side change that can make a row disappear.

Display changes. The register starts showing, or stops showing, a category of document in the default list. A history that seems to have lost its agent-change rows may simply be hiding them behind a filter that did not exist before.

For a U.S. entity, start with the state business filing office that maintains its record; Delaware's Division of Corporations is one example. Read that office's notices and guidance before treating a changed row as company activity.

Telling the two apart

When in doubt, compare the document references, not the labels or the count. A reference that persists across captures is the same filing whatever the label now says. Registers that expose their data programmatically make this explicit, and the Companies House developer overview is a clear example of a register naming the identifiers it promises to keep stable.

Planning re-checks

Where the filing office publishes a reporting cadence for the entity type, use it as a reference point. Plan a check around an expected report date, allowing for indexing lag.

Add a check after any date on which you know something happened, allowing for indexing lag. For an entity you rely on continuously, a quarterly diff is usually enough: the registration status flag moves first if anything serious occurs and is cheaper to watch.

Diffing well

Keep your saved histories as rows with document references, filing dates, and office labels, plus the date you captured them. Key each set on the entity number rather than the name, so a name change between captures does not read as a different company.

On re-check, pull the current list and compare to the reference. Rows present now but absent before are additions. Classify each as company or office using the table above.

Rows present before but absent now are removals. Each needs a note, since each is rare and has a specific explanation. Rows in both with a different label are re-labeling. Update your mapping, not your conclusion.

Write the diff down as a short list, dated, with each change classified. Over several checks this list becomes the true history of the record, which is a different and sometimes more revealing thing than the history of the company.

What an update never is

An office-side change is never evidence about the company. A backfilled image of a 1998 filing does not mean the company was hiding something in 1998. A re-labeled amendment is not a new amendment. A placeholder that vanished is not a deleted filing.

Anyone comparing a history at two points in time feels the pull to read the second as a story about the interval. The discipline is to ask who made each change. That question belongs in the wider sequence set out in company verification.

Common questions

The history is shorter than when I last looked. Should I be worried?

Almost certainly not about the company. Check for a display filter, a system migration notice on the register's site, or a replaced placeholder row. Then compare document references.

If a real filing has genuinely disappeared, ask the state business filing office that maintains the entity's record to explain it.

A row appeared with a date from years ago. Was it hidden?

Usually digitized from paper, or indexed late after being found in a backlog. The document's content will show which. Neither means the company concealed it.

Do I need to keep old captures once I have a new one?

Yes. The captures are the only record of when the register showed what. The current page has no memory of its own previous states.

The register has moved to a new website and my saved links are dead. Is the old data gone?

Almost never. Re-platforming changes addresses, not archives. Find the entity again by identifier, then re-derive your links, and treat the broken ones as a reminder to store document references rather than URLs.