A billing address identifies the customer’s billing information for the transaction, while a delivery address identifies where goods were delivered or another relevant delivery location. They may be the same, but do not assume that one can replace the other. Confirm the buyer entity and the role of each address before entering invoice data.
The buyer-information workflow starts with the entity being charged. A warehouse, project site or service venue can be relevant to the supply without being the buyer’s billing address. Mixing those roles can leave a readable invoice that the customer’s processing team cannot match correctly.
Identify the buyer before choosing an address
Read the accepted order and billing instructions. Determine which business or person is the buyer and which address the customer has confirmed for that role. The address where a contact works is not automatically the billing address, especially in groups with several entities and shared premises.
For a fictional furniture sale, goods might go to a new office while the order names a separate operating company and supplies a central billing address. Those locations serve different purposes. A delivery label establishes where a consignment went; it does not necessarily establish the complete identity of the entity to invoice.
If the customer asks you to use a processing-centre address, obtain the intended representation and any routing reference. Do not replace the buyer’s identity with the name of a third-party processing service merely because that service handles the documents.
Keep evidence of each location’s role
Retain the order, delivery record and confirmed billing instruction with labels explaining which fact each supplies. This avoids using the most recent address as a universal replacement for every location in the invoice record. A changed delivery site may not change the buyer entity or billing address at all.
The buyer-address preparation guide helps confirm and structure the billing information. Record delivery details separately when they matter for the transaction or recipient. Do not discard them just because the current editor has no dedicated field for the complete role.
If two source documents disagree, ask the customer’s authorised contact whether the difference is a correction, an additional site or a different entity. A combined address block can hide the unresolved question rather than solve it.
Avoid inferring tax treatment from location alone
A delivery location can be relevant to transaction analysis, but this application does not have enough information to determine tax treatment from an address. The nature of the supply, parties and other applicable facts may matter. Confirm the treatment through appropriate records or advice before entering a category and rate.
Do not alter a delivery address or country to make the tax entry resemble another invoice. Likewise, a buyer’s billing country and invoice currency do not establish where every supply occurred. These are distinct facts, and preserving the distinction helps an adviser assess the actual transaction.
The creator’s country context and party-country selections remain descriptive application data. They do not implement a national profile, validate a delivery location or select tax rules. A checked field is not evidence that the underlying location has been verified.
Recognise the current model’s boundaries
EInvoiceCreator holds one buyer address block and no complete separate structured delivery-location group. Its notes or descriptions can explain a relevant location for a human reader, but that is not equivalent to mapping delivery components into a recipient’s required standard fields.
If a final profile requires both buyer and delivery addresses, preserve the confirmed components and roles for supporting software. Do not concatenate two addresses into one unlabelled buyer field and claim the resulting JSON satisfies that profile. The application’s JSON schema has its own limited structure.
Similarly, the line-items CSV does not contain a full buyer or delivery record. A preview showing a readable buyer block does not mean that every available export carries all of that information. Choose the output according to its actual contents.
Review a multi-site example
Suppose a fictional maintenance supplier performs work at a customer’s East Depot but the purchase order names “Redwood Operations Ltd” with a central billing office. The job contact is based at the depot. The preparer should keep the buyer, billing address, service location and contact distinct.
If the customer also requests a depot code, ask where it belongs and whether a separate buyer reference is needed. A site code may support internal matching without replacing the legal buyer or address. This is precisely the kind of requirement that should remain labelled for external mapping when the preparation editor has only one general reference field.
Before export, read the buyer block and any location note together. Ensure a reader will not mistake the depot for the seller, the processing centre for the buyer or the service date for the issue date. Context is useful only when the roles remain clear.
Resolve role questions before final hand-off
A good hand-off states the confirmed buyer entity, billing address, relevant delivery information and source of each. It also identifies any dedicated fields the final software needs to generate. Keep unresolved questions visible rather than presenting a combined paragraph as complete structured data.
Accurate preparation preserves the facts for the next operator. It does not establish recognised-format conformance, tax-authority acceptance or successful delivery. Those stages need their own implemented process and evidence, even when the billing and delivery locations are both correct.