Start with the business meaning of each field
An invoice format is more than a list of XML tags or JSON keys. Each value has a business role: who sold, who bought, what was supplied, what tax treatment applies, what is payable and how the transaction can be referenced later. A field map should connect each source-system value to that meaning before it is mapped to a particular syntax.
Required fields depend on the chosen specification, transaction and recipient. The following groups are a planning aid, not a universal mandatory-field list.
| Field group | Typical purpose | Question to resolve |
|---|---|---|
| Parties and addresses | Identify seller, buyer and relevant electronic endpoints. | Which legal or trading-party identifier does the recipient require? |
| Document identity | Invoice number, issue date, type and prior references. | How are duplicates and corrections distinguished? |
| Lines and references | Describe goods or services, quantities, prices and order links. | Can each line be matched to a purchase order or contract? |
| Tax and totals | Represent tax categories, amounts, allowances, charges and payable amount. | Do source calculations reconcile at document and line level? |
| Payment and delivery | Provide payment instructions and applicable delivery context. | Which values belong in the structured payload rather than a note? |
Validation is not one pass/fail test
A file can be well-formed yet unusable to the buyer. Run checks in layers and retain the specific rule, field and document reference for each failure. OpenPeppol's Billing specification, for example, publishes business rules and validation material in addition to syntax documentation. Apply the version and profile actually used in your exchange.
- Syntax: can the file be parsed in the declared format?
- Semantic content: are required business terms present with acceptable values?
- Calculations: do line, tax and payable totals reconcile under the applicable rules?
- Profile and recipient rules: does this buyer accept the process, identifiers and references?
- Transport and outcome: was it delivered, accepted or rejected after validation?
What does an actionable rejection look like?
“Invalid invoice” is not enough for operations. A useful result identifies the document, rule, affected field and next action. For example, a missing buyer reference should go to the team that knows the order relationship, while a calculation mismatch may need correction at the source system. Keep rejected payloads and responses associated with the same transaction ID so resubmission does not create duplicates.
Build a field map that survives change
For each field, record the source system, business definition, output field, transformation, allowed values, responsible owner and test case. Include optional and conditional values, credit notes, negative values and attachments where the selected specification allows them. Avoid inserting a default solely to pass a rule if it misstates the transaction.
When the source system changes, test the mapping against real representative transactions. The ERP integration checklist covers project ownership and test scenarios; EN 16931 explained separates the European semantic model from its syntaxes.
A useful pre-send review
Before production, test invoices for a normal order, a service without an order, multiple tax treatments, a correction or credit note, and a recipient with a distinct profile. Compare the structured values to the business record and readable rendering. Treat validation rule updates as a controlled release: record the version, rerun regression cases and monitor new rejection patterns.
Related guides
- EN 16931: a starting point — What the European e-invoicing semantic model covers, how syntax differs and where local rules begin.
- ERP integration checklist — A phased checklist for connecting e-invoice data, exchange routes and finance operations.
- Structured invoice vs PDF — Compare a human-readable PDF with machine-readable invoice data, including hybrid documents and OCR.
Primary sources and further reading
These official resources support the standards and regulatory context. Check their current versions before implementation.
- European Commission: Compliance with the eInvoicing standard ↗ — Semantic model and UBL/CII syntax bindings
- OpenPeppol: Peppol BIS Billing 3.0 ↗ — Billing profile, information elements and validation
- OpenPeppol: Billing validation rules ↗ — Technical and business rule examples