How to Prepare Seller Details for a Structured E-Invoice

Prepare seller details by identifying the business or person supplying the goods or services, confirming the relevant name and address, and keeping registration, tax and contact information in their proper roles. Do not build a supplier identity by copying whichever logo, account name and email happen to be most convenient. The fields should describe one coherent seller for the actual transaction.

EInvoiceCreator currently records a seller name, address, country, tax identifier and optional email. It does not verify a registry, authenticate the business or provide every identifier structure needed by external invoice profiles. This guide explains how to prepare reliable information for those fields and how to preserve requirements that need supporting software.

Establish who supplied the transaction

Use the agreement, order and business records to identify the supplier. A brand can be operated by a separate business entity, and several branches can trade under a shared presentation. A customer recognising the brand does not necessarily tell you which entity should issue the invoice.

Resolve uncertainty before entering the final values. If the business has recently changed its name, structure or registration, ask the appropriate authorised person which details apply to this supply. Do not automatically replace an older contracting entity with the latest name seen on a website.

The business-name and trading-name distinction helps separate supplier identity from commercial presentation. In a particular structured profile, those names may have different fields or uses. Check the target requirements rather than joining several names into a string that nobody can later map confidently.

Keep names consistent with identifiers

A name and its identifiers should refer to the same supplier. A registration number belonging to one company should not sit beneath a related company’s name merely because the firms share an office or bank account. Matching an identifier’s appearance is not the same as establishing its relationship to the seller.

OpenPeppol’s published UBL binding describes the seller-name business term as the formal name by which the seller is registered or otherwise trades in the relevant sense. That is an example of a specific field meaning in a documented profile, not permission to assume that every name displayed in a design template is an appropriate seller name.

Retain the trusted source of the name and any confirming identifier. If a customer asks for an additional supplier account number, label it as the customer’s reference rather than treating it as a tax identifier. The preparation record should preserve the distinction even if the current editor lacks a dedicated field.

If a source uses more than one language, agree the representation needed by the recipient and preserve the original spelling in your records. Do not replace a business name with an informal translation merely because it fits an English-language preview.

Structure the address without changing its meaning

Collect the address that belongs in the seller record for the applicable transaction and requirement. Distinguish the registered, trading, branch and correspondence addresses where they differ. Do not choose one solely because it looks better on the printed page or resembles the delivery address.

Use separate source components for street information, locality, postal code, region where relevant and country. The current application stores its address as multiline text, with country selected separately. A readable block is useful for the preview, but an external mapping may need those source components individually.

The seller-address preparation guide explains how to avoid losing apartment, building or locality information while making a readable block. International addresses do not all follow the same line order or postal-code pattern. Preserve the confirmed address rather than forcing it into assumptions borrowed from another country’s example.

Distinguish registration and tax information

A company registration number and a tax identifier can serve different purposes. Some invoice workflows require typed identifiers and scheme information, not just an unlabelled number. Obtain the actual value and its purpose from an appropriate source rather than inferring the role from length or punctuation.

The current creator has one seller tax-ID field, not a full collection of legal registration and electronic-address fields. Do not put several unrelated identifiers into that field and report that the final standard is satisfied. Keep an additional preparation record for data that a downstream mapper must represent separately.

Entering a tax identifier does not determine whether the seller must charge a particular rate. A registration check, transaction-specific tax decision and invoice-field entry are separate activities. Where applicable, an official check or professional advice can help resolve the relevant question; the browser form does not perform those checks for you.

Use contact details for their actual purpose

Enter a contact address that the recipient can use for invoice questions when that is appropriate. The billing email may differ from a sales email or the personal address of the person doing the work. Confirm which contact should appear before copying an email signature.

A contact email is not automatically an electronic invoice endpoint or a participant identifier. Keep network and delivery information separate in the preparation records. Likewise, naming a bank in the payment section does not establish the business name or replace the seller’s identity.

Consider what information is necessary to share. A sole trader may need to handle personal contact and address details carefully while still meeting applicable invoice requirements. Do not omit required information solely for presentation reasons, but do not add unrelated personal data merely because a form provides space.

Review a coherent fictional example

Suppose “Willow Print” is a trading label used by the fictional business “Willow Workshop Ltd”. The agreement identifies Willow Workshop Ltd as the supplier, its records provide a confirmed address, and its accountant confirms the relevant tax identifier. An invoice preparation sheet should retain that relationship explicitly rather than selecting only the shorter logo text.

If a branch dispatches the goods, record whether the branch address is relevant separately from the supplier identity. If the customer’s supplier record uses a different name, resolve the discrepancy with the buyer before export. A clean-looking preview should not become the place where inconsistent records are silently reconciled by guesswork.

The seller-information checklist provides a final review sequence covering identity, address, identifiers and contact details. Use it after entering the data, especially if several people supplied different parts of the information.

Preserve consistency through revisions

When a seller detail changes, identify the supporting source and update the working draft deliberately. Review dependent information rather than changing a name in isolation. A new address may affect more than the preview, while a new entity can raise questions about identifiers and the underlying agreement.

Do not retroactively rewrite an issued invoice without following an appropriate correction process. The current creator is a preparation workspace, not a system that maintains legal issuance status, historical seller versions or an accounting audit trail. Keep reviewed exports and source records distinguishable from editable drafts.

Recognise what the creator can check

The application requires a seller name and address and checks supported country choices and the shape of an optional email. It cannot determine whether the address is correct, an identifier is registered or a person is authorised to act for the business. Passing the field checks establishes completion of those application inputs only.

You can enter the confirmed seller details in the invoice creator and inspect how they appear alongside the buyer and invoice lines. Its printable output and own-schema JSON can help with preparation and review. Recognised-format mapping, registry verification and formal validation require separate implemented tools and the relevant recipient specification.

Keep any unresolved identity question visible until it is answered. Accurate seller preparation is successful when the named supplier, identifiers, address and evidence describe the same business, not simply when every available box contains text.