EN 16931: what makes an electronic invoice compliant

EN 16931 is the European standard for electronic invoices. This page explains what it defines and what it does not, the two ways it can be written, how national formats build on it, who must accept it today, and what changes in 2030. Every statement is quoted from the EU texts or the European Commission. No software vendor is compared to another.

What the standard is

The EU asked for it in Directive 2014/55/EU on electronic invoicing in public procurement, which defines an electronic invoice as one

“that has been issued, transmitted and received in a structured electronic format which allows for its automatic and electronic processing”.
Directive 2014/55/EU, Article 2, point (1).

and rules out the simplest case in its recitals:

“A mere image file should not be considered to be an electronic invoice for the purpose of this Directive.”
Directive 2014/55/EU, recital (7).

A PDF sent by e-mail, however neat, is therefore not an electronic invoice in this sense. The standard itself was issued by the European Committee for Standardisation (CEN) on 28 June 2017, and its reference published in the Official Journal by Commission Implementing Decision (EU) 2017/1870, Article 1, in two parts:

  • EN 16931-1:2017, Electronic invoicing, Part 1: Semantic data model of the core elements of an electronic invoice;
  • CEN/TS 16931-2:2017, Electronic invoicing, Part 2: List of syntaxes that comply with EN 16931-1.

A data model, written in one of two syntaxes

The semantic data model

The heart of the standard is a list of the information an invoice carries, what each item means, and the rules between them. It does not say how the file is laid out:

“The EN does not define the technical structure (syntax) of the electronic invoice but instead uses two international XML message standards to carry the information defined in the core invoice data model.”
European Commission, “Compliance with eInvoicing standard”.

The two syntaxes

SyntaxAs the Official Journal names it
CIIUN/CEFACT Cross Industry Invoice XML message, as specified in XML Schemas 16B
UBLUBL invoice and credit note messages as defined in ISO/IEC 19845:2015 (UBL 2.1)

Commission Implementing Decision (EU) 2017/1870, Annex.

A public buyer in the EU has to accept an invoice in either of the two, as the section on who must accept it shows below.

How national formats build on it: CIUS and extensions

A country or a sector often needs more precision than the core model, or more data. The standard provides two tools for that, and they are not equally compliant:

  • A CIUS (Core Invoice Usage Specification) narrows the core, for example by restricting how its items may be filled in. It stays inside the standard.
  • An extension adds items the core does not have. It leaves the standard.
“Because it is documented within the standard, the use of a CIUS is a compliant implementation of the eInvoicing standard while an extension is not.”
European Commission, “Navigating the eInvoicing standard documentation”.
“An extended invoice is not compliant to the eInvoicing standard […] The use of extended invoices must be based on bilateral agreement between buyer and seller.”
European Commission, “CIUS and Extension, What is allowed”.

The German XRechnung is a worked example of both. Its publisher describes it as a CIUS and an extension together:

„Dabei besteht der Standard XRechnung aus der CIUS XRechnung sowie der Extension XRechnung.“ The XRechnung standard consists of the XRechnung CIUS and the XRechnung extension.
KoSIT, xeinkauf.de, “XRechnung”.

Which German format to send to which recipient is a separate, practical question, answered in German on XRechnung oder ZUGFeRD?

Compliant with the standard is not the same as a valid VAT invoice

The standard describes the structure. What an invoice must say for VAT purposes comes from the VAT Directive, Article 226, which opens:

“Without prejudice to the particular provisions laid down in this Directive, only the following details are required for VAT purposes on invoices issued pursuant to Articles 220 and 221: (1) the date of issue; (2) a sequential number, based on one or more series, which uniquely identifies the invoice; (3) the VAT identification number […]”
Council Directive 2006/112/EC, Article 226, consolidated version of 14 April 2025.

The two conditions are separate, and from 1 July 2030 the VAT Directive says so in as many words: Member States must ensure that electronic invoices “(a) include the information required by this Directive; and (b) comply with the required technical standards on electronic invoicing” (new Article 218(4), inserted by Directive (EU) 2025/516). A file can pass every rule of the standard and still be a defective invoice, and the reverse.

Who must accept it, and from when

Public buyers: since 2019

“Member States shall ensure that contracting authorities and contracting entities receive and process electronic invoices which comply with the European standard on electronic invoicing whose reference has been published pursuant to Article 3(2) and with any of the syntaxes on the list published pursuant to Article 3(2).”
Directive 2014/55/EU, Article 7.

