For a business with multiple branches, identify the actual supplier entity first and then establish which branch or address information is relevant to the invoice. A branch location does not automatically become a separate seller, and a shared brand does not prove that several locations belong to the same entity. Use the agreement and confirmed business records to establish those relationships.
The seller-details workflow provides the identity framework. The additional task here is to keep the entity, operating location and recipient-specific site references distinct. A single name-and-address block can otherwise hide several different roles under one familiar business label.
Identify the contracting supplier
Check which entity is named in the agreement, quotation or accepted order. Compare that name with the relevant registration and tax information. If one location fulfilled the work but another entity contracted with the customer, resolve the relationship with an authorised business contact rather than assuming the dispatch location determines the invoice seller.
For a fictional maintenance group, a north office might perform the work while the contract identifies the group’s operating company. Another office using the same brand could belong to a different company. The appearance of the brand alone cannot settle which identifiers belong on the invoice.
Do not combine a branch address from one record with a tax identifier from a different entity to create a convenient-looking seller block. The values need to form a coherent representation of the supplier for the actual transaction.
Label each location’s role
A preparation sheet can distinguish the supplier identity address, service location, correspondence address and a branch reference. Record which source established each value. Some may belong in different parts of an external structured invoice, while others may be relevant only to the customer’s internal matching process.
Keep the service or delivery site out of the seller address unless the confirmed requirements call for that representation. A customer’s premises, for example, can be where work occurred without being an address of the seller at all. Location information should not change roles simply because it is copied into a nearby box.
The registered and trading address comparison can help when two seller-related addresses appear in the source records. It addresses the role of the address; the branch preparation still needs to establish whether those addresses belong to the same supplier entity.
Preserve branch references separately
A customer may require a site code, supplier location number or branch reference in addition to the seller identity. Ask what the code represents and where the recipient expects it. An internal branch nickname is not automatically a legal identifier or an electronic invoice endpoint.
EInvoiceCreator currently offers a seller name, multiline address, country, tax ID and email. It does not implement a complete multi-location supplier schema or separate typed branch references. Preserve additional values in the preparation records for supporting software instead of putting several unrelated codes into the tax-ID field.
If a readable note helps explain which office performed the service, keep it accurate and relevant. Do not report that note as satisfying a recipient profile that requires a dedicated structured reference. A human explanation and a mapped identifier serve different purposes.
Check cross-location currency and tax assumptions
A branch country or service location does not give the application enough information to determine tax treatment. The nature of the transaction, parties, registrations and other applicable facts may matter. Obtain the relevant decision through appropriate records or advice rather than applying a sample rate based on a location name.
The overall country context and the seller country remain descriptive application selections. Neither creates a national profile or validates a branch’s registration. Selecting the invoice currency also does not convert prices agreed by another office in a different currency.
For a fictional repair invoice, preserve the agreed charge and currency even if a different branch prepares the document. Do not normalise the price into that branch’s usual currency without an explicit, appropriate conversion process, which this creator does not implement.
Review the customer-facing identity
Read the preview as the customer’s billing team would. Can they match the named supplier with their order and supplier record? Does the address describe the intended seller role? Is any branch information clearly labelled rather than mixed into the business name in a way that changes its meaning?
If the customer has a separate supplier account for each branch, obtain its instructions before final output. Those account references do not necessarily replace the supplier’s formal identity. Resolve conflicts through the customer’s established process rather than changing seller facts merely to achieve a match.
Keep revisions and hand-offs controlled
When reusing a draft for another branch, check the seller identity and every related field. An old location code, email or tax identifier can remain after the visible address changes. A basic field checker may accept the values because they are complete and well-formed.
Retain the confirmed source records and describe any external mapping requirements in the hand-off. The current creator can help prepare an ordinary invoice’s basic fields and readable document. It cannot verify a group structure or decide which branch is entitled to issue the invoice. A clear branch record supports the next stage without pretending that the limited application model already represents every required location relationship.