A seller tax identifier identifies a business for a tax purpose, while a company registration number identifies a registration under a particular business-registration system. They are not interchangeable merely because both appear on company stationery. Depending on the entity and jurisdiction, their formats and relationships can differ, and a particular invoice profile may require specific typed identifiers.

Prepare each value with its label, source and purpose. The seller-information workflow treats identifiers as part of one coherent supplier identity. Do not choose whichever number fits a box or copy an old identifier from a related business simply because the seller uses the same brand.

Start with what each number represents

Read the source record’s label instead of inferring meaning from length. A sequence printed near a company name might be a registration number, a VAT number, a customer-assigned supplier reference or another identifier. Preserve the distinction before transferring the value into software.

For a fictional business, the preparation sheet might contain a registration value labelled “company register”, a separate tax identifier and the customer’s supplier account reference. Those are three roles, even if all three values are short strings. Combining them into one unlabelled line makes later mapping and verification harder.

Do not assume that a sole trader has the same registration structure as a limited company. The relevant identifiers depend on the entity and applicable rules. Where a required registration or tax fact is unclear, obtain confirmation from the appropriate records, authority or adviser rather than inventing an equivalent.

Keep the identity relationship clear

An identifier should belong to the supplier represented on the invoice. Shared premises, related owners or a group brand do not justify mixing the tax identifier of one business with the name of another. A consistent set of fields is more important than making the seller block resemble a previous design.

Check meaningful prefixes, punctuation and leading zeros against the authoritative source. Do not strip characters solely because another country’s identifier is usually numeric. A code’s appearance does not establish its validity, and an application accepting the text does not verify registration.

The formal-name and trading-name explanation helps when a number appears under a brand rather than the contracting name. Resolve the relationship between those names and the relevant registration before choosing the final entries.

Distinguish a value from its identifier scheme

Some structured workflows need both an identifier and information describing the scheme under which it is issued. The scheme tells the receiving software how to interpret the value. A number without that context can be ambiguous even when a human recognises it from company records.

Do not invent a scheme or assume that a familiar prefix supplies all the metadata a target profile requires. Check the applicable specification, its code lists and recipient instructions. A general text field in a preparation tool cannot demonstrate that a complete typed identifier has been mapped correctly.

The current EInvoiceCreator provides a seller tax-ID field but no separate comprehensive legal-registration or network-identifier structure. Keep additional values labelled in your preparation records for supporting software. Putting several numbers into the tax-ID field may make them visible in a PDF, but it does not satisfy a profile requiring separate structured elements.

Understand what an external check can establish

An official registry or tax verification service can answer a defined question within its scope. It does not necessarily confirm all the facts needed for the invoice. For example, a VAT-related lookup should not be reported as a universal check of company status, payment account ownership or the correct treatment of a transaction.

Your Europe explains the purpose and limits of VIES for relevant EU VAT-number checks. If a check does not confirm the expected result, follow the service’s guidance and resolve the issue with the business or relevant authority. Do not change the number to a plausible alternative merely to obtain a positive response.

EInvoiceCreator performs no registry or VIES lookup. Its field validation does not confirm whether an entered tax identifier exists. Any external check and its evidence need to remain distinguishable from the application’s required-field result.

Prepare a clean hand-off

For each identifier, record the value, role, source and any scheme information the final specification requires. Note whether it has been externally checked and what that check actually established. If the recipient requests a customer-specific supplier code, keep it separate from national registration and tax identifiers.

When the final format requires information the current model cannot express, hand over the preparation sheet with the source records and recipient instructions. Do not conceal the gap by placing all identifiers in notes and claiming the output is ready for automatic processing.

Review the seller block before sharing

Check that the name, address and identifier all describe the same supplier. Compare the current draft with the confirmed records after any seller change or revision. Look for old sample values and values carried over from a related business.

An identifier is useful because it preserves a specific relationship between a supplier and an issuing system. Keeping that meaning intact through entry and mapping matters more than filling every available box. Where the relationship remains uncertain, retain a draft and resolve the fact before presenting it as confirmed invoice information.