What is the European Core Invoice?
Find out everything you need to know about European Core Invoice (EN-16931) – from its definition and importance, to its historical and legal basis, to the technical aspects and the benefits of standardization in the EU.
1. Executive summary: European Core Invoice, EN-16931
The European Core Invoice, otherwise known as EN-16931, is an important standard for electronic invoices within the European Union. It aims to create a uniform and machine-readable structure for invoice data to simplify cross-border business transactions and automate processes. This makes the adaptation to national invoice formats much more efficient, easier and cheaper.
The introduction of the European Core Invoice is closely linked to the EU's efforts to strengthen the digital single market and minimize administrative barriers to international trade. Standardization at European level will enable businesses – especially SMEs – to benefit from increased competitiveness and transparency, while meeting legal and compliance requirements.
The following sections go into the historical background to the Core Invoice, the legal framework, the specific benefits of implementing the European Core Invoice, and the most important technical specifications.
2. An introduction to the European Core Invoice
The definition and significance of the European Core Invoice
The European Core Invoice, also known as 'European Core Invoice' or 'EN-16931', is a standard format for electronic invoices introduced by the European Commission. The aim of this standard is to create a uniform and interoperable structure for electronic invoices within the European Union. The European Core Invoice ensures that all relevant invoice data is provided in a structured, machine-readable format to drive the automation and efficiency of invoicing processes.
The importance of the European Core Invoice lies in its ability to facilitate cross-border trade by providing a common language for invoice data. This reduces the complexity and costs associated with adapting to different national invoice formats and improves the transparency and traceability of business transactions.
Historical development and legal framework of the European Core Invoice
The introduction of the European Core Invoice is the result of the European Commission's efforts to promote the digital single market and reduce administrative barriers to cross-border trade. An important milestone was the publication of Directive 2014/55/EU in April 2014, which requires the use of electronic invoices in public procurement. This directive called for the development of a common European standard for e-invoicing.
In response, the European Committee for Standardization (CEN) developed the EN-16931 standard, which was officially published in June 2017. Since then, all public contracting authorities in the EU have been obliged to accept electronic invoices in the EN-16931 format. This obligation came into force on 18 April 2019.
The legal framework for the European Core Invoice includes, in addition to Directive 2014/55/EU, national legislation to ensure implementation of and compliance with the standard in the individual EU member states.
The objectives and advantages of standardized e-invoicing in the EU
E-invoicing standardization in the EU has 6 main objectives:
3. What is EN-16931?
European Directive 2014/55/EU requires public authorities within the EU to accept and process invoices from contractors in electronic format. As a result, the European Commission asked CEN (Comité Européen de Normalisation) to create a European Standard (EN) for a semantic data model of a European Core Invoice.
The standard EN-16931 published by CEN has since been adopted by national standards bodies, such as DIN in Germany. It was the CEN committee CEN/TC 434 that first defined the requirements for an invoice and gave them a requirement identifier. These were transferred to the semantic data model of the core invoice.
While evaluating and selecting suitable syntaxes, several were examined according to defined criteria and the selected syntaxes were published in the Technical Annex EN-16931-2 (CEN/TS 16931-2:2017, Electronic invoicing – Part 2: List of syntaxes compliant with EN 16931-1). The syntaxes that comply with EN-16931 are listed below:
- UBL (Universal Business Language):
UBL is a standardized XML format for electronic business data exchange covering a wide range of document types, including invoices. The UBL invoice contains all the information required by EN-16931 and is widely used in the EU. - CII (Cross Industry Invoice):
CII is another XML-based format developed by UN/CEFACT. It also supports the requirements of EN 16931 and provides an alternative way to implement e-invoicing.
Syntax bindings are available for both. From a global or EU perspective, the use of the UBL 2.1 syntax has become well established. The CII syntax is mainly used for ZUGFeRD / FacturX (GER & FR), as well as being the second permitted syntax in Germany for XRechnung. Other countries have generally committed to using a single syntax (UBL 2.1 invoice and credit note).
The technical implementation of the European Core Invoice requires adherence to certain specifications and validation rules to ensure that invoices comply with the standard specifications and can be processed correctly. These include:
- Schematron rules:
This XML schema defines the structure and validation rules for the invoice data. - Syntax rules:
These specify the correct syntax for invoice data to assure error-free processing.
What is the difference between semantics and syntax?
What are semantics?
Semantics (from ancient Greek σημαίνειν sēmaínein, ‘to signify’) is the scientific study of meaning and the various relationships between a sign and that which it signifies. (Source: https://de.wikipedia.org/wiki/Semantik (accessed 20.9.2024)).
The European Core Invoice is based on clearly defined content and meaning. These are described in EN-16931. In addition to the scope of the content, business rules have been defined for general compliance criteria for a valid invoice. These rules can be used to determine whether the content of an obligation is optional or conditional, i.e. subject to dependencies defined in the business rules. Where content is provided in coded form rather than text, the semantic definition also specifies which code lists are to be used.
The semantic definition provides a common understanding of the content and its meaning in an electronic invoice.
This information is critical for business departments to determine what information is required to create a correct invoice.
An example of the semantic data model:
| ID | Level | Cardinality | Business Term | Description | Usage Note | Req. ID | Semantic data type3 |
| BT-1 | + | 1..1 | Invoice number | A unique identifier for the invoice | The sequential number required by Article 226 (2) of Directive 2006/112/EC [2], which is uniquely assigned to identify the invoice within the seller's business context, time frame, operating systems and records. It may be based on one or more series of numbers, which may contain alphanumeric characters. No identification scheme is to be used. | R56 | Identifier |
| BT-2 | + | 1..1 | Invoice date | The date on which the invoice was issued | - | R56 | Date |
| BT-3 | + | 1..1 | Code for the invoice type | A code indicating the function type of the invoice | Commercial invoices and credit notes are defined according to the entries in UNTDID 1001 [6]. Other entries from UNTDID 1001 [6] with specific invoices or credit notes may be used if applicable. | R44 | Code |
| BT-5 | + | 1..1 | Code for the invoice currency | The currency in which all invoice amounts are stated, except for the total tax amount in the booking currency | The invoice must be issued in one currency only, with the exception of the total tax amount in the accounting currency (BT-111) in accordance with Article 230 of Directive 2006/112/EC on VAT. The lists of permitted currencies are kept by the ISO 4217 Maintenance Agency "Codes for the representation of currencies and funds". | R54, R47 | Code |
Figure 1: Semantic data model of the core elements of electronic invoices (Source: EN-16931-1)
What is syntax?
Syntax, on the other hand, determines how the information is to be provided. It can also be defined as a language or script. The syntax determines how the content is presented. Different rules apply depending on the syntax. It is comparable to communicating in German or English or using the Latin or Greek alphabet.
This information is primarily intended for IT specialists who are responsible for the technical implementation.
What is a syntax binding?
Syntax bindings ensure that semantic contents are mapped onto syntax structures (paths). This assigns the semantic contents exactly to the information elements of the respective syntax. The syntax binding is an interface that mediates between the business and technical sides. It is where both parties come together.
Sample extract from the syntax binding for UBL 2.1 Invoice:
| ID | Level | Card. | BT | Description | DT | Path | Type | Card. | Match | Rules |
| BT-1 | 1 | 1..1 | Invoice number | A unique identification of the Invoice. | I | /Invoice/cbc:ID | I | 1..1 | ||
| BT-2 | 1 | 1..1 | Invoice issue date | The date when the Invoice was issued. | D | /Invoice/cbc:IssueDate | D | 1..1 | ||
| BT-3 | 1 | 1..1 | Invoice type code | A code specifying the functional type of the Invoice. | C | /Invoice/cbc:InvoiceTypeCode | C | 0..1 | CAR-2 | |
| BT-5 | 1 | 1..1 | Invoice currency code | The currency in which all Invoice amounts are given, except for the Total VAT amount in accounting currency. | C | /Invoice/cbc:DocumentCurrencyCode | C | 0..1 | CAR-2 | |
| BT-6 | 1 | 0..1 | VAT accounting currency code | The currency used for VAT accounting and reporting purposes as accepted or required in the country of the Seller. | C | /Invoice/cbc:TaxCurrencyCode | C | 0..1 | SEM-2 | |
| BT-7 | 1 | 1..1 | VAT added tax point date | The date when the VAT becomes accountable for the Seller and for the Buyer in so far as that date can be determined and differs from the date of issue of the invoice, according to the VAT directive… | D | /Invoice/cbc:TaxPointDate | D | 0..1 | SEM-2 |
Figure 2: Excerpt from the mapping of the semantic model to the UBL invoice syntax elements (Source: EN 16931-3-2_EN_UBL)
What does EN 16931 cover?
The current version of the European Core Invoicing Model was developed with the needs of public administrations as invoice recipients in mind. The focus has been on the requirements of VAT legislation and the requirements of the administration's procurement processes. These aspects have significantly influenced the semantic scope.
The defined contents can be roughly divided into several groups:
- Information on process control (BG-2)
- Information on the seller (BG-4)
- Information on the buyer (BG-8)
- Information on the payee (BG-10)
- Information on the seller's tax representative (BG-11)
- Delivery information and address (BG-13 + BG-15)
- Details of the invoice items (BG-25)
- Payment instructions and information (BG-16 + ff)
- VAT breakdown (BG-23)
- Grand totals (BG-22)
- References and invoice-supporting documents / attachments (BG-24)
Each group, of course, contains the information elements that belong to that group. In EN 16931, both the groups and the information elements themselves have been assigned unique identifiers.
- Group = Business Terms Group or group of business terms, or BG for short.
- Information element = business term or business term, or BT for short.
The identifiers for the groups and information elements are structured as follows:
- Group (business terms group or group of business terms) = BG-x*
- Information element (business term or business concept) = BT-x*
*x stands in each instance for a number, currently either one-digit or double two-digits long
Can all business transactions be modelled with EN 16931?
It is not possible to cover all types of business transactions. The mandate for the current standard was issued primarily for the needs of public administration. Support has therefore been limited to a simple purchase-to-pay (P2P) process. Core Invoicing does not support complex P2P processes such as supplier managed inventory. However, the extension mechanisms offer the possibility to extend the Core Invoice for these purposes.
What is a CIUS and what is an extension in e-invoicing?
For country- or industry-specific extensions, there are two methods in the standard, namely the Core Invoice Usage Specification (CIUS) or an extension.
A CIUS is an application specification for the European Core Invoice. This must, of course, comply with the European standard. This means that further application recommendations, business rules or restrictions to those specified in EN-16931 must be defined for a specific region/country or business situation. A CIUS must always be fully compliant with EN-16931. This means that a recipient can still receive the invoice according to the core invoicing model. It is possible to restrict the content, for example by providing optional information for mandatory information or by restricting the code lists used. In addition, descriptions can be provided to explain what information is expected in a particular field.
The German XRechnung as an example
- The postcode in the address details is optional for the core invoice, but it is a required field in the XRechnung. Otherwise, the address details would be incomplete.
- The BT-10 ‘Buyer Reference’ field is optional for the core invoice model. For recipients in public administration, however, this information is mandatory to identify the correct department for the recipient. Public servants need to put the Leitweg-ID – a routing ID – in this field.
Unlike a CIUS, an extension allows you to extend the scope of the Core Invoice. An extension must conform to the Core Invoice. This means that you have all the features of the core invoice model, with additional functionality on top.
Examples include:
- Extensions are made to a code list, such as the extension of the code list for 'Mime type codes' to include the code application/xml for the types of possible attachments (see XRechnung Extended rule BRDEX-01 for BT-125 'Attached document').
- An extension of the semantic and therefore syntactic scope is made (see XRechnung Extended – SUB INVOICE LINE [BG-DEX-01] information about individual subordinate invoice items).
The rules for creating an extension have been laid out in the supporting technical specifications and reports for EN-16931 Part 5 (CEN/TR 16931-5:2017, eInvoicing – Part 5 Guidelines on the use of sector or country extensions in conjunction with EN 16931-1, methodology to be applied in the real environment.)
What Core Invoice Usage Specifications or extensions are there for EN-16931?
Here are some prominent examples:
- Germany: XRechnung and XRechnung Extended
- Germany, France, Switzerland: ZUGFeRD/FacturX 2.0, 2.1, 2.2, 2.3 Comfort profile /EN-16931 and Extended profile
- The Netherlands: SIUBL 2.0 (The Netherlands)
Some countries have not defined their own CIUS or extension, but use the Peppol BIS Billing 3.0 specification from Open Peppol in the Peppol network.
Do you need specialist knowledge to create an e-invoice as per EN-16931?
This question cannot be answered with a simple 'yes' or 'no'. Instead, we need to consider two perspectives:
- Technical execution: creating an invoice in one of the given syntaxes
- Content execution
The technical execution requires specialist knowledge of the structure. This knowledge is either found within a company's in-house IT department, or is bought in from outside through external service providers.
The essential content of the semantic model should be known to the issuer of an invoice. This is regardless of whether the invoice is digital or paper-based. This content is not significantly different from the information that an analogue invoice must contain to meet the requirements of VAT legislation or general invoice verification rules. The content must meet the requirements of the European Core Invoice and the business and verification rules defined therein. This is the only way to ensure a standardized and automated verification of the different invoice components. Deviations from these rules are not accepted when processing an e-invoice. Therefore, no specialist knowledge is required, but the semantic definition and the associated business rules should also be known to the department. Only then can they embed their content requirements in this environment.
A common problem in practice is that of rounding differences, which can occur when, for example, already rounded values are transferred during processing or data updates in the ERP systems. The European Core Invoice rules do not provide any tolerances for rounding differences in the checks. The common practice of tolerating small rounding differences in existing invoicing practices, whether paper-based or EDI (EDIFACT INVOICE), cannot be generally applied to the electronic invoice due to the general validation rules from EN-16931. Public portals in particular usually reject invoices that do not comply with the rules directly.
If rounding differences cannot be avoided completely, KoSIT has issued a recommendation for action. This is based on the use of BT-114 (Rounding Amount) in the invoice totals (BG-22 ‘Document Totals’).
4. More information about European Core Invoice
Blog
