Structured e-invoicing in Europe

Structured e-invoicing in Europe

Building, sending and receiving machine-processable invoices under EN 16931, Directive 2014/55/EU, the VAT Directive 2006/112/EC as amended by Council Directive (EU) 2025/516 (ViDA), and the national mandates layered on top. Written for a developer who has to make invoicing work inside a product, not for an accountant. Status as at 2026-08-05.

Core principle: an e-invoice is not a PDF. Under Art 2(1) of Directive 2014/55/EU and Art 217 of Directive 2006/112/EC as replaced by ViDA, an electronic invoice is a dataset "issued, transmitted and received in a structured electronic format which allows for its automated and electronic processing". An emailed PDF is not one, and under § 14 Abs 1 Satz 4 UStG it is expressly a sonstige Rechnung. The correct mental model has four independent layers: one semantic core (EN 16931 business terms BT-/BG-), two permitted syntaxes (UBL 2.1, UN/CEFACT CII D16B), many national CIUS and extensions (XRechnung, Peppol BIS Billing, RO_CIUS, Factur-X profiles), and separate transmission channels (Peppol AS4, SdI, KSeF, French plateformes agréées, SPV). Getting the syntax right and the CIUS wrong is the standard failure: the file is well-formed UBL, passes the XSD, and is rejected by the receiving country.

Not tax or legal advice

This skill produces implementation artefacts and findings, not advice on a taxpayer's obligations.

• Whether a specific entity is inside a mandate, from which date, and at which turnover threshold is a question for a tax adviser in that country. The skill maps the rule; it does not classify the business.
• Anything that goes into production and carries VAT figures — invoice content, exemption wording, retention, correction procedure — gets signed off by the tax adviser responsible for the entity before the first live invoice.
• Every generated invoice template, mapping table or country statement carries <!-- ENTWURF – steuerlich nicht freigegeben --> until that sign-off is confirmed. Never remove the marker silently.
• The mandatory published legal texts of a website (Impressum, privacy notice, terms) are out of scope — those belong to the legal-* skills. The boundary: this skill covers the invoice document and its transport, not what the shop page says.

Never drop or soften this section in the output.

Workflow

1. Intake before any code. Without the answers in references/intake.md, every format and channel decision is a guess. Country of establishment, countries of customers, B2G/B2B/B2C, turnover band and existing ERP decide everything downstream.
2. Decide the layer stack using the matrix below: semantic profile → syntax → CIUS/customization ID → channel.
3. Read the reference file for each layer before producing anything. The element names, code lists and rule IDs are too specific to recall — a wrong cbc: path or a wrong EAS code fails silently at the access point.
4. Validate before sending. Schema, then EN 16931 Schematron, then the CIUS Schematron, then the country platform's own test endpoint. references/validation-errors.md maps the rule IDs that reject most first attempts.
5. Run references/checklist.md and report findings with rule ID and fix.

Output shape. Exactly four parts, in this order:

1. the artefact — mapping, XML, code, or the finding table — carrying the draft marker
2. the list of [[MISSING: …]] values the user must supply
3. adjacent open items in one sentence each (archiving, credit notes, second country, human-readable rendition)
4. the sign-off note

Cite the norm, rule ID or specification version next to the claim it supports. Reference file names are working material and belong in none of the four parts.

Decision matrix

Hard rules

