How Seller and Buyer Fields Fit into the Semantic Invoice Model

Map seller and buyer information by the role each party has in the transaction, then map its individual facts into the required model. A name, address and identifier are not interchangeable strings. They need to describe the same confirmed party in the correct semantic context.

The mapping preparation workflow starts with those meanings before target syntax. The current creator collects supported party information in its own model, including multiline addresses and tax-identifier text. It does not formally implement every party group or identifier scheme a target profile may require.

Establish the party roles

Identify who supplied the goods or services and who is being invoiced. A contact person, group purchasing office or payment recipient may be related without being the seller or buyer. Preserve those distinctions rather than assigning roles from whichever name appears first in correspondence.

For a fictional group of businesses, a central purchasing contact could act for one named subsidiary. The buyer mapping should follow the confirmed invoiced entity, not automatically the contact’s email domain or a shared brand. Resolve ambiguity from the actual agreement and billing instruction.

Keep the determination and source in the preparation record. A complete-looking party panel cannot establish that the correct entity was selected. The final mapper needs accurate roles before it can choose structurally correct locations.

Separate name roles

A formal name, trading label and contact name can serve different purposes. Read the target term’s definition and select the appropriate confirmed source. Do not concatenate all available names simply to avoid deciding which one belongs in the field.

The Commission’s seller-name binding example illustrates a defined business meaning mapped into UBL and CII structures. The lesson is that syntax follows the intended term. A target accepting text does not make every visible business label suitable for that role.

If the current source combines several names in one field, preserve the components separately for finalisation. Do not ask the adapter to infer the authoritative identity from punctuation or visual prominence alone.

Preserve address components

A readable multiline address can work for a person while a target model needs separate components. Keep confirmed street, locality, postal information and country facts available in preparation records where required. Extraction from a single block can be ambiguous.

Do not confuse a delivery location with the legal or billing address of a party. They may share a value in one transaction and differ in another. The source-to-target mapping should identify the role rather than copying an address into every location field.

Where a formal country code is needed, use the appropriate list and confirmed country. The creator’s country context does not establish that every required coded representation has been mapped or validated.

Keep identifier types distinct

A tax identifier, company registration value, electronic endpoint and customer account code answer different questions. Preserve each value’s role and scheme where required. A plausible shape is not proof of ownership or applicability.

Do not copy a single source identifier into several target roles merely because the target requires data. Obtain missing facts from the appropriate party. A formally valid string in the wrong semantic role can still prevent processing or misstate identity.

Use the code-list and identifier review to check the required representations. The current creator does not verify registries, endpoint schemes or every target identifier field. Those gaps need explicit handling in the final workflow.

Keep other parties separate

A payee different from the seller, a delivery party or another supported role may require its own group in the target. Do not overwrite seller identity to fit an additional party into a narrower source model. Preserve the authorised arrangement separately.

Ask the final provider which roles it implements under the required profile and version. A readable note naming another organisation does not establish a typed party mapping or validate the relationship. Keep the unsupported requirement visible until implemented.

Review payment and tax decisions independently. A party’s identifier or destination account does not determine the transaction’s tax treatment. Mapping should preserve an established decision, not create one from assumptions about names or countries.

Test with deliberately different values

Use fictional seller and buyer names, different addresses and visibly distinct identifiers. Trace each fact to the actual exported target location. A test using identical or near-identical values can hide a role reversal.

Then change one party’s address in the source and regenerate the output. Confirm that only the intended target changes. This tests both role assignment and revision behaviour without exposing real customer information.

Retain source evidence, mapping rules and the exact tested file together. Formal technical validation remains necessary where required, but factual party review also needs its own evidence. The creator’s current JSON, CSV and printable output support preparation rather than a verified EN 16931 party binding, registry check or guarantee of acceptance.

A useful negative test assigns the fictional buyer’s identifier to the seller while leaving both names correct. Check which factual or semantic review detects it. A structural validator alone may see two permitted text values without knowing their true owners.