Company registration number formats by country: validation without false matches

Company registration number formats by country are useful because they stop obvious input errors before a KYB, supplier-risk or credit workflow wastes time on a bad lookup. They are not enough to verify a company. A valid-looking identifier can still belong to a different entity, a different register, a tax authority rather than a company register, or an entity whose status has changed since a snapshot was downloaded.

The immediate implementation decision is therefore narrow: validate the format early, then verify the claim against the right source. A format check can answer, “could this be a plausible identifier for this jurisdiction?” Verification must answer, “did this identifier resolve to the legal entity we intend to rely on, at this source and retrieval time?” Those are different controls.

This article uses company registration number in the corporate-registry sense: the identifier assigned by a business or company register to a legal entity or registered entity. It does not use the term as shorthand for a tax ID, VAT number, employer number, payment identifier or Legal Entity Identifier, although those may be relevant in adjacent checks.

A company registration number is best modelled as an asserted registry identifier, not as a complete identity proof. The identifier becomes useful only when it is tied to a jurisdiction, issuing register, legal name, source record and retrieval date. Without those fields, a downstream reviewer sees a number but cannot know what system issued it, what it proved, or whether it was current when used.

The difference matters in the United States because company formation is state-led. A Delaware file number is not a national company number; it is an identifier in a state system. That system can return an entity name, file number, formation date and registered-agent details, but even a real-time lookup still needs a separate judgement about whether the matched entity is the counterparty in the contract or onboarding form.

It also matters outside the United States. Australia distinguishes a nine-digit company number issued to companies from an eleven-digit business number used more broadly. France distinguishes an establishment identifier from the legal-unit component inside it. Hong Kong moved existing entities towards a business-registration-number-based unique identifier, with dummy numbers for certain entities without a business registration record. A single field called “registration_number” cannot safely represent all of these meanings without type and source context.

A practical answer to “what is a company registration number” is therefore: it is an official or registry-issued identifier that may support legal-entity matching when paired with the issuing jurisdiction and source. It does not, by itself, prove ownership, authority to sign, solvency, sanctions status, tax registration or suitability for a transaction.

Current competing pages answer the lookup question reasonably well. They give long country lists, examples and common labels. Some distinguish company identifiers from VAT or tax identifiers; others mix tax, registration and platform-verification formats because their product use case is payment onboarding or indirect tax validation. That is useful reference material, but it leaves an enterprise implementation question open.

The unanswered question is: what should the system do after the value matches a format? A form validator can accept “123456789” as a plausible nine-digit identifier in one market, but the same shape can appear in tax, company, establishment or internal account-number contexts elsewhere. If the workflow then stores only the submitted string and a green tick, it has lost the evidence needed to explain the decision later.

The stronger pattern is to treat format validation as a pre-check in a longer evidence chain. Keep the raw submitted value, the normalised value, the country selected by the user, the inferred identifier type, the source queried, the returned legal entity and any unresolved state. If a source is unavailable, record unavailability. If the source returns a different name, record a contradiction. If the value is plausible but the jurisdiction is ambiguous, ask for the issuing register or a supporting extract instead of silently choosing one.

That distinction is also where CompanyProof’s evidence-led approach is relevant: the claim, observed value, source context and retrieval time should remain separate. The aim is not to turn every identifier into a legal conclusion. It is to make the downstream decision explainable and reversible when better evidence arrives.

Consider a hypothetical procurement workflow reviewing “North River Analytics Pty Ltd”, said to be incorporated in Australia. The supplier enters “36 123 456 789” in a field labelled company registration number. A simple numeric rule accepts eleven digits after removing spaces. The value looks orderly, and the supplier’s invoice uses the same number.

The correct next step is not to mark the legal entity verified. In this hypothetical, the eleven-digit value resembles a business number, while the company register uses a nine-digit company number for companies. The workflow should ask whether the last nine digits are the company identifier, search the company register with the appropriate identifier or name, and store which identifier type resolved. If the company record returns the same legal name, the evidence supports legal-entity matching for that source and time. It still does not prove who owns the company or whether the person who submitted the form can bind it.

Now change the example. The same supplier enters a nine-digit value, but the returned registry record shows a different legal name, while the trading name on the invoice is unchanged. That is not a missing-data case; it is a contradiction or possible entity mismatch. A safe implementation pauses approval, asks for the exact registered entity or evidence of the trading relationship, and prevents payment-account approval from inheriting a weak entity match.

