SIST-TP CEN/TR 16931-10:2025

SLOVENSKI STANDARD
01-december-2025
Elektronsko izdajanje računov - 10. del: Dodatne zahteve za razširitev na B2B
Electronic invoicing – Part 10: Additional requirements to extend to B2B
Elektronische Rechnungsstellung - Zusätzliche Anforderungen zur Ausweitung auf B2B
Ta slovenski standard je istoveten z: CEN/TR 16931-10:2025
ICS:
03.100.20 Trgovina. Komercialna Trade. Commercial function.
dejavnost. Trženje Marketing
35.240.63 Uporabniške rešitve IT v IT applications in trade
trgovini
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TR 16931-10
TECHNICAL REPORT
RAPPORT TECHNIQUE
September 2025
TECHNISCHER REPORT
ICS 35.240.63; 35.240.20
English Version
Electronic invoicing - Part 10: Additional requirements to
extend to B2B
Elektronische Rechnungsstellung - Zusätzliche
Anforderungen zur Ausweitung auf B2B

This Technical Report was approved by CEN on 2 June 2025. It has been drawn up by the Technical Committee CEN/TC 434.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 16931-10:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
4 Background . 9
4.1 Facilitating business . 9
4.2 An Analogy for the Core Invoice Model . 11
4.2.1 General. 11
4.2.2 Understanding the Core . 12
4.2.3 Understanding Extensions . 14
4.3 Extensions as a visual analogy . 14
4.4 State of Play . 15
5 The need for Extension Components . 16
5.1 Low adoption rates . 16
5.2 Challenges in diverse business sectors . 17
5.3 Extension components improve interoperability of Extensions . 18
5.4 The benefits of Extension Components . 20
5.5 Using Extension Components . 21
5.5.1 General. 21
5.5.2 Sectors creating eInvoice Specifications . 22
5.5.3 Publishing to the Registry . 25
5.6 Maintenance cycle . 27
5.7 Importance for Stakeholders . 28
6 Adaptations to the Extension Methodology . 29
6.1 General. 29
6.2 Updating the Extension Methodology and EN. 29
6.3 Adding the concept of An Extension Component . 29
6.3.1 General. 29
6.3.2 Proposed Updates . 29
6.3.3 Implications of Proposed updates . 29
6.4 Revising text related to Extensions within the EN Part 1 . 30
6.4.1 General. 30
6.4.2 Current text . 30
6.4.3 Proposed Updates . 30
6.4.4 Semantic Definitions and the use of the words contradiction and infringement . 30
6.4.5 Proposed update . 31
6.4.6 Implications of Proposed updates . 31
6.5 Revising the Definitions in the Extension Methodology . 31
6.5.1 Changing Current Definitions . 31
6.5.2 Proposed Updates . 31
6.5.3 Implications of the Proposed Updates . 31
6.6 Adding the concept of Extension Scope . 31
6.6.1 General. 31
6.6.2 Implications of adding an Extension Scope . 32
6.7 Allowed elements in Extension Components . 32
6.7.1 General. 32
6.7.2 Current Instructions . 32
6.7.3 Proposed Updates. 33
6.7.4 Implications of the Proposed Updates . 33
6.8 Cardinality changes in Extensions . 33
6.8.1 Current Instructions . 33
6.8.2 Proposed Updates — Rules and limitations . 33
6.8.3 Implications of Proposed Updates . 33
6.9 Business rules in Extensions: Additions and Removals . 34
6.9.1 Current Instructions . 34
6.9.2 Proposed Updates. 34
6.9.3 Implications of Proposed Updates . 34
6.10 Extending Code Lists in Extensions . 34
6.10.1 Current Instructions . 34
6.10.2 Proposed update to changing Code Lists . 35
6.10.3 Implications of Proposed Updates . 35
6.11 Changing formats in Extensions (Data types, lengths, etc.) . 35
6.11.1 Current Instructions . 35
6.11.2 Proposed Updates. 36
6.11.3 Implications of proposed updates . 36
6.12 Replacing TOGAF Definitions . 36
6.12.1 General . 36
6.12.2 Proposed Updates. 36
6.12.3 Implications of the Proposed Updates . 38
6.13 Development of an Extension Component Library . 38
6.13.1 General . 38
6.13.2 Implications of the proposed implementation . 38
6.14 Governance Framework . 39
6.14.1 General . 39
6.14.2 Implications of Proposed Updates . 39
6.15 Active Governance . 39
6.15.1 General . 39
6.15.2 Selecting the tools . 39
6.15.3 Active Governance Process for Extension Components . 42
6.15.4 Active Governance Process for Extension Specifications . 45
7 Conclusion . 47
Bibliography . 49

