Put the customer entity being billed in the buyer identity fields, and treat a billing contact as the person or team handling communication about that invoice. A contact can work for the buyer, a group service centre or another authorised organisation. Its name and email do not by themselves establish which legal business ordered the supply.
Confirm the relationship using the agreement, order and current billing instructions. The buyer-details preparation workflow keeps identity, address, references and delivery information separate. This article focuses on the common mistake of treating a familiar person or inbox as the complete buyer record.
Start with the purchase relationship
Read the accepted order or agreement and identify the entity named as the customer. If the document uses a group brand or informal project name, ask the appropriate customer team for the exact billing entity. Do not expand an abbreviation or add a company suffix from memory.
The person approving a project may have authority to discuss the work without being the person responsible for invoice processing. Record that person’s contact role if useful, but do not replace the customer business name with the individual’s name unless that is genuinely the buyer for the transaction.
For a fictional example, a trainer may work with Maya at “Cedar Group”, while the order identifies “Cedar Operations Ltd”. Maya’s email can help resolve questions about the workshop, but the invoice preparation still needs the confirmed buyer entity and billing address.
Separate the contact’s job from identity
Ask what the contact handles: order approval, invoice queries, document submission or payment remittance. Different people or teams may own each role. A general accounts-payable inbox can be a useful communication channel without becoming the buyer name or electronic endpoint.
Do not assume that an email domain settles the entity question. Several group companies can use a shared domain, while an outsourced service may handle correspondence for a customer. A familiar domain is therefore context, not a substitute for explicit billing instructions.
The current creator has an optional buyer email field but no complete structured contact-person model. If a recipient profile needs a named contact or department in a dedicated element, preserve that requirement for supporting software rather than adding every role to the buyer-name box.
Confirm the address with the entity
Check that the billing address belongs with the confirmed buyer role. A contact’s office, a service location and a registered or invoicing address can differ. Do not automatically copy the address from an email signature when the purchase order provides different billing information.
Where the customer uses a shared processing centre, ask how it wants the business identity and any routing address represented. The right answer may require several separately labelled values. The current form’s single address block cannot demonstrate that every required structured role is represented.
The billing-address and delivery-address comparison helps keep those roles distinct. The important question is not which address is nearest to the contact, but which confirmed information belongs in the buyer record and which describes another part of the transaction.
Handle group-company ambiguity before export
If a customer asks you to change the buyer after work is completed, establish why and whether the instruction affects the underlying contract or an already issued document. Do not treat a new contact’s request as automatically resolving every commercial or tax consequence.
Ask for an authorised clarification of the entity, relevant address, references and affected invoice. Preserve the source and any remaining questions. A change that helps an accounts-payable system match a document should still reflect the actual transaction rather than an inaccurate identity chosen for convenience.
EInvoiceCreator cannot assess contractual authority or maintain issued-document correction status. It records the values entered and performs application field checks. Where a formal correction or different document type is needed, use the appropriate process and supporting software.
Enter roles without disguising missing fields
Use the confirmed buyer name in the name field and the appropriate email in the contact field when that is useful. Keep purchase order numbers and routing references labelled according to purpose rather than attaching them to the business name simply because it is prominent in the preview.
Do not put a network participant identifier into the email field unless the relevant scheme and representation specifically require that kind of value in the target system. The current product has no network endpoint mapping or delivery integration, so recording an email cannot create those capabilities.
If several required contact or routing details exceed the model, retain a separate preparation record. A readable note may explain context to a person, but it should not be presented as an implemented field in the final standard.
Review the completed buyer block
Read the buyer name, address, identifier and email together. Confirm that the name identifies the entity and the contact information has a clear role. Look for a sample name or a previous customer’s email left behind when a draft was reused.
The application can identify a missing buyer name and certain invalid values, but it cannot confirm that the customer ordered the work or that the chosen contact is authorised. Keep the supporting records available and describe the review outcome narrowly. A correct identity and a useful contact support each other; neither should be used to conceal the absence of the other.