The deadline for central public buyers is set by the implementing decision: “18 April 2019 is the final date for bringing into force of the measures referred to in the first subparagraph of Article 11(2) of Directive 2014/55/EU” (Article 2). Member States could postpone it for sub-central buyers until 30 months after the reference was published (Directive 2014/55/EU, Article 11(2)).

Businesses: the default from 1 July 2030

ViDA makes the standard the default for invoices between businesses across the EU, with room for national standards for domestic supplies:

“Electronic invoices shall comply with the European standard on electronic invoicing and the list of its syntaxes pursuant to Directive 2014/55/EU […]. Member States may allow the use of other standards for electronic invoices relating to supplies of goods and services within their territory, other than those referred to in Article 262 of this Directive.”
Directive 2006/112/EC, Article 218(3), as replaced by Directive (EU) 2025/516, Article 5, point (5).

Of the five countries this site covers, France and Germany already base the formats they accept on it, as their guides set out; Italy and Poland require FatturaPA and FA(3). The table of national mandates shows which format each country requires today.

What the standard does not decide

  • How the invoice travels. E-mail, a platform, a national clearance system or a network such as Peppol: the standard is silent on the channel.
  • Whether it is mandatory. That comes from each country's law, and from 2030 from the VAT Directive.

The 2026 edition

CEN has published a new edition of part 1. Its catalogue lists EN 16931-1:2026 as published, ratified on 13 March 2026 and made available on 18 March 2026, superseding the 2017 edition and its amendment, which it lists as withdrawn. Its entry for the Official Journal reads “Citation expected for Directive 2014/55/EU”: the Official Journal still cites the 2017 edition through Implementing Decision (EU) 2017/1870.

The Commission states that the 2017 edition stays usable in the meantime: “The 2017 version will, however, remain compliant during the migration period.” The same Commission page dates the new edition to May 2026, where CEN gives March; this page reports both rather than choose.

The Commission also announces a change of instrument for public procurement: “replacing the current Directive with a Regulation that makes the European standard mandatory for public procurement (Q4 2026)”. That is a plan, not yet a text.

Reading the standard

Parts 1 and 2 of the 2017 edition can be obtained free of charge: “On 18 December 2018, the European Commission and CEN signed a License Agreement allowing cost-free access to the parts 1 and 2 of the eInvoicing standard”. The Commission marks that page as under review, and does not say whether the arrangement covers the 2026 edition. The other parts are sold by the national standards bodies.

One way to produce it

Invoicerr is one way to produce invoices on this standard: open-source invoicing software that builds Factur-X, XRechnung, ZUGFeRD, UBL and CII invoices. It is not the only way, and this paragraph does not try to convince you otherwise: whatever tool you use, the test is whether its output passes the standard's rules and carries the VAT particulars.

Sources

Every claim on this page links to the text that carries it. Checked at these addresses on 24 September 2026.

Definition of an electronic invoice, image files excluded, obligation of public buyers, transposition
Directive 2014/55/EU of 16 April 2014, Articles 2, 3, 7 and 11, recital (7). eur-lex.europa.eu
Reference of EN 16931-1:2017 and CEN/TS 16931-2:2017, the two syntaxes, 18 April 2019
Commission Implementing Decision (EU) 2017/1870 of 16 October 2017, Articles 1 and 2, Annex, recital (3). eur-lex.europa.eu
Mandatory particulars of an invoice
Council Directive 2006/112/EC, Article 226, consolidated version of 14 April 2025. eur-lex.europa.eu
EN 16931 as the default from 1 July 2030, new Article 218(3) and (4)
Council Directive (EU) 2025/516, Article 5, point (5), and Article 6(5). eur-lex.europa.eu
The standard does not define the syntax; UBL 2.1 and CII
European Commission, Digital Building Blocks, “Compliance with eInvoicing standard”. ec.europa.eu
CIUS compliant, extension not
European Commission, “Navigating the eInvoicing standard documentation” and “CIUS and Extension, What is allowed”. ec.europa.eu
XRechnung as CIUS and extension
KoSIT, “XRechnung”. xeinkauf.de
EN 16931-1:2026: dates, 2017 edition withdrawn, OJ citation expected
CEN, project page for EN 16931-1:2026. standards.cencenelec.eu
2017 edition compliant during migration, free access to parts 1 and 2
European Commission, “Obtaining a copy of the European standard on eInvoicing”. ec.europa.eu
Planned regulation replacing Directive 2014/55/EU
European Commission, Digital Building Blocks, “eInvoicing”. ec.europa.eu