A company name, compared to a state file number, makes an unreliable lookup key

Company names are terrible database keys. They change, they repeat, they get punctuated four different ways, and two unrelated businesses in two states can hold the same one legitimately. Anyone who has tried to reconcile a supplier list against registry records has met all four problems in an afternoon.

The identifier assigned by the filing office is the fix. It is the one field on the record that stays put while everything else moves, and building your own records around it rather than around the name removes a whole category of error.

What to take away

Why names fail

Suffix and punctuation variation. Inc, Inc., Incorporated, Corp, Corporation, LLC, L.L.C., Limited. The same entity is written every way across contracts, invoices, and your accounting system. Exact-match search rejects all but one.

Articles, ampersands, and spacing. "The", "and" versus "&", hyphens, and doubled spaces are all places where the string you have and the string the office holds diverge.

Reuse across states. Name availability is decided state by state. The same name can be validly registered in several states by entirely different owners. Without a jurisdiction, a name is ambiguous by construction.

Names change; entities persist. A company that rebrands keeps its file number. Search by the new name and the old contracts look like a different company. Search by the old name and you may find nothing.

Trading names are not legal names. The name on the sign, the invoice, and the register are three separate strings, and only one of them is in the entity index. Which index holds which string is the whole subject of business name search.

The state file number

Filing offices assign each entity an identifier when it is created on the register.

Labels vary: entity number, file number, registration number, charter number, and control number, among others.

Format varies widely: pure digits in some states, letters and digits in others, sometimes with a prefix encoding entity type or year.

Two properties make it valuable. It is assigned by the office of record rather than by a vendor. And it survives name changes, address changes, management changes, and in most cases reinstatement after a lapse.

Two properties limit it. It is state-specific, and it is not universal in format, so you cannot validate one by pattern-matching.

There is no national company number

This trips up anyone building a supplier or customer database. A company incorporated in one state and registered to do business in four others will hold five distinct identifiers: one from its home state and one from each state where it qualified. They are unrelated numbers issued by unrelated offices.

The US has no single government identifier covering ordinary US companies like a national company number elsewhere. Federal identifiers serve specific purposes, such as the unique entity identifier issued for federal contracting.

Each covers only entities that take part in that purpose. Any system you design must key on jurisdiction plus identifier as a pair, never on the identifier alone.

Other identifiers, and what each is actually for

People routinely accept one identifier as proof of something a different identifier would establish. Here is what the common ones do and do not do.

Two consequences worth stating plainly.

An EIN is not proof of registration. It is a tax account identifier obtained from the revenue agency through its own process, as the IRS page on the employer identification number sets out. You normally get it from the counterparty on a tax form rather than from a public search, because it is not published for most private companies. A business can hold one while its state registration status is revoked.

A vendor identifier is not a registration. Commercial business-data providers assign their own keys to the records they maintain. Those keys are useful for matching inside that provider's data and carry no authority about whether an entity exists on any government register.

Never treat an identifier from one system as validation in another. Match on the file number for registry questions, and go to the responsible agency for everything else.

Working from a number you were given

Someone hands you a number and it does not resolve. The usual causes, roughly in order of frequency:

If you have a name and want the number, search broadly rather than exactly. Drop the suffix, use the most distinctive root word, and accept a longer result list you can narrow by city or formation date.

Exact-match searching on a full legal name is the most reliable way to find nothing. secretary of state search goes through the rest of that technique.

Recording standard

Store these together, as one unit, every time:

An identifier without its jurisdiction is meaningless. An identifier without the name it belonged to cannot be audited. A record without a date cannot be trusted a year later.

If you maintain a supplier or customer master, add a jurisdiction field before you add an identifier field. Systems that store "registration number" as a single string end up with a column containing five kinds of number from four kinds of agency, and no way to tell which is which.

Using the number well

Once you have it, the number is what you quote back to the office. You also use it to pull the filing history without ambiguity.

You write it on the contract alongside the legal name, so next year's re-check lands on the same entity, not a lookalike.

That is the real payoff. Names are how humans refer to companies; identifiers are how records refer to them. Keep both, but key on the number, and note the jurisdiction that gave it meaning. The rest of a verification routine gets considerably easier once every entity in your file has a stable handle.

Common questions

Can I tell which state a number came from by looking at it?

Not reliably. Formats overlap between offices and change within one office over time, so a number alone does not identify its issuer. Go back to whoever gave it to you and ask which office issued it.

Our system has one field called registration number. Is that a problem?

Yes, and a common one. That column will end up holding tax accounts, license numbers, vendor keys and file numbers from several states with no way to tell them apart. Add a jurisdiction field and an issuer field before you add another row.

The number is right but the name beside it is different. What happened?

Most often a name change, which the number survives on most registers. Check the filing history for the change before assuming the number is wrong, then look at whether the register reissued it.

Should the file number go on the contract?

Yes, with the state. It is the one identifier that will still resolve to the right record after a rebrand, and it costs nothing to add next to the legal name.

What do I do when a counterparty has no number to give?

Find it yourself from the register once you know the legal name and state, and record where you got it. A counterparty who cannot name their own state of formation is worth a second question.