European foreword
This document (CEN/TR 16931-10:2025) has been prepared by Technical Committee CEN/TC 434
“Electronic invoicing”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared as part of a Grant Agreement (reference SA 2022-07e-Invoicing) from
the European Commission to CEN. NEN has been appointed by CEN to perform work in accordance with
their Specific Agreement with reference number Project 101098931 - e-Invoicing
This document is part of a set of documents, consisting of:
— EN 16931-1:2017 +A1:2019/AC:2020, 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;
— CEN/TS 16931-3-1:2017, Electronic invoicing — Part 3-1: Methodology for syntax bindings of the
core elements of an electronic invoice;
— CEN/TS 16931-3-2:2020, Electronic invoicing — Part 3-2: Syntax binding for ISO/IEC 19845 (UBL
2.1) invoice and credit note;
— CEN/TS 16931-3-3:2020, Electronic invoicing — Part 3-3: Syntax binding for UN/CEFACT XML
Industry Invoice D16B;
— CEN/TS 16931-3-4:2020, Electronic invoicing — Part 3-4: Syntax binding for UN/EDIFACT INVOIC
D16B;
— CEN/TR 16931-4:2017, Electronic invoicing — Part 4: Guidelines on interoperability of electronic
invoices at the transmission level;
— CEN/TR 16931-5:2017, Electronic invoicing — 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;
— CEN/TR 16931-6:2017, Electronic invoicing — Part 6: Result of the test of EN 16931-1 with respect
to its practical application for an end user;
— CEN/TS 16931-7:2020, Electronic invoicing — Part 7: Methodology for the development and use of
EN 16931-1 compliant structured Core Invoice Usage Specifications.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
Introduction
In a Communication (COM/2010/0712) the European Commission highlighted that the mass adoption
of e-invoicing within the EU is projected to lead to significant economic benefits. It is estimated that
moving from paper to eInvoices will generate savings of around EUR 240 billion over a six-year period.
The Commission expressed a goal for eInvoicing to become the predominant method of invoicing in
Europe by 2020.
Directive 2014/55/EU on electronic invoicing in public procurement facilitates the use of electronic
invoices by economic operators when supplying goods, works and services to public administrations
(B2G), as well as supporting trading between economic operators themselves (B2B). It establishes the
legal framework for the adoption of a European Standard (EN) for the semantic data model of the core
elements of an electronic invoice (EN 16931-1).
In line with Directive 2014/55/EU, after publication of the reference to EN 16931-1 in the Official Journal
of the European Union, contracting public authorities and entities in the EU are required to receive and
process an eInvoice if it conforms to the semantic content described in EN 16931-1, is represented in any
of the syntaxes identified in CEN/TS 16931-2 in accordance with the request referred to in Paragraph 1
of Article 3 of Directive 2014/55/EU, and conforms to the appropriate mapping defined in the applicable
subpart of CEN/TS 16931-3
The semantic data model of the core elements of an electronic invoice – the core invoice model – as
described in EN 16931 1 defines a limited but sufficient set of information elements that support
generally applicable invoice-related functionalities.
In most situations, business partners use the core invoice model exclusively and the invoices they send
or receive do contain additional structured information elements. In some sectors or situations with
specific additional information requirements, the required information is conveyed in the form of
unstructured text, which cannot be processed automatically and requires human intervention.
Alternatively, specific information requirements can be implemented using information elements that
extend the core invoice model. These circumstances allow for the definition of additional information
elements while still utilising the concepts of the core invoice model.
In other situations, additional guidance or restrictions on the use of the information elements defined in
the core invoice model are documented in a core invoice usage specification as outlined in EN 16931-1.
Guidelines on the optional use of extensions to the Core Invoice Model, including a methodology to be
applied in real environments, were developed to align with the provisions of Directive 2014/55/EU.
This document identifies and documents additional Business Requirements to support the increased use
of electronic invoicing (eInvoicing) in the Business-to-Business (B2B) market within the European
Economic Area (EEA) and CEN Member states. It provides updates and extensions to the current
standards, particularly EN 16931-1 and CEN/TR 16931-5, to better facilitate B2B transactions.
Included in the Scope are:
— Core Invoice Model (EN 16931-1): Enhancements and adaptations to address specific B2B
requirements while maintaining compliance with the foundational elements.
— Extension Methodology (CEN/TR 16931-5): Revisions and updates to the Extension Methodology to
incorporate new Business Requirements and facilitate the creation of interoperable Extension
Components.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52010DC0712
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32014L0055
— Integration of Additional Requirements: Identification and integration of additional sector-specific
and cross-sector Business Requirements into the existing standard framework.
— Harmonisation with EU Parliament Work: Ensuring that the updates align with ongoing and future
initiatives by the EU Parliament to support a cohesive eInvoicing strategy across the EU.
Excluded from the Scope are:
— Detailed Implementation Guidelines: While the document provides the framework and requirements
for extensions, detailed implementation guidelines for specific software solutions or bilateral
agreements are not covered.
— Non-Standard Extensions: Extensions that do not conform to the defined methodology and are based
solely on bilateral agreements without broader applicability are excluded.
Primary Goals:
— Identify how to gather Business Requirements: How to gather and document additional Business
Requirements from various sectors to enhance the B2B eInvoicing process.
— Update EN 16931-1: Propose modifications to the Core Invoice Model to incorporate these new
requirements, ensuring it remains relevant and useful for B2B transactions.
— Revise CEN/TR 16931-5: Update the Extension Methodology to support the creation and use of
Extension Components, promoting greater interoperability and ease of use.
— Support B2B adoption: Facilitate the wider adoption of eInvoicing in the B2B market by addressing
specific needs and challenges faced by different industry sectors.
— Harmonise with existing Standards: Ensure that the proposed changes integrate smoothly with the
current standardisation deliverables and align with EU legislative and regulatory frameworks.
Relation to Other Parts of EN 16931
This document is directly related to and impacts the following parts of EN 16931:
EN 16931-1:2017: The core standard that defines the semantic data model of the core elements of an
electronic invoice. This document recommends updates to ensure the core model addresses additional
B2B requirements.
CEN/TR 16931-5:2017: Provides guidelines on the use of sector or country extensions in conjunction
with EN 16931-1. This document suggests revisions to the extension methodology, including the
introduction of Extension Components to better manage and utilise these extensions.
Disclaimer:
As a Technical Report the statements made are not normative and therefore are not binding. However, it
is expected that WG5 has agreed to implement any changes in future normative documents and approval
of this report shows the future direction and intent to cater to the needs of invoicing for Business to
Business (B2B) transactions.
1 Scope
This document focuses on identifying and documenting additional Business Requirements to support the
increased use of electronic invoicing (eInvoicing) in the Business-to-Business (B2B) market within the
European Economic Area (EEA) and CEN Member states. It aims to update and extend the current
standards, particularly EN 16931-1 and CEN/TR 16931-5, to better facilitate B2B transactions.
Included in the Scope are:
— Core Invoice Model (EN 16931-1): Enhancements and adaptations to the Core Invoice Model to
address specific B2B requirements while maintaining compliance with the foundational elements.
— Extension Methodology (CEN/TR 16931-5): Revisions and updates to the Extension Methodology to
incorporate new Business Requirements and facilitate the creation of interoperable Extension
Components.
— Integration of Additional Requirements: Identification and integration of additional sector-specific
and cross-sector Business Requirements into the existing standard framework.
— Harmonisation with EU Parliament Work: Ensuring that the updates align with ongoing and future
initiatives by the EU Parliament to support a cohesive eInvoicing strategy across the EU.
Excluded from the Scope are:
— Detailed Implementation Guidelines: While the document provides the framework and requirements
for extensions, detailed implementation guidelines for specific software solutions or bilateral
agreements are not covered.
— Non-Standard Extensions: Extensions that do not conform to the defined methodology and are based
solely on bilateral agreements without broader applicability are excluded.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1
core invoice model
semantic data model of the core elements of an electronic invoice
Note 1 to entry: The model contains mandatory information elements that every invoice includes, along with
optional elements that can be used when necessary.
3.2
mandatory core
core invoice Model information elements that are marked as mandatory
Note 1 to entry: These elements represent the legally required information included in all invoices, particularly for
use in public procurement
3.3
information element
specific piece of data that is used to represent a particular item of information within an electronic invoice
Note 1 to entry: Information elements are often grouped using Business Terms (BTs), which can be further
aggregated within Business Groups (BGs), such as the BG Seller, which contains relevant information about the
selling entity
3.4
business term
label assigned to a given information element, used as its primary reference
3.5
business group
group of related business terms
3.6
core invoice usage specification
CIUS
specification providing guidance, explanations, and rules related to the implementation and use of
structured information elements in the Core Invoice Model for specific trading situations
3.7
core invoice instance document
instance of an electronic invoice that conforms to the Core Invoice Model
3.8
extension specification
specification describing the use of additional information elements not defined in the Core Invoice Model,
that falls within the Scope for Extensions
Note 1 to entry: An Extension Specification may describe an invoice that includes Core Invoice Model elements,
Extension Components, and other elements needed for specific business requirements
Note 2 to entry: An Extension Specification can provide additional explanations and examples to support its use
3.9
extended invoice instance document
instance of an electronic invoice that conforms to an Extension Specification
3.10
eInvoice registry
registry of CIUS and Extensions, which define restrictions or Extensions to Core Invoice Model
Note 1 to entry: The Registry is currently hosted by the EU Commission
Note 2 to entry: It operates in an open, transparent, and free-of-charge manner
3.11
compliant
meets all the legal requirements and follows the binding legal rules associated with the standard
3.12
conformant
adheres to the applicable non-binding normative rules or guidelines of the standard
Note 1 to entry: When using Extensions, these should ideally be sourced from the Scope for Extensions or from an
existing Extension Component
3.13
scope for extensions
possible information elements or rules that can be used in an extension
Note 1 to entry: Where possible, information elements and their usage rules for Extensions are aligned with existing
models to ensure validation artefacts are preserved and function as expected
3.14
extension component
identified set of information elements and business rules, within the Scope for Extensions, that are not
covered by the Core Invoice Model and are needed to support a specific business requirement
Note 1 to entry: An Extension Component includes the necessary information elements and business rules and
specifies any Core rule it replaces.
Note 2 to entry: An Extension Component can encompass one or more business groups, which may include one or
more business terms.
3.15
extension component library
library of Extension Components governed by CEN TC 434
Note 1 to entry: All the elements in the Extension Components form a Data Model that can be enumerated in a
similarly to the Core Invoice Model
3.16
syntax
machine-readable text or format in which the invoice semantics are represented
Note 1 to entry: Syntax provides the structure for how invoice data is presented and processed.
4 Background
4.1 Facilitating business
Directive 2014/55/EU identified issues and barriers that were being created as a result of multiple
disparate methods of electronic invoicing (eInvoicing) being used throughout the EU. The Directive called
for the creation of a single European standard to remove these barriers to ensure that eInvoices can be
easily exchanged and processed across different systems and national boundaries within the EU.
EN 16931-1, the European eInvoicing standard, was created to meet these needs. The Directive mandated
that Central and Sub-central Public Bodies in Member States support the standard from April 2020.
Since then, any eInvoice that conforms with EN 16931-1 is accepted and processed by an EU Member
State Public Body for a B2G (business-to-government) transaction.
The EN 16931-1 set of standards describes the semantics, business rules and syntax that are required for
conformant eInvoicing. It also provides advice on transmission protocols that could be considered.
The OASIS UBL invoice and UN/CEFACT CII Models are the syntaxes mandated for B2G and are
considered as the Scope for Extensions.
WG5 proposed the following guidelines:
— It is intended that information elements for Extensions will be based on those defined in the UBL
Invoice or CII. Elements not standardised in these syntaxes are not expected to be included.
— Whenever feasible, the syntax version will align with one referenced in Part 2 List of Syntaxes.
— It is preferred that elements used for Extensions be available in both syntaxes whenever possible.
Defining a Scope for Extensions promotes interoperability and ensures that Extensions limited to this
scope can relatively easily be proven by using artefacts (schema) supplied by both UN/CEFACT and
OASIS. The Core Invoice Model, EN 16931-1, is a subset within the Scope for Extensions as demonstrated
in the diagram below.
Key
A UBL Invoice Model
B CII Model
Core Invoice Model (EN 16931-1)
Overlapping elements
Non-Overlapping elements
Figure 1 — The Scope for Extensions
Figure 1 illustrates the Extension Scope, which includes the Core Invoice Model (EN 16931-1) as a subset
of the overlapping of both UBL Invoice and CII Models. This overlap contains standardised information
elements that are easily usable for Extensions. While it is preferable to use these overlapping elements
due to their compatibility with both syntaxes, non-overlapping elements from only one model can also
be used when necessary. This approach allows an implementor to include a new information element
from one model, while waiting for alignment with the other model. Governance can involve monitoring
changes to either model to ensure that necessary adjustments are made accordingly.
Feedback from business communities has indicated a large and varied number of business requirements
for their invoices. Accommodating all those requirements in the standard, however, would be
counterproductive as the invoice would become complex and, in many cases, too much of a technical
burden for smaller businesses to bear. The EN solved this problem by describing the Core Invoice Model,
which is comprised of the most commonly used information elements used in invoices. The aim of the
Core is to support the most common requirements, while also recognising that it did not meet all
requirements of all businesses. For this reason, the concept of Extensions to the Core was recognised and
has been an integral part of the EN.
The Core contains the elements of an electronic invoice containing over 200 individual information
elements. 35 of which are mandatory to support while the rest are optional. It has been said, anecdotally,
that this could cover 80% of all business requirements. The Core defines and describes all the Business
Terms and Groups that can be used in conformant eInvoicing. eInvoicing parties have the option to
support the full Core, the Mandatory Core, or a specific selection of all mandatory and some optional
elements, which can be mandated in a CIUS (Core Invoice Usage Specification). The objective was to
create a model that allows for the flexibility required to meet both large and small invoicing
requirements, while keeping the standard as simple as possible.
4.2 An Analogy for the Core Invoice Model
4.2.1 General
The flexible methodology/concept of the Core Invoice Model can be confusing for some, particularly first-
time users. To simplify the concept, an analogy that is more relatable can be used to express the flexibility
of the standard. In the figure below, imagine the Core Invoice Model as a vehicle with various optional
extras.
Figure 2 — EN 16931-1, the Core Invoice Model, as a visual analogy
There are two methods of providing a specification that is conformant with the Core Invoice Model:
• supporting the full Core Invoice Model (vehicle with all optional extras)
• supporting a CIUS of the Core Invoice Model (vehicle with some or none of the optional extras).
Supporting the full Core Supporting a CIUS of the Core

