How to Prepare Invoice Fields for an EN 16931 Mapping

Prepare an EN 16931 mapping by identifying what each source value means, where the required model represents it and how the chosen syntax binding carries it. A completed form is not a completed mapping. The work needs the correct source facts, applicable edition and profile, implemented transformations and validation of the actual output.

The current creator can help organise supported invoice information, calculate amounts and check application fields. Its JSON uses its own schema. It does not implement an EN 16931 binding, formal standards validator or transmission service. Treat the following workflow as preparation for suitable final software rather than a compliance statement about the current app.

Establish the target before mapping fields

Record the recipient’s required specification edition, usage profile, syntax and version. A semantic model and the message carrying it are different layers. The receiving workflow may also apply constraints beyond the broad model, so the target must be more precise than a request for XML.

Check published production requirements and migration arrangements. A newly published standard edition does not establish that every receiver has moved to the same combination. Likewise, the newest UBL or CII release is not automatically the syntax version bound by the required profile.

Keep the source instruction and confirmation date with the mapping record. A spreadsheet labelled latest cannot identify the context later. The European Commission’s guidance on syntax bindings and standard access is a useful starting point, but the actual destination requirement still needs confirming.

Inventory source facts by meaning

List the seller, buyer, invoice identifiers, dates, references, lines, amounts, tax information and payment facts the transaction requires. For each, identify the source of truth. An accepted order, party record and approved tax determination answer different questions and should not be collapsed into the finished invoice as its own evidence.

Read the field definitions rather than matching labels mechanically. A business name may be a trading label rather than the intended formal seller name. A reference may relate to buyer routing, an order or payment matching. Similar strings can represent different business facts.

Use the business-term and business-group explanation to organise the inventory. Groups collect related facts with defined roles; they are not simply visual form sections. A source interface can combine values that the target needs separately or omit a role altogether.

Build a reviewable mapping record

For each fact, record its source field, intended business term, target representation, transformation, condition and test. Include known gaps and the person responsible for resolving them. This makes the implementation assessable without requiring a reviewer to infer decisions from a sample XML file.

A mapping entry should say more than copy value. Identify whether text needs splitting, a code requires confirmation or a calculation must be recomputed under the target model. Do not assume a multiline address can be divided reliably without retaining its original components.

The guide to seller and buyer semantic roles develops one important part of that record. Keep parties distinct even when they share a group name or address. A correctly copied identifier assigned to the wrong party is still a semantic error.

Preserve line and amount relationships

For each line, confirm description, quantity, unit and price basis. A price per hundred items cannot be treated as a price per item without the appropriate representation and calculation. The current creator has no dedicated price-base quantity field, so source requirements may exceed its model.

Record adjustments at the correct level. A line percentage discount, fixed allowance and document charge express different facts. A prior payment is not a discount. The app does not implement every financial structure a formal target may require, even if a similar-looking total can be forced through unrelated inputs.

Use the allowance and charge mapping guide to identify those roles. Preserve the accepted commercial basis and use final software that genuinely implements it. Do not alter quantities or tax categories merely to make a narrower model reach the desired amount.

Organise tax data as a separate decision record

Obtain the confirmed category, rate, identifiers and reasons from the appropriate review. Mapping must express the decision accurately; it must not silently create a tax determination. A numeric rate in a supported field is not proof that it applies to the supply.

Keep category-level relationships and required reasons explicit. Several zero tax results can represent different treatments. The current creator’s line controls and summed tax do not implement every formal breakdown field or coded explanation the destination may need.

Use the tax-breakdown mapping explanation to connect lines with their intended groups. Record calculation and rounding differences separately from treatment decisions. A cent mismatch does not justify moving a line to another category.

Review references, codes and payment information

Collect each reference with its intended role. Buyer routing, purchase orders, preceding invoices, supporting documents and remittance information should not be merged into one unexplained value. The current application has a limited reference model, which is a gap to identify rather than disguise.

Codes need the applicable list and context. A readable unit label is not automatically a standard unit code. An electronic endpoint may need a scheme, while an email address remains a different fact. Do not guess values from abbreviations or examples.

Payment information also has separate method, destination, terms and reference roles. A note describing direct debit does not implement a mandate group or collection service. Preserve the required source components for the final mapper instead of asking it to extract meaning from prose.

Test meaning before declaring technical success

Use a fictional invoice with distinct references, nontrivial quantities and relevant conditional data. Trace selected values from their source facts through the mapping into the target document. Include negative cases so missing information and unsupported features are reported clearly.

The guide to semantic mapping and schema validation explains why structural validity is only one layer. A schema-valid date can still be the wrong date role, and a well-formed identifier can still belong to another party. Review meaning alongside technical rules.

Retain the exact input, generated file, mapper configuration and required validation report. A report about an earlier revision or different profile does not establish the current result. Repeat affected tests after meaningful changes to source data or implementation.

Complete the handoff without unsupported claims

Assign the remaining source-data, mapping, validation and delivery tasks to named roles or systems. Keep unresolved requirements visible until completed. A field labelled standard or an XML-shaped export does not constitute evidence of conformance.

For a compact fictional review, trace an invoice issue date, buyer routing reference and payment reference separately. Give the two references different demonstration values and verify their target locations. Then remove a conditionally required fact and confirm that the final workflow reports the gap. This tests roles and error handling rather than only whether a file opens.

The useful preparation outcome is a reproducible semantic mapping record with accurate source facts and explicit capability gaps. The creator’s current printable output, JSON and CSV remain application outputs. Formal conformance, legal validity, submission and acceptance require the appropriate implemented workflow and evidence; they cannot be inferred from a complete-looking form.

For a final handoff exercise, ask a colleague to trace one source fact using only the mapping record. They should be able to identify its meaning, source evidence, target role, transformation and test result without a private explanation. Repeat the exercise for a known unsupported fact. The colleague should be able to identify who resolves the gap and what evidence will establish completion. This checks the usability of the mapping record itself, which is often where an apparently finished implementation still relies on unrecorded assumptions.