• A PDF is not an e-invoice, and neither is a PDF with XML next to it in the same email. Art 217 of Directive 2006/112/EC as replaced by ViDA and Art 2(1) of Directive 2014/55/EU require a structured format allowing automated processing. Only a hybrid file where the XML is embedded in a PDF/A-3 (Factur-X / ZUGFeRD) counts, and then the XML is the invoice — the visual layer is a rendition.
• The XSD is not the validation. UBL 2.1 and CII D16B schemas accept files that EN 16931 rejects. Conformance means passing the EN 16931 Schematron (validation artefacts v1.3.16, released 2026-04-13, github.com/ConnectingEurope/eInvoicing-EN16931) and the CIUS Schematron of the target country. Never report "valid" on the basis of a schema check.
• cbc:CustomizationID (BT-24) is the contract, not decoration. urn:cen.eu:en16931:2017 is plain EN 16931; Peppol BIS Billing 3.0 requires exactly urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0 (docs.peppol.eu). Sending a Peppol invoice with the plain EN 16931 identifier is rejected at the access point. Never guess this string — copy it from the target specification.
• Two ZUGFeRD/Factur-X profiles are not invoices. MINIMUM (urn:factur-x.eu:1p0:minimum) and BASIC WL (urn:factur-x.eu:1p0:basicwl) carry no line data and are not EN 16931 conformant; only BASIC, EN 16931 and EXTENDED are (fnfe-mpe.org, Factur-X 1.09.2 / ZUGFeRD 2.5.2, released 2026-08-04). They are booking aids, not something to send into a mandate.
• The buyer no longer has to agree. Art 232 of Directive 2006/112/EC as amended by ViDA (Council Directive (EU) 2025/516, Art 1 point 3) lets a Member State that mandates domestic e-invoicing dispense with recipient acceptance, applicable from 14 April 2025. Advice that "you need the customer's consent for an e-invoice" is pre-ViDA and wrong wherever a domestic mandate exists.
• A qualified electronic signature is not required by EU VAT law, anywhere. Art 229 of Directive 2006/112/EC: "Member States shall not require invoices to be signed." Art 233(1) as replaced by Directive 2010/45/EU lets each taxable person choose any business controls creating a reliable audit trail; the advanced signature and EDI in Art 233(2) are examples, not requirements. Portugal's PDF-signature rule is a national procedural rule about non-structured PDFs, not a counter-example to this.
• The receipt obligation and the issuing obligation are different dates. Germany: receipt obligatory since 2025-01-01, issuing phased via § 27 Abs 38 UStG to 2027-01-01 and 2028-01-01. France: receipt for all before issuing for most. Never state one mandate date per country.
• Never invent an identifier, code or threshold. EAS scheme codes, codice destinatario, Leitweg-ID, KSeF numbers, turnover thresholds and go-live dates are either verified against the authority's own page or written as [[MISSING: …]]. A plausible wrong EAS code routes the invoice to nobody and fails silently.
• The Peppol MD5/CNAME lookup is dead, not deprecated. Since 2025-11-01 participant resolution uses strip-trailing(base32(sha256(lowercase(value))),"=") under a U-NAPTR record with service name Meta:SMP; the legacy B-<md5hex> CNAME records now return NXDOMAIN (Peppol CNAME to NAPTR Migration Process v1.0.0). The SML zone is also moving to participant.sml.prod.tech.peppol.org — access points must have switched by 2026-08-31. Any tutorial showing MD5 is describing a broken client.
• Cancelling a transmitted invoice is usually impossible. Once SdI, KSeF or SPV has accepted the document, the correction is a new document (Italy TD04 credit note; Poland faktura korygująca — the buyer-issued nota korygująca was abolished on 2026-02-01). Building a "void invoice" button without a country check produces an unreconcilable ledger.

False friends

Assumptions that are plausible, widespread in English-language material, and wrong.

Common mistakes

Reference files

• references/intake.md — questions to answer before any format or channel decision
• references/en16931.md — semantic model, BT-/BG- structure, mandatory vs conditional, validation artefacts
• references/syntax-examples.md — worked minimal invoice in UBL 2.1 and in CII D16B with verified element names
• references/eu-law.md — Directive 2014/55/EU, Implementing Decision 2017/1870, ViDA package and every date
• references/vat-content.md — Art 226/226a/226b/229/233 content rules, reverse charge, intra-Community, small business
• references/country-matrix.md — per-country lookup: format, syntax, channel, mandate status, identifier scheme
• references/countries-mandates.md — Italy, France, Germany, Spain, Poland in detail
• references/countries-other.md — Belgium, Romania, Hungary, Portugal, Greece, Nordics, NL, CH, UK
• references/peppol.md — network model, BIS Billing 3.0, identifiers, SMP/SML, connecting via a service provider
• references/identifiers.md — EAS, ISO 6523 ICD, national routing IDs, UNTDID 1001, Rec 20, UNCL5305, VATEX
• references/validation-errors.md — rule ID → cause → fix for the errors that reject first attempts
• references/implementation.md — rounding, totals, PDF/A-3 embedding, renditions, test validators
• references/lifecycle.md — credit notes, corrections, cancellation per country, archiving, integrity
• references/checklist.md — pre-go-live check with rule and norm references