Company verification data reads best as one dated row per finding

Company verification data is not a browser-history entry. The output of a check is a record with a shape: what was asked, of which source, on what date, with what answer, and what could not be established.

Get the shape right once and the same file will still be readable by a stranger two years later. That is the only test that matters.

This page is about that record: the fields, what not to store, and how to keep evidence without building a private dossier nobody needed.

What to take away

The record's shape

One row per finding, not one row per company. A company accumulates findings over time and across sources. Collapsing them into columns on a company record destroys the two things that make each one usable: where it came from and when. Each dated row also needs a source label, which is the core idea behind a company verification list.

Use these columns for each finding: jurisdiction; registry/office; entity number; question/finding; source reference; retrieved on; source updated on; answer; not established/limits; evidence file.

Template row (illustrative, not a lookup result):

The pair of dates is the field people merge and should not. A status read today from a record the office last updated in March is a March fact retrieved in October, and both halves change what it is worth.

Key on the identifier, never on the name

The subject key must carry jurisdiction plus the office's entity number, stored as text with prefixes and leading zeros intact. Names change, repeat across states, and are punctuated four ways in your own systems. A file keyed on a name will silently split one company into two records after a rebrand and merge two companies into one after a coincidence. For example, California's Secretary of State bizfile Online business search shows the state's assigned entity number. Number formats vary by entity type, so keep the number exactly as displayed.

Keep the name as an attribute with its own retrieved-on date, and keep former names rather than overwriting them, because old contracts and invoices will quote them for years.

Store the negative results

"Not established" is a value. So is "source does not hold this". A row saying that the state does not collect officers for this entity type is worth more than an empty officer field, because the empty field will be read as "nobody" by the next person to open the file.

The same applies to what you chose not to check. A short list of sources deliberately skipped, with the reason, stops a later reader assuming the check was exhaustive. Every verification file is partial; only some of them admit it. Skipped sources belong in the file too, and a company verification timeline shows how those gaps age.

What not to store

Registry records contain individuals' names and occasionally addresses. Storing them at scale is a materially different activity from one person reading one record, and it is the point at which a business-verification file starts to look like something else.

The defensible default is to hold entity-level fields only. Almost every question a counterparty check has to answer can be answered without a single personal field.

Where a name genuinely matters, store the finding, not the person: "signer named on the certificate supplied on this date" carries the decision without building a roster.

Which of your own uses are regulated depends on the relevant rules, not a page like this. The Federal Trade Commission's guidance for businesses is a sensible first stop. When personal information about California residents is involved, assess whether the California Consumer Privacy Act, as amended by the California Privacy Rights Act, applies. If the check uses a consumer report about an individual, the Fair Credit Reporting Act may also apply, depending on the use; an entity registry entry alone is not automatically a consumer report.

Decide the personal-field question before ingestion, not after. A pipeline that collected everything and filters on display has already stored everything.

Evidence, and how much of it

Save the page as a file rather than a screenshot where you can, with the retrieval date in the filename. For a document you opened, save the document and its reference, because the index row is a label written by the office and not a statement of what the document says.

Retention is a policy and legal decision; set it deliberately, not by disk space, and keep evidence at least as long as the exposure it supported.

Keep old captures when you re-check. They are the only record of what a register showed on a past date, and the live page has no memory of its own previous states.

Refreshing without destroying history

Re-checks add rows. They never overwrite them. A refresh that replaces the status field with today's value loses the fact that the status was different in March, which is exactly the fact a dispute will turn on.

Tie refresh to the entity's report cadence and to your own triggers, and record "no change" explicitly with its date. The registration status row is the one to refresh most often and the one never to let an automated decision read from cache.

For California entities, the California Secretary of State's Statement of Information filing is a named refresh source. Check the entity's filing record and applicable filing cycle rather than assuming one schedule fits every entity type.

If any of this is automated

Everything above holds, with two additions. Store the raw response beside your parsed fields. If a field's meaning differs from your assumption, the raw payload is the only way to repair history.

Make the pipeline distinguish "no match" from "no answer." A source returning an empty result under rate limiting will otherwise fill your table with clean-looking nil results for entities that exist.

Licensing and access questions that come with automation are their own subject, covered in public data APIs. Where a register documents a programmatic interface, its documentation is the authority on field meanings.

For US public-company filings, SEC EDGAR APIs are a named programmatic source, but they do not replace a state entity registry for state registration status. The Companies House developer overview is an example of a register naming what it promises to keep stable. Where a jurisdiction publishes an open-data catalog, its own guidance on APIs shows the difference between a supported interface and a scraped search page.

What the record is for

Kept this way, the file answers three questions on demand: what did we know, when did we know it, and what did we never establish.

A colleague needs that to continue the work, a reviewer needs it to judge the work, and you need it if a decision made from it is questioned. The judgments stay in company verification. This container makes them auditable.

Common questions

Is a folder of screenshots really that bad?

Undated, yes. A screenshot with no retrieval date and no source path proves that a page once looked a certain way to somebody. Adding the date and the source turns the same file into evidence.

Do I need a database for this?

No. A spreadsheet with the columns above, one row per finding, handles a surprising volume. The shape matters far more than the tool.

How do I record a check that was inconclusive?

As a row, with the outcome "not established" and a note saying what would have settled it. Inconclusive is a real result, and it is the one most likely to be repeated pointlessly if nobody wrote it down.

Should the file record who did the check?

Record it if your process needs to be reviewable, and treat it as a fact about your own staff rather than about the counterparty. It belongs to your side of the record and follows your own rules on staff data.