Test company data is a made-up business entity, written down in full. It is a company name, a legal form, a registration number, a tax number and a VAT number, a registered office, a contact telephone number and a handful of smaller fields, assembled so that software can be exercised on a record that looks like an ordinary trading company without describing one that exists.
This article explains what such a record is actually for, why borrowing a real company’s details is a bad trade in both law and engineering, which parts of a business need it, and what a generator on this site does and does not guarantee about its output.
What test company data actually is
Strip away the vocabulary and a company test record is just a coherent set of answers to the questions a business form asks. Somebody is applying on behalf of an organisation. The organisation has a name and a declared legal form, it is registered somewhere, it has been assigned whatever identifiers that place issues, and it has a place of business.
Coherence is what separates a usable record from a pile of strings. The registration number belongs to the registry of the country in the address, the VAT number carries the prefix of that same country, the legal form is one that the jurisdiction actually recognises, and the telephone number carries the right calling code. A record assembled field by field usually fails at exactly this point, because each field was judged on its own.
Provenance is what separates a test record from a real one. Nothing in it was copied from a company, and nothing in it belongs to a company. It has the shape of a business so that a system can process it, and no referent outside the test.
Where does a team genuinely need business records of this kind?
The demand is larger than it first appears, and it clusters around one requirement: give the software plausible input while the output lands somewhere harmless.
| Situation | What is impossible without generated records |
|---|---|
| Onboarding form testing | Required-field and length rules cannot be exercised end to end |
| Invoicing rehearsal | Tax and registration fields cannot be tried on a document that nobody receives |
| Sandbox integration | A partner’s test environment needs a counterparty that is not a real client |
| Demo and sales environments | The product looks unfinished when every record reads as placeholder text |
| Bulk seeding | Volume testing needs many thousands of rows that still look plausible |
| Regression fixtures | Assertions drift if the same test produces a different company each run |
The list also shows why the shape of the record matters more than a developer expects. A sandbox integration is judged by whether the partner’s validation accepts the payload. A demo is judged by whether a prospect can read the screen without noticing anything odd. Neither goal is served by injecting a real company’s identifiers.
Why is using a real company’s details the wrong move?
Because a real company’s registration number, tax number and officers are personal and commercial facts that belong to somebody else, and lower environments are where the weakest controls tend to be.
Two failures follow. The first is legal and reputational. Holding yourself out as another business is misrepresentation, and under data protection rules a sole trader’s registration details plus a contact name can be personal data too. Moving those facts into a development environment is a new use of them that nobody agreed to. The second is operational: the copy then survives in backups, in query logs, in screenshots pasted into tickets and on the laptops of everyone who restored the database. The organisation ends up with more copies of one company’s details than it ever had before, in places nobody audits.
There is a third, quieter cost. A test built on one real company only ever sees that company’s shape. Real portfolios contain short names, very long names, ampersands, accented characters, trading names that differ from the registered name, and entities with no VAT number at all. A generated set can cover that spread deliberately, which a borrowed record cannot.
What does a complete company record contain?
On this site, the test company data generator builds the whole entity in one step rather than one field at a time. A record carries four groups of fields.
- Identity — the registered name, the legal form and the industry or activity description.
- Registration and tax — the company registration number, the tax identifier and the VAT number where the country issues one, each in that country’s own shape.
- Registered office — street, district, city, administrative division, postal code and country, following the real address conventions of that country.
- Contact — a telephone number carrying the correct international prefix, plus associated administrative details such as the size band or incorporation indicators the country publishes.
Two properties are worth understanding before you rely on the output. The first is internal consistency, as described above. The second is reproducibility: output is driven by an identity key, and the same key with the same country yields exactly the same company every time. Reproducibility is what makes a generated record usable inside an automated test rather than only inside a manual walkthrough. The field consistency question is really a question about generation order, and the legal forms article explains why country has to be decided before anything downstream of it.
Does generated company data need to look real?
It needs to look ordinary, which is a weaker requirement — and the difference matters.
An obviously fake record is easy for a reader to dismiss but easy for a validation rule to reject for the wrong reason. A record that looks exotic tests the wrong thing: if every generated company name is a single syllable, or every street line is the same placeholder phrase, the layout is never stressed and the validation never fires. Generated records earn their keep when they land in the same shape as the real submissions the system will eventually receive, including the awkward ones — long legal names, accented characters, trading names that differ from the registered name, and entities that legitimately have no VAT number.
Ordinary is not the same as valid-in-the-world. A synthetic registration number of the right shape is still not registered anywhere. It will pass a format check and fail the moment a process consults the registry behind it. That is a feature, not a defect: the boundaries of synthetic company data are exactly what keep a test record from being mistaken for a real one.
For developers: designing the record
Model the record as fields with dependencies rather than as a flat table of independent columns. Country constrains the address shape, the registry, the identifier format and the telephone prefix. Legal form constrains the name suffix and the set of identifiers that may exist at all. A schema that hides those relationships will admit inconsistent rows no matter how careful the fixtures are.
Three habits prevent most damage. Give the record a stable key so it can be regenerated on demand instead of being copied between environments. Treat a missing identifier as absent rather than filling the field with a plausible string, because an empty field and a wrong field fail in very different places. And never let a test record cross into production: keep generated entities in their own database or schema, tag them at the row level if a shared environment forces it, and keep the fixture files themselves labelled as synthetic.
The note that ships with the fixtures is part of the design. Say plainly in the file, and in any export the tool produces, that these companies are fabricated for testing, that no real business is described, and that the records must not be used to open accounts, obtain licences, issue real invoices or stand in for an actual counterparty.
Next steps
Pick one form in your product that asks for company details and fill it with a generated record instead of the placeholder text that is probably sitting there today, then submit it twice with the same identity key and confirm the two attempts produce identical values. If they differ, you are looking at a generator that cannot support automated assertions, and the company registration number article explains what to ask for instead. For teams seeding a staging database at volume, the seeding walkthrough covers the same problem at scale.