a) EN 16931-1 b) CIUS c) Mandatory Core
When the full Core Invoice Model is  When some of the Optional
supported, you are maximising elements of the Core Invoice
interoperability potential Model are excluded from invoice
specifications this is considered a
CIUS of
EN 16931-1
When all the Optional elements of the Core Invoice Model are excluded from invoice specifications this is
considered as supporting the Mandatory Core which is also a type of CIUS
Figure 3 — Visual analogy of methods for supporting EN 16931-1, the Core Invoice Data Model
Deciding which method to support depends on the business’s invoicing requirements. Some businesses
use the full Core Invoice Model, while others only use the mandatory elements along with some optional
elements. This is similar to the analogy of choosing the base model of a vehicle with some or none of the
optional extras. Both methods of supporting EN 16931-1 include the Mandatory Core, i.e. the base model
of the vehicle, ensuring a high level of interoperability despite other differences in their invoicing
requirements.
When creating an invoice specification for a specific business need using specialist software, the process
begins by laying out the full Core Invoice Model. Optional elements that are not necessary are then
deselected. However, in the planning stages, all invoice specifications typically start with the Mandatory
Core elements (the base model of the vehicle). These elements, identified by CEN/TC 434 as legally
required and commonly used, are included in the invoice specification to conform with EN 16931-1. The
less common elements are considered optional and are added as needed, particularly if required to enable
automation of the invoice processing.
Using the vehicular analogy, a business defining their eInvoicing Specification is similar to a car
dealership customer ordering their new vehicle. They begin with the base model of their chosen vehicle
(the Mandatory Core of EN 16931-1) and then decide if they also require any of the available optional
extras.
4.2.2 Understanding the Core
It is important that the Core Invoice Model is fully understood in all scenarios. Implementors first
consider the entire Core when determining their needs and then decide how to handle unneeded
elements, possibly by archiving them. This approach ensures the system processing the Core can make
informed decisions about both mandatory and optional elements.
When a Buyer system receives elements that it does not need, it can recognise them as part of the Core
and take appropriate action. In some cases, this might mean archiving the elements without further
processing. However, rejecting these elements, as discussed below, is not ideal.
To further explore this concept we explore strict vs non-strict as defined in CEN/CWA Conformance and
Customizations methodology guideline.
Strict
• Strict Receiver: Accepts an eInvoice only if it meets their specific requirements as defined in a CIUS
or Extension Specification. Any additional elements cause the eInvoice to be rejected
• Strict Sender: Sends eInvoices that contain only the elements specifically required for each
transaction
Non-strict
• Non-Strict Receiver: Accepts eInvoices even if they contain elements that were not requested.
• Non-Strict Sender: Often includes more information elements in the invoices than what their Buyer
needs. This is because different Buyers need different information, so the Non-Strict Sender includes
all relevant elements in one invoice.

