A company data generator produces the set of fields a business onboarding form asks for — a legal name with the right suffix for its jurisdiction, a registration number, a tax identifier, an address, and often a legal form and a contact — arranged so that the parts agree with one another. The difficulty is not inventing a company name; it is keeping a dozen interdependent identifiers consistent with a single jurisdiction.
This guide covers how corporate naming conventions change between countries, why registration and tax numbers follow different rules than most teams expect, which fields a KYB flow actually needs, and what a generated entity can never be used for. By the end you will know which consistency checks belong in your own test suite and which assumptions about corporate data are simply wrong.
Why do company names carry jurisdiction in the suffix?
The suffix at the end of a company name is not decoration. It identifies the legal form under which the entity exists, and it is compulsory in most jurisdictions. A German limited liability company carries GmbH, a French or Spanish company may carry S.A. or S.A.S., a Malaysian company carries Sdn. Bhd., an Australian proprietary company carries Pty Ltd, an American limited liability company carries LLC, and a Turkish joint stock company carries A.Ş.
Because the suffix encodes the legal form, it also constrains the rest of the record. An entity with a GmbH suffix is governed by German company law, so its registration number follows the German pattern, its tax identifier follows the German pattern, and its address sits in Germany. A record that mixes a German suffix with a British registration number is not subtly wrong; it describes a company that cannot exist.
Punctuation and diacritics add a second layer. Several suffixes contain periods, some contain accented characters, and some are conventionally written without spaces. A name field that strips punctuation on input will corrupt a legal name, and a validator that expects a single suffix list will reject the ones it has never seen. The company name suffixes by country article collects the common forms and their conventions.
How registration numbers and tax identifiers differ
A registration number is issued by the company registry of a specific jurisdiction. Its length, its format and whether it contains letters all vary. Some registries use a pure numeric sequence, some embed a year or a district, and some issue an alphanumeric string. There is no international standard that makes these numbers interchangeable, and a system that stores them in one field with one validation rule will reject valid inputs from most of the world.
A tax identifier is a different number issued by a different authority, and conflating the two is one of the most common modelling errors in onboarding systems. In many countries a company has both a registration number and a tax number, they have different formats, and they appear in different fields of a form. A record that fills both fields with the same value is internally inconsistent, even though each value is plausible on its own.
The VAT identifier adds a third variant. Within the European Union it usually begins with a two-letter country prefix followed by the domestic tax number, and the prefix must match the country of the address and the registration. The VAT number formats by country article shows the range of shapes involved, and the tax ID validation rules article covers the checks that distinguish them.
What about LEI and D-U-N-S identifiers?
The Legal Entity Identifier is a twenty-character alphanumeric code assigned to entities that participate in financial transactions, and it is globally unique. It is not a registration number and it does not replace one; it is an additional identifier that a financial counterparty may request. Its structure includes a local operating unit prefix, a reserved section, and two check digits computed to a published standard.
The D-U-N-S number is a nine-digit identifier issued by a commercial data provider, used widely in credit and supplier assessments. It is not a government identifier, and it exists only for entities that provider has recorded. Treating it as mandatory in a form will exclude most businesses in most countries.
Both identifiers are worth having in a test dataset because their length and character rules are distinctive, and because their presence in a form changes the validation path. But a generator should be explicit about whether the LEI it produces satisfies the published checksum, since a well-formed-looking LEI with a wrong check digit will fail at exactly the point you were trying to test. The business identifiers article goes through both in more depth.
Which fields make a KYB record coherent
A know-your-business flow asks for an entity’s legal name, its jurisdiction and legal form, its registered address, its registration number, its tax identifier, its representatives, and often its ownership structure. The coherence requirement is that these fields describe one entity in one place.
That means the jurisdiction governs the naming convention, the registration number format and the tax number format. The registered address sits in the same country, and if it sits in a subdivision, the postal code must match that subdivision. The representatives carry names and addresses appropriate to the jurisdiction, and the founding date precedes any document the entity signs. The two numbers are separate facts and a form that conflates them will accept a tax identifier in the registration field, which is a defect that only appears when a jurisdiction uses one for both. The company registration number by country article lists the formats that a coherence check has to enforce.
Coherence also has a direction. Changing the jurisdiction should pull every dependent field with it, so a test that switches the country on an existing record is testing more than a label. In practice most forms do not do this, and a stale registration number is left behind under the new country, which is exactly the kind of defect a coherent dataset surfaces in one run rather than in production.
The field that most often breaks coherence is the address, because it is the one teams reuse from a person record without adjusting the country. A German company with a British postcode is an obvious defect that a nested validator catches immediately, and the same logic applies to the telephone country code on the contact record. The KYB testing checklist article sets out the checks in the order a real onboarding pipeline applies them.
There is also a set of fields that many systems add and that have no universal format at all: number of employees, annual revenue, industry classification, and website. These are free-form or classification-based, and a test dataset should vary them deliberately rather than leaving every generated entity identical in size and sector. Varying them matters because validation logic that never meets an unusual value is validation logic that has never been exercised.
Are generated companies real entities
They are not. A generated company has a legal name with a valid suffix, a registration number in the right format, a tax identifier in the right format and an address in the right country, and none of it is registered anywhere. There is no filing behind the registration number, no tax record behind the identifier, and no entity behind the name.
That property is what makes the data safe to use. Because the company does not exist, no third party can be harmed by the record, no credit can be extended against it, and no counterparty can be misled if the record is clearly labelled. It also means that any check that consults a registry will fail, which is the correct outcome and should be the expected behaviour in a test. A generated business name should therefore also avoid colliding with a real one, and the simplest safeguard is to keep generated names obviously generic rather than plausible enough to be searchable.
The boundary is worth stating plainly in the dataset itself. Records of this kind are synthetic business data, they correspond to no registered entity, and they must not be used to open a real account, to pass a real KYB or credit check, to obtain goods or services on credit, to send payments under a false name, or to represent any real business.
Where a generated company is combined with a generated person as its representative, the whole record remains synthetic, and the same prohibition applies to the combination. A record does not become usable for a real transaction because it is internally consistent; internal consistency is a testing property, and nothing more.
What should your B2B form tests cover
Test the jurisdiction and legal form pairing first, because it drives everything else. Select a country, confirm that the offered legal forms are the ones that country recognises, and confirm that the suffix in the name field is validated against the selection rather than left free.
Test the registration number field against several countries in the same run, with one value that is the right length and one that is too short. This is where a single hard-coded rule reveals itself, because the field will reject the valid foreign number rather than the invalid local one.
Test the tax identifier as a separate field with its own checks, including the country prefix where one is expected, and confirm that the form refuses a number whose prefix contradicts the selected country. The billing form test cases article extends this into the payment-adjacent parts of the flow, where the company record meets an invoice.
Test the order the fields are presented in as well, because a single global form imposes one sequence on every jurisdiction and that sequence is wrong somewhere. A field that is mandatory in one country and meaningless in another will be marked required for both, and the resulting friction is a defect that users report as confusion rather than as a bug. The legal forms by jurisdiction article maps the country and legal form pairings that a test matrix should cover.
Then test the fields that are free-form. A legal name with an ampersand, a name containing a period from an abbreviation suffix, a name at the length limit and a name one character beyond it together cover most of the ways a name field breaks. The company generator on this site produces records across these jurisdictions with the identifiers kept consistent, so that a single exported row can be used as a coherent fixture rather than assembled by hand.
Every record produced this way is synthetic test data for software testing only. It describes no registered or trading entity, it confers no legal existence, and it must not be used to impersonate a business, to open or register real accounts, to obtain credit or goods, or to pass any real corporate verification.