For real workflows, add the source and retrieval date to the record. For example: entity submitted by user; jurisdiction selected as Australia; identifier type inferred as company number; source retrieved on 2026-10-08; matched legal name; result state supported, contradicted, unavailable or unresolved. The evidence record should also state what the check does not establish: beneficial ownership, financial health, sanctions status, tax registration and authority to sign remain separate checks.

If the user asks how to find company registration number evidence, start with the jurisdiction and register, not the number shape. A name search can be useful, but name search is vulnerable to trading names, old names, punctuation and group-company confusion. An identifier search is sharper, but only if the identifier type is right for the jurisdiction and entity form.

The operational sequence is simple. First, capture the country or state of formation separately from the operating address. Second, identify the register expected for that entity type. Third, normalise only safe separators such as spaces or hyphens where the relevant source permits them. Fourth, retrieve the record and compare the returned legal name, jurisdiction and status with the submitted counterparty. Fifth, preserve what was checked and what remains unresolved.

Do not treat a monthly bulk snapshot as the same evidence as a live lookup. A current download can still describe data compiled at a previous cut-off, while a live register search can have terms, rate limits or fields that differ from the bulk file. This does not make snapshots useless. It means a product should store whether the value came from a snapshot, a live search, a customer document or a data provider, and whether a later refresh is needed before a decision can rely on it.

Where can I find company registration number evidence? Usually in the relevant official registry record, incorporation extract, certificate, filing history or company-data snapshot. For higher-risk decisions, store the source record or reference and the retrieval date, not only the number copied into the form.

The following checklist is deliberately stricter than a format table. It is designed for product, KYB, supplier-risk and credit teams that need an evidence trail rather than a polished input field.

• Create separate fields for submitted value, normalised value, identifier type, issuing register, jurisdiction, source, retrieval time and returned legal entity.
• Apply country-specific format checks before lookup, but return “format plausible” rather than “company verified”.
• Maintain a mapping table for identifier meaning, not only pattern: company number, business number, establishment number, tax identifier, state file number and global identifier are not interchangeable.
• Design states for supported, unresolved, source unavailable, contradictory, wrong identifier type and stale evidence.
• Where a jurisdiction uses multiple identifiers, ask for the source label shown on the document or register rather than forcing one generic field name into the form.

A verifier should not collapse every failed lookup into rejection. Rejection is only one possible outcome. A wrong format, unavailable source, ambiguous identifier and contradictory registry record each require a different user experience and analyst action.

The same rule applies to positive matches. A supported identifier should unlock the next check, not close the file. A supplier can be correctly registered and still fail ownership, sanctions, authority, payment-control, security or financial-stability requirements. Keeping the company registration number finding narrow prevents later teams from treating a registry match as a complete due-diligence conclusion.

• Format invalid: ask for correction before registry lookup and show the expected identifier type in plain language.
• Format plausible but source unavailable: retry, use an approved alternative source, or route to manual review without implying the company is false.
• Record found with matching legal name: store the evidence and proceed to ownership, authority and risk checks as separate tasks.
• Record found with different legal name: stop automatic approval until the counterparty, trading name or group relationship is explained.
• Identifier belongs to a different category: relabel the value if appropriate, or request the correct company-register identifier.

The practical build is a two-layer service. The first layer validates syntax by jurisdiction and identifier type. The second layer resolves the identifier against the expected source and writes an evidence receipt. The receipt should not be a blob of prose; it should be a structured object that another system can recheck.

For example, store: claim type, submitted company name, submitted identifier, selected jurisdiction, inferred identifier type, source queried, retrieval time, returned legal name, returned status, match result, limitations and next required checks. If the source is a bulk dataset, include the dataset date. If the source is a live register, include the retrieval time and any source-stated limits. If the value came from a customer document, distinguish document retrieval from source verification.

This architecture also supports stale-fact monitoring. When a registry changes a name, a dataset refreshes, an identifier type mapping is updated or a source becomes unavailable, the system can reopen only the affected claim. That is better than rerunning a whole onboarding file, and safer than leaving a one-time green tick in place indefinitely.

The outcome is modest but important: company registration number validation becomes a reliable gate in a larger evidence workflow. It catches obvious errors, narrows the lookup and creates an audit trail, while leaving ownership, authority and risk decisions to the controls designed for those questions.