A company registration number is the identifier a registry hands to a business when it is entered on the register, and it is the handle everyone else uses to find that business again. It is also the field that breaks the most forms, because teams keep writing validation against the one country they know and then discovering that nothing about the number is universal.
This guide explains what the number is, why its shape varies so widely, why a strict format rule so often backfires, and how to design a field that accepts the world instead of one postcode.
What a company registration number actually is
When a business is registered, the registry — a companies house, a commercial court, a trade register, a revenue authority, depending on the country — records it and gives it a number. From that moment the number is how the company is cited: on invoices, in contracts, in filings, in credit checks, in court documents.
The number identifies. It does not describe. You cannot read a company’s industry, size, age or creditworthiness out of it, and you should be suspicious of any claim that you can. A familiar prefix may hint at the registry that issued it, but the digits after it are an allocation, not an encoding.
One more thing worth stating plainly at the top: the number is issued by a public authority for the purpose of registration. It is not a licence, not an approval, and not evidence that the business is in good standing today. Registries also change status — companies get struck off, dissolved, renamed — while the number stays the same.
How does the number differ from country to country?
It differs in basically every respect a developer cares about: whether letters appear, how long it is, whether punctuation is part of it, and whether the country even uses a single national registry.
In some places the number is a run of digits assigned straight from a sequence. In others it carries a letter prefix that codes for the registry, the legal form or the region. Some registers use a fixed width and pad with leading zeros, so the value is really a string even though it looks like an integer. Some countries run separate registers for different legal forms and therefore issue separate number series, and some federations have both a state-level registration and a national identifier, with the two appearing on different documents.
The same country can also be written differently by different people. A registry may print separators that are not part of the number, a bank may quote it with a prefix of its own, and a translated document may transliterate it. None of that changes the number, but all of it changes the string a form receives.
| What varies | Why it matters to a form |
|---|---|
| Presence of letters | A digits-only rule rejects a large share of the world |
| Length | Any fixed-length rule is wrong outside the country it came from |
| Leading zeros | Storing the value as an integer silently destroys it |
| Punctuation and spacing | Formatting must be stripped before comparison, never before storage |
| Register per legal form | One country may answer with more than one valid identifier |
Where do you look a registration number up?
You look it up at the source: the official register of the country where the company says it is incorporated. Everything else — a credit agency, a directory site, a marketplace profile — is a secondary copy with its own update lag.
The practical part is finding the right register. Search for the country’s companies register rather than the company itself, and be aware that many countries publish a free public search while a smaller number charge for documents. Where a country has no free public search, the honest answer to a customer is that the number can only be confirmed on paper or through the authority’s own paid channel.
This is also why verification should be a separate, explicit step in any workflow that needs it. A form can check the shape of a number. Only the register can tell you whether the company exists. Keeping those two checks apart — and telling the user which one failed — is the difference between a helpful error and a mystery.
Why is there no global format to validate against?
Because there is no global registrar. Registration is a national competence, and each country’s law decides what its register records and how it numbers the entries. International standards cover plenty of business data — country codes, currency codes, dates, identifiers for legal entities — but there is no world registration number, and no authority to issue one.
The consequences for engineering are concrete:
- No regular expression should be treated as “the” company number pattern.
- No length limit should be tight enough to reject another country’s numbers.
- No check-digit routine should be assumed to exist; where a country publishes one, it belongs to that country alone.
- No validation failure should be reported as “this company does not exist”.
A test suite that carries these assumptions will pass comfortably on domestic data and fail on the first international customer, usually in production, usually during onboarding.
How strict should validation be?
Strict enough to catch obvious mistakes, loose enough never to reject a legitimate company. Those two goals pull in opposite directions, and the resolution is to validate in layers rather than in one pass.
The first layer is presence and basic sanity: the field is filled, it is not whitespace, it does not contain control characters, and it is within a generous maximum length. The second layer is country-aware shape checking, applied only when you know the country with confidence — and written to accept anything plausible rather than to enforce one country’s grammar. The third layer is the authoritative one: an actual lookup against the register, run asynchronously, with its own outcome.
Layering gives you useful errors. “We could not confirm this number with the register” is actionable. “Invalid registration number” is not, and it is also wrong, because the form has no idea whether the company is registered — only that its input did not match a pattern somebody typed from memory.
For developers: accepting the world’s registration numbers
Treat the field as an opaque string. Store it exactly as the customer entered it after trimming outer whitespace, and store a normalised copy — case folded, separators removed — for comparison and search. Never store it in an integer column, and never let a leading zero be lost in transit through a spreadsheet, a CSV export or a JSON parser that is careless with numeric-looking strings.
Set the maximum length generously; the longest national formats are still short strings, and the cost of a loose limit is nothing compared with the cost of truncating a real number. Allow letters, digits and the separators people actually type, and normalise before you compare rather than rejecting what you did not expect.
Route by country rather than guessing, and make the routing explicit in the data model: a registration-number value without a country is only half a value. Where a country is unknown or unsupported, fall back to the generic checks and say so in the interface instead of inventing a rule.
Finally, keep generated and real values visibly separate in every environment you control. Values produced by the generator on this site are synthetic and belong to no register, and the note that accompanies them says so. The VAT number article covers the neighbouring field, which has the same layered-validation problem and its own trap: a format check and a register check are two different questions.
Next steps
Take the registration-number field in your own product and try it against a handful of countries whose formats you have never seen. If anything rejects a value you cannot personally prove is malformed, loosen the rule and move that judgement into the lookup step, where it belongs. Then generate a few synthetic companies in the test company data generator and confirm the field survives copy, paste, export and reimport without losing a leading zero.