Key
A Strict Sender Can send to B and D
B Strict Receiver Can receive from A only
C Non-Strict Sender Can send to D only
D Non-Strict Receiver Can receive from A and C
Figure 4 — Strict vs Non-Strict
• Strict Sender to Strict Receiver: Interoperable because the Sender ensures they only send what is
required
• Strict Sender to Non-Strict Receiver: Interoperable because the Sender ensures they only send what
is required
• Non-Strict Sender to Strict Receiver: Not interoperable because the Non-Strict Sender sends extra
information that the Strict Receiver rejects.
• Non-Strict Sender to Non-Strict Receiver: Interoperable because the Non-Strict Receiver does not
reject the invoice if it contains extra information.
In the above graphic, the Non-Strict Receiver is the most flexible as it does not reject invoices that contain
elements not requested or omitted. In contrast, the Strict Sender is the most successful because they only
send what is strictly required.
4.2.3 Understanding Extensions
Extensions address the unique business needs of specific countries or sectors. Unlike the Core, Extensions
are relevant only to businesses in those countries or sectors. This approach simplifies electronic invoicing
by reducing the number of required information elements and rules. For example, mastering the CII or
UBL invoice formats involves familiarity with thousands of details. In contrast, the Core Invoice Model
narrows this down to about 200 essential Core Invoice elements, plus a manageable number of Extension
elements relevant to the specific country or sector the user operates in. This streamlined approach
facilitates the implementation of EN 16931-1 conformant electronic invoices by entities.
4.3 Extensions as a visual analogy
EN 16931-1 outlines a Core Invoice Model and anticipates the use of Extensions for more complex needs.
The focus of the Core Invoice Model is to maintain simplicity and user-friendliness. Overloading it with
too many information elements can lead to complexity, which can be challenging for first-time users.
The Core Invoice Model covers the general needs of invoicing, but sometimes businesses have more
specialised requirements. For instance, the vendor managed inventory (VMI) process has been
implemented by industries such as automotive, steel, and printing industries. The VMI business process
requires additional information elements, not present in the Core Invoice Model.
These Extensions pull from the broader elements found in comprehensive models of the UBL and CII
Invoices, which extend beyond the Core's scope. They are integrated with the mandatory and any chosen
optional information elements of the Core Invoice Model to form a complete Extension Specification. This
tailored specification ensures businesses meet their unique invoicing needs while staying conformant
with the EN 16931-1 standard.
Extensions act as add-ons to the Core, providing extra functionalities only when needed. They do not
impose these specific requirements on all businesses. This way, only the relevant sectors or parties use
these specialised elements, ensuring efficiency and compliance without overloading everyone with
unnecessary details.
In the figures below the vehicular analogy is expanded by imagining an Extension as a trailer that is
attached to a vehicle. The Extension operates in conjunction with the vehicle i.e. the Core Invoice Model.
The vehicle remains the driving force of the invoice, and the trailer carries additional information that
does not ‘fit’ in the vehicle (is not part of the Core Invoice Model), i.e. requirements that not everyone
needs. This vehicle/trailer combination is an Extension Specification.

