A buyer tax identifier identifies the customer for a tax purpose, while an electronic address identifies it within a defined electronic invoicing or delivery arrangement. A particular scheme can use a familiar registration value, but that relationship must be established by the actual specification and recipient instruction. Do not assume that typing a VAT number also supplies a valid endpoint.
The buyer-information workflow keeps identity, references and delivery details distinct. This separation is useful even when the customer sends every number in one onboarding document. The same-looking value can have different roles, checks and required metadata.
Label the tax identifier accurately
Obtain the value and its purpose from the customer’s confirmed information and appropriate sources. A company registration number, tax registration and customer account code are not interchangeable. If the tax identifier is unknown, ask for clarification instead of substituting another number from the purchase order.
Keep meaningful prefixes and characters according to the relevant instruction. Do not infer registration or transaction treatment merely from a number’s shape. A well-formed value can still belong to another entity or be unsuitable for a particular use.
The current creator has a general buyer tax-ID field and performs no registry lookup. Recording a value there is a preparation action, not evidence that the customer is registered or that the tax treatment of the supply has been determined.
Label the electronic address separately
Ask the customer’s technical or billing contact for the complete endpoint or participant instruction where applicable. Record the value, relevant scheme and intended route. Preserve the source so the final software provider can assess whether its implementation supports that arrangement.
OpenPeppol’s published buyer electronic-address field illustrates a specified address role with scheme requirements. That is a profile-specific representation, not permission to put any buyer identifier in any address field. The final system must use the representation required by its actual specification and version.
A billing email may also be useful, but its communication role does not automatically make it an endpoint. The billing-email and endpoint comparison explains why those values should remain distinguishable when the customer uses a separate submission process.
Avoid guessing from a familiar number
For a fictional buyer, an onboarding sheet might show a tax number, an electronic addressing value and a purchase order. The invoice preparer should not choose the tax number for every field because it is the one identifier already stored in an old draft. Each value needs its own role and confirming instruction.
If a recipient says that its electronic address is based on a registration value, ask for the exact scheme and representation. Do not invent a prefix, remove characters or join codes based on examples from another customer’s system. A formatting shortcut can change the identifier’s meaning.
If the instruction does not state the scheme or route clearly, leave that requirement unresolved and ask the appropriate contact. A known tax identity can coexist with an unknown technical destination. Treating them as the same fact hides the remaining work.
Distinguish the checks performed
A tax-registration service can answer a defined registration question within its scope. A network or participant lookup can answer a different addressing question. Neither should automatically be reported as proof that the invoice itself meets a structured standard or that the customer accepts the amount.
The current product performs neither kind of external lookup. Its input validation cannot confirm a tax identifier’s registration, endpoint availability or the association between a value and the selected buyer name. An entered value and a verified value must therefore remain different statuses in the preparation records.
If an external check produces an unexpected result, retain the queried value, source and relevant response and follow the service’s official guidance. Do not change identifiers repeatedly until a favourable status appears. Resolve the underlying fact with the appropriate authority or customer contact.
Recognise the current representation limit
EInvoiceCreator provides buyer name, address, country, tax ID and optional email, alongside one general buyer reference. It does not implement a complete typed buyer-endpoint model or a network delivery connection. Placing an endpoint in the tax-ID or email box can mislabel the data rather than complete the missing feature.
Keep additional scheme and addressing information in the preparation record for supporting software. A readable note can preserve context for a person, but a final recipient profile may need dedicated structured elements. Application-owned JSON does not become that profile merely because the values appear somewhere inside it.
The line-items CSV has a narrower scope and does not carry the complete buyer record. Check the chosen output’s contents rather than assuming that every field visible in the preview is included in every download.
Make the hand-off unambiguous
Identify the confirmed buyer entity, tax identifier, electronic address, scheme, billing email and intended delivery route as separate labelled facts where relevant. Mark missing or unverified values without disguising them as optional or not applicable.
The next operator can then generate and validate the required document using appropriate supporting software. Clear preparation does not itself establish delivery, standards conformance or government acceptance. It establishes that the right values and their meanings are available for the work that remains.