Figure 5 — A visual analogy of an Extension Specification that supports the Mandatory Core and
an Extension
The above figure shows a use case where the business requirement includes an Extension but only the
mandatory Core, i.e. no optional extras are used.
Figure 6 — A visual analogy of an Extension Specification that supports a CIUS and an Extension
The above figure shows a use case where the business requirement includes an Extension and a Core that
is restricted i.e. some optional extras are included.

Figure 7 — A visual analogy of an Extension Specification that supports the full Core and an
Extension
The above figure shows a use case where the business requirement includes an Extension and the full
Core, including all optional extras.
It is important to note that the trailer cannot drive itself, similar to how an Extension cannot work without
at least the mandatory elements of the Core data of the eInvoice.
4.4 State of Play
EN 16931-1 now serves as a cornerstone in the landscape of eInvoicing within Europe. It has become a
critical component in modernising procurement transactions within Europe, ensuring the region is fit for
the digital age . This involves leveraging digital technologies to drive economic growth and streamline all
aspects of business and governance.
By adopting eInvoicing, companies can automate related processes, significantly speeding up
transactions and reducing manual errors. This efficiency is particularly beneficial for businesses handling
a large volume of transactions, especially those involved in B2B (business-to-business) and B2G
(business-to-government) transactions.
For SMEs (small and medium-sized enterprises), having eInvoicing functionality integrated into their
accounting systems is advantageous. Built-in eInvoicing capabilities enable SMEs to benefit from
automation without needing additional software or extensive training, making it a valuable tool for their
operations.
eInvoicing using EN 16931-1 ensures interoperability, which facilitates smooth cross-border trade and
efficient business transactions within the EU. The standard also helps ensure compliance with legal
requirements, such as those required for VAT. By adhering to EN 16931-1, businesses align with the
specific requirements of Directive 2014/55/EU and position them
...