SIST-TS CEN/TS 16931-5:2025

SLOVENSKI STANDARD
01-december-2025
Nadomešča:
SIST-TP CEN/TR 16931-5:2017
Elektronsko izdajanje računov - 5. del: Smernice za uporabo v sektorju ali državi v
povezavi z EN 16931-1, metodologija za uporabo v realnem okolju
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
Elektronische Rechnungsstellung - Teil 5: Leitfaden über die Verwendung von branchen-
oder länderspezifischen Erweiterungen der EN 16931-1 einschließlich einer im realen
Umfeld einzusetzenden Methodik
Facturation électronique - Partie 5: Lignes directrices relatives à l'utilisation des
extensions de secteur ou de pays conjointement avec l'EN 16931-1, avec une
méthodologie à appliquer dans l'environnement réel
Ta slovenski standard je istoveten z: CEN/TS 16931-5: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/TS 16931-5
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
October 2025
TECHNISCHE SPEZIFIKATION
ICS 35.240.20; 35.240.63 Supersedes CEN/TR 16931-5:2017
English Version
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
Facturation électronique - Partie 5: Lignes directrices Elektronische Rechnungsstellung - Teil 5: Leitfaden
relatives à l'utilisation des extensions de secteur ou de über die Verwendung von branchen- oder
pays conjointement avec l'EN 16931-1, avec une länderspezifischen Erweiterungen der EN 16931-1
méthodologie à appliquer dans l'environnement réel einschließlich einer im realen Umfeld einzusetzenden
Methodik
This Technical Specification (CEN/TS) was approved by CEN on 27 July 2025 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

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 NORMALISATIO N

EUROPÄISCHES KOMITEE FÜR NORMUN G

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/TS 16931-5:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 6
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 8
4 The challenge of interoperability . 12
4.1 Interoperability through standardization . 12
4.2 The challenge . 12
5 Extension Components . 13
5.1 The benefits of Extension Components . 13
5.2 Assessing Extension Components . 13
5.3 Developing and publishing Extension Components . 13
5.4 Maintenance cycle - Maintaining Extension Components . 16
5.5 Importance for Stakeholders . 17
6 Extension Specifications . 18
6.1 General . 18
6.2 The purpose of Extension Specifications . 18
6.3 Who will develop Extension Specifications and why? . 18
6.4 Using the Scope for Extensions. 19
6.5 What may be specified in an Extension Specification . 19
6.6 Documentation of Extension Specifications . 23
6.7 Mapping to syntax . 23
6.8 Governance of Extension Specifications . 23
6.9 Identification of Extension Specifications . 23
7 Claiming Conformance . 24
7.1 Compliance vs Conformance . 24
7.2 Conforming objects . 25
7.3 Conformance of Extension Specifications . 25
7.3.1 General . 25
7.3.2 Core Conformant . 25
7.3.3 Partly Core Conformant . 25
7.3.4 Comparison of Core Conformance and Partly Core Conformance . 25
7.4 Determining Conformance . 26
7.5 Conformance of an Extended Invoice Instance Document . 27
8 The process of creating an Extension Specification . 27
8.1 How parties agree on using an Extension Specification . 27
8.2 Statement of objectives . 27
8.3 Gathering of business requirements . 27
8.4 Mapping against the Core Invoice Model . 27
8.5 Evaluate what is currently in use . 28
8.5.1 General . 28
8.5.2 Using Extension Components . 28
8.6 Re-evaluate requirements and/or re-evaluate processes . 33
8.7 List requirements . 33
8.8 Define required changes . 33
8.9 Create specification . 34
8.10 Evaluate type of changes . 34
8.11 Publish Extension Specification . 34
8.11.1 General . 34
8.11.2 How end users use the Registry. 36
8.12 Bind to syntax. 37
Bibliography . 38
European foreword
This document (CEN/TS 16931-5: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 supersedes CEN/TR 16931-5:2017.
This document includes the following significant technical changes with respect to
CEN/TR 16931-5:2017:
— updating concepts in alignment with EN 16931-1;
— introducing the concept of Extension Components. This should greatly improve interoperability
cross-sector and intra-EU where Extended Information Elements are required;
— changing the definition of the Terms Compliant and Conformant. Previously they were based on
TOGAF terminology[10]. This avoids confusing the terms when used in legal text compared to
normative text;
— compliant now refers only to legal specifications;
— conformant refers only to normative text;
— recommending the use of multilateral business agreements rather than bilateral when using
Extension Specifications.
This document is part of a set of documents, consisting of:
— EN 16931-1:— , 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
Under preparation. Stage at the time of publication: prEN 16931-1:2025.
— CEN/TR 16931-4:2017, Electronic invoicing — Part 4: Guidelines on interoperability of electronic
invoices at the transmission level
— CEN/TS 16931-5:2025, 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
— CEN/TS 16931-8:2024, Electronic invoicing — Part 8: Semantic data model of the elements of an e-
receipt or a simplified electronic invoice
— CEN/TR 16931-9:2024, Electronic invoicing — Part 9: VAT reporting and gap analysis with current
e-invoicing standardization deliverables
— CEN/TR 16931-10:2025, Electronic invoicing — Part 10: Additional requirements to extend to B2B
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.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: 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 the
United Kingdom.
Introduction
The European Commission states that “The mass adoption of eInvoicing within the EU would lead to
significant economic benefits and it is estimated that moving from paper to Electronic Invoices will
generate savings of around EUR 240 billion over a six-year period” [1]. Based on this recognition “The
Commission wants to see eInvoicing become the predominant method of invoicing by 2020 in Europe
[1].”
As a means to achieve this goal, Directive 2014/55/EU [2] on electronic invoicing in public procurement
aims at facilitating the use of Electronic Invoices by economic operators when supplying goods, works
and services to public administrations (B2G), as well as the support for trading between economic
operators themselves (B2B). In particular, it sets out the legal framework for the establishment and
adoption of a European Standard (EN) for the semantic data model of the core elements of an Electronic
Invoice (EN 16931-1).
The semantic data model of the core elements of an Electronic Invoice – the Core Invoice Model – as
described in EN 16931-1 is based on the proposition that a limited, but sufficient, set of Information
Elements can be defined that supports generally applicable invoice-related functionalities.
In many cases, businesses will use only the Core Invoice Model for their invoices, without needing to add
any extra structured data. Sometimes, additional guidelines or restrictions on how to use the existing
data elements in the Core Invoice Model are necessary. These can be specified in a Core Invoice Usage
Specification (CIUS), as described in EN 16931-1. In certain industries or situations where specific extra
information is required, this information might be included as unstructured text. The drawback of
unstructured text is that it cannot be processed automatically and requires manual effort. If machine-
readable information is needed that is not covered by the Core Invoice Model, there will be a need to use
Extended Information Elements.
In order to comply with the provisions of Directive 2014/55/EU [2], guidelines on the optional use of
Extended Information Elements, including a methodology to be applied in the real environment, are
needed. This Technical Specification provides this methodology and complies at least with the following
criteria:
— is technologically neutral;
— is compatible with relevant international standards on electronic invoicing;
— has regard to the need for personal data protection in accordance with Directive 95/46/EC [3], to a
‘data protection by design’ approach and to the principles of proportionality, data minimization and
purpose limitation;
— is consistent with the relevant provisions of Directive 2006/112/EC [4];
— allows for the establishment of practical, user-friendly, flexible and cost-efficient electronic
invoicing;
— takes into account the special needs of small and medium-sized enterprises as well as of sub-central
contracting authorities and contracting entities;
— is suitable for use in commercial transactions between enterprises.
The methodology and rules described in this document are based on the following key design principles:
— Extended Information Elements are defined in an Extension Specification.
— Extension Specifications are used to provide user communities with the ability to add Information
Elements or functions to the Core Invoice Model to support their specific business requirements.
— Extension Components identify common requirements and solutions that can be reused in Extension
Specifications.
— A business Extension Specification is not intended to be used to specify legally required Information
Elements or expected to be obligated by law. Common legal requirements should be covered in the
Core Invoice Model, while Country Extension Specifications may be created to cover specific
domestic laws.
— Information provided in supplementary documents (attachments) to an invoice are not considered
to be Extended Information Elements, as these are an integral part of the Core Invoice Model.
— Extension Specifications should not be used to remove Information Elements from the Core Invoice
Model, only to add Information Elements.
— Extension Specifications should be made publicly available in an appropriate repository in order to
foster awareness and reuse, as this is expected to foster convergence over time.
— Extension Specifications reuse the syntax binding methodology applied to EN 16931-1.
— The actual implementation and use of an Extension Specification is subject to agreement between
the trading partners.
1 Scope
This document describes how trading partners may extend the Core Invoice Model and the related
business rules and code lists, to support business cases that are specific to their trading environment,
while at the same time maintaining semantic interoperability with the Core Invoice Model.
This document does not define a methodology for creation of a Core Invoice Usage Specification, nor does
it describe the detailed process of syntax binding.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 16931-1:—, Electronic Invoicing — Part 1: Semantic Data Model of the Core Elements of an Electronic
Invoice
CEN/TS 16931-2, Electronic invoicing — Part 2: List of syntaxes that comply with EN 16931-1
CEN/TS 16931-3-1, Electronic invoicing — Part 3-1: Methodology for syntax bindings of the core elements
of an electronic invoice
CEN/TS 16931-3-2, Electronic invoicing — Part 3-2: Syntax binding for ISO/IEC 19845 (UBL 2.1) invoice
and credit note
CEN/TS 16931-3-3, Electronic invoicing — Part 3-3: Syntax binding for UN/CEFACT XML Industry Invoice
D16B
CEN/TS 16931-3-4, Electronic invoicing — Part 3-4: Syntax binding for UN/EDIFACT INVOIC D16B
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
electronic invoice
invoice that has been issued, transmitted and received in a structured electronic format which allows for
its automatic and electronic processing
[SOURCE: Directive 2014/55/EU [1]]
3.2
information element
smallest unit of data that is used to represent an item of information within an electronic invoice
Note 1 to entry: The EN identifies these elements using Business Terms (BTs) in EN 16931-1.
3.3
structured information element
information element that can be processed automatically
3.4
business term
label assigned to a given information element which is used as a primary reference
3.5
business group
group of related business terms
Note 1 to entry: BTs can be aggregated within Business Groups (BGs). For example, the BG Seller contains all the
Information Elements needed to describe the entity that is selling the good or service. BG Seller also contains its
own BGs such as address and contact i.e. BG Seller acts as a parent Group to child Groups for addresses and contact
details that are related to the Seller.
3.6
semantic data model
structured set of logically interrelated information
3.7
core invoice model
semantic data model of the core elements of an electronic invoice
Note 1 to entry: The model contains the core elements of an Electronic Invoice – see EN 16931-1:—, Clause 4 for
a more detailed explanation. The Core Invoice Model is composed of mandatory Information Elements that every
invoice contains along with conditional elements that can be used when required.
3.8
mandatory core
core invoice model information elements that are marked as mandatory
Note 1 to entry: All invoices contain the legally required Information Elements in the Mandatory Core i.e. those
mandated by the current version of the VAT Directive 2006/112/EC and, for Public Bodies, Directive 2014/55/EU
electronic invoicing in public procurement).
3.9
core elements of an electronic invoice
set of essential information elements that an electronic invoice may contain in order to enable cross-
border interoperability, including the necessary information to ensure legal compliance
3.10
extended information element
information element within the scope for extensions but outside the core invoice model
Note 1 to entry: Extended information elements are sometimes informally referred to as extensions in other
documents.
3.11
core invoice usage specification
CIUS
specification that provides detailed guidance, explanations, and examples, as well as rules (business
rules) related to the actual implementation and use of information elements present in the core invoice
model in a specific trading situation
3.12
core invoice instance document
instance of an electronic invoice that is conformant with the core invoice model
3.13
extension specification
specification describing the use of extended information elements to the core invoice model that may
reuse extension components
Note 1 to entry: An Extension Specification is intended to be published in the Registry of CIUS and Extensions. It
is typically written by a Representative/Representatives of a Sectoral Organization for its members to describe an
Invoice that includes the Core Semantic Model elements, Extension Components, and other elements needed for
business.
Note 2 to entry: The resulting invoice model contains Information Elements that do not form a strict subset of the
Core Invoice Model. An Extension Specification can also provide additional explanations and examples.
3.14
extended invoice instance document
instance of an electronic invoice that is valid with an extension specification
3.15
identifier
character string used to establish the identity of, and distinguish uniquely, one instance of an object
within an identification scheme from all other objects within the same scheme
Note 1 to entry: An identifier may be a word, number, letter, symbol, or any combination of those, depending on
the Identification Scheme used
3.16
identification scheme
collection of identifiers applicable for a given type of object governed under a common set of rules
3.17
mandatory syntaxes
syntaxes identified in CEN/TS 16931-2; list of syntaxes that comply with EN 16931-1
3.18
scope for extensions
possible information elements or rules that can be used in an extension specification limited to the
semantic information elements contained in the mandatory syntaxes
Note 1 to entry: Extended Information Elements and their rules for use in Extension Specifications are obtained
from the Mandatory Syntaxes to help ensure validation is simplified. However, this specification is agnostic to
syntax, so it only refers to data models
3.19
registry of CIUS and extensions
registry (also known as eInvoice registry) containing CIUS specifications and extension specifications for
all country and business requirements within the EEA
Note 1 to entry: Hosted by the EU Commission.
https://ec.europa.eu/digital-building-
Note 2 to entry: Can be found in the eInvoicing User Community pages at
blocks/sites/display/EINVCOMMUNITY/eInvoicing+User+Community.
Note 3 to entry: The Registry is open, transparent and free of charge.
3.20
compliant
meets all the legal requirements and follows all the legal rules of any Directive associated with the
standard, particularly the VAT Directive
3.21
core conformant
respects all the normative rules of the core invoice model
Note 1 to entry: A Core Conformant instance is not expected to throw any error when using WG3 validation
artefacts for the Core Invoice Model.
3.22
partly core conformant
one or more normative rules of the core invoice model is not respected
Note 1 to entry: A Partly Core Conformant instance is expected to throw an error when using CEN/TC 434 WG3
validation artefacts for the Core Invoice Model.
3.23
extension component
reusable identified set of information elements and business rules, within the scope for extensions, but
outside the scope of the core invoice model
Note 1 to entry: The extension component includes the required information elements and business rules and
identifies any core rule it replaces.
Note 2 to entry: An extension component can include one or more business groups that include one or more
business terms.
3.24
syntax
machine-readable format used to represent the information elements contained in an electronic invoice
instance
Note 1 to entry: CEN/TS 16931-2 contains the list of mandatory syntaxes.
4 The challenge of interoperability
4.1 Interoperability through standardization
The Core Invoice Model is designed to support the commercial needs of electronic invoicing in most
business scenarios, whether B2G or B2B. It is intended to align with the common legal requirements for
invoicing in EU Member States. Structured Information Elements use codes or Identifiers wherever
possible to enable automated processing. However, some elements may appear in unstructured text form
to facilitate visualization or store notes that can be manually reviewed.
The Core Invoice Model thus represents the baseline for semantic interoperability in electronic invoicing.
Trading partners are, however, free to organize the use of appropriate Extension Specifications
comprising additional Extended Information Elements and functionalities not included in the Core
Invoice Model, especially those marked out of scope in EN 16931-1. Such Extension Specifications should
preferably be created at an industry or sectoral level based on Extension Components (see below).
4.2 The challenge
Achieving semantic interoperability faces a significant challenge due to the unique requirements of
various industry sectors. Specific business processes often demand sector-specific information and, as
invoicing implementations mature, they frequently require a higher degree of automation. This is
especially true in sectors with complex workflows or ERP systems that need to support additional
Information Elements to meet industry-specific requirements.
A Core Invoice Model that is designed to address all possible sector requirements would become vast and
highly complex, making it challenging to implement, especially for those using eInvoicing for the first
time. Such complexity would also pose a particular challenge for ERP developers, who benefit from a
concise Core Invoice Model that they can easily understand and implement. With this foundational model,
ERP developers can then selectively decide which Extension Specifications to include, if any, allowing
them to meet their clients' specific needs in a relatively easier way.
Extension Components are specifically designed to address situations where cross-industry (aka cross-
sector) requirements go beyond what is covered by the Core Invoice Model. This often occurs when use
cases fall outside the scope of the Core Invoice Model, such as those involving more complex processing
needs. By incorporating common Extension Components into an Extension Specification instead of using
sector-specific solutions, invoicing becomes cross-sector. This approach reduces the need for bilateral
agreements and instead promotes sector-wide agreements, significantly enhancing interoperability.
Some business requirements for B2B transactions may conflict with the rules of the Core Invoice Model
due to legacy processes that are difficult to change. Since the Core Invoice Model and its Extension
Components are both designed to ensure interoperability, it’s important to address these conflicts
carefully to minimize their impact.
This methodology provides a clear framework to manage such situations. It defines which types of
conflicts, or contradictions, are allowed and ensures they are handled in a way that supports
interoperability. Table 1 in Clause 6 lists the types of amendments that are allowed, while Clause 7
explains how to claim conformance when these amendments are applied. This approach helps businesses
align their needs with the Core Invoice Model while maintaining conformance.
5 Extension Components
5.1 The benefits of Extension Components
Extension Components are designed to help develop interoperable Extension Specifications, addressing
common invoicing requirements that are either not fully covered or intentionally excluded from the Core
Invoice Model.
A major advantage of Extension Components is their potential for reuse across different sectors. This
approach aims to ensure that, especially for cross-sector requirements, these components are
implemented in a way that promotes enhanced interoperability across countries and business sectors.
This is vital for maintaining a cohesive and efficient Digital Single Market within the EU, enabling
businesses to seamlessly conduct transactions across borders and sectors.
Industry-Specific Adaptability: These components allow for the inclusion of specific details pertinent
to various sectors, such as promotional information in retail or parts identification in automotive,
ensuring invoices are both conformant to the EN 16931 standard and relevant to the industry.
Cross-Sector Interoperability: They facilitate seamless communication across different industries,
enhancing the interoperability while also facilitating cross-border transactions. This is key to an
integrated Digital Single Market within the EU.
Operational Efficiency and Accuracy: By organizing necessary details in a standardized format, these
components reduce the need for additional documentation and minimize errors, leading to quicker
processing and payment cycles.
VAT compliance: They ensure adherence to VAT regulations by maintaining legal compliance and not
overriding the eInvoicing requirements specified in the VAT Directive. This contributes to the
simplification of VAT reporting.
Overall, common Extension Components support the specific operational needs of businesses while
maintaining conformance to EN 16931-1 Core Invoice Model and complying with the EU’s regulatory
framework. This contributes to a more efficient and interoperable digital economy in Europe.
5.2 Assessing Extension Components
An Extension Component Group (ECG) should be established to manage the complete lifecycle of
Extension Components, encompassing assessment, development, and ongoing maintenance.
Members should be selected from CEN/TC 434 and should also include invited stakeholders from
relevant business sectors, technical experts, and possibly observers from regulatory bodies.
5.3 Developing and publishing Extension Components
It is expected that new Extension Components should be continually developed as it is not possible to
gather all common business needs, at least initially. This means that there will be cases where
specifications do not use Extension Components because they are not yet developed. However, once the
Extension Components are developed and published, Extension Specifications should be updated to
include them.
Figure 1 — High-level process for creating Extension Components
There are 7 stages involved in creating an Extension Component
1. Stakeholders identify and document the business requirement using the template outlined in stage
— Sources include:
— CEN/TC 434
— Other B2B Requirements repositories
— Direct proposals from Business and Public Sector organisations
2. ECG assesses the business requirements
— ECG undertakes an initial assessment of the requirements to ensure it has the required
information, and there are no duplicates or pre-existing Components that covers these
requirements. It will then require additional information to help start the next stage.
The following template should be used during the initial assessment:
Background
High-Level Business Requirement
— Purpose
— Functional Requirements
— Technical Requirements
— Compliance
3. ECG creates a draft Extension Component
— ECG Editors draft the Extension Component based on the analysis
The following template should be used when creating Extension Components:
Identification
— Title
— Identifier
— Component version
— Status
— Date of publication
— Core version
— BT-24 Specification Identifier prefix
— Source
— Repository location
— Labels
The business requirement
— High-level description of requirement
— Purpose and usage
— Legal considerations
— Additional content to be considered
— Who needs to understand/target market?
The solution
— Changed Core Invoice Model Information Elements
— Type of change(s)
— Identify rules that are affected in the Core Invoice Model
— New Information Elements
— New rules
4. Stakeholders review the draft Extension Component
— Stakeholders are invited to discuss the draft Extension Component at an ECG meeting
5. ECG revise draft Extension Component
— If Stakeholders reject the draft Extension Component, updates are made based on comments
received and the updated draft is ready to be reviewed by Stakeholders (return to stage 4).
Stages 4 and 5 may iterate until the draft is considered suitable for publication
6. ECG defines syntax binding
— The Extended Information Elements are checked to ensure that the elements are valid according
to the appropriate data models in the Scope for Extensions.
— If required elements are missing from one or both syntaxes, CEN/TC 434 WG3 will begin the
process for including them by initiating a change request.
— Syntax bindings are created
— Validation Artefacts are created
7. The Extension Component is published
— The Extension Component is published, and its status is set to ‘published’
— Stakeholders are notified that the Extension Component is now available to be included in
Extension Specifications
5.4 Maintenance cycle - Maintaining Extension Components
Existing Extension Components also need to be maintained. They may have errors or, if seen to be very
common, they should be promoted to be part of the Core Invoice Model. Conversely Information Elements
in the Core Invoice Model should be demoted to an Extension Component if their use is found not to be
common. However, these changes can only be made following a TC Ballot as part of the CEN process,
when the majority believe they can accept these changes. This is important because some changes require
significant alteration. Typically, CEN standards have a life cycle of 5 years, and only essential changes,
such as correcting significant errors, are made more quickly.
In the diagram below the maintenance cycle of the EN is shown. This includes both the Core Invoice Model
and Extension Components. Highly used Extension Components can be considered for promotion to the
Core Invoice Model. Conversely, unused or rarely used Information Elements from the Core Invoice Model
can be considered for demotion. Once the promotion or demotion is approved, the Information Element
can be updated in the next amendment or revision. This level of monitoring and action ensures that the
Core Invoice Model and Extension Components are relevant while also preventing bloat or build-up of
complexity.
a) High usage of an Extension b) Call to Action – Ballot c) Action achieved
Component is noted by ECG
CEN TC 434 receives a CEN TC 434 nominate the The Extension Component is
request for promotion Extension Component for promoted, EN is amended
promotion
After a review, CEN TC 434
organize the ballot
Key
A Mandatory Core
B Optional Core
C Cross-sector Components
D Sector-specific Components
Figure 2 — A visual example of Extension Components being promoted to the Core Invoice Model
A key point to remember is that because these Extensions Specifications are created by business sectors
or industry sectors, they are part of sectoral agreements rather than bilateral agreements, which provides
enhanced interoperability. Promoting an Extension Component or demoting Core Invoice Model
Information Elements could mean significant resources being employed by Software Developers
involved. It is, therefore, essential to include the relevant sectors in this process.
5.5 Importance for Stakeholders
The integration of Extension Components within the Extension Methodology, along with the publication
of a comprehensive library containing these components, holds significant implications for a wide range
of stakeholders. This development is especially impactful in shaping how business processes are
conducted across Europe, which needs to be addressed in cooperation with various stakeholder groups.
Businesses across different Sectors: Companies in sectors like retail, automotive, chemical, and
agriculture will benefit from a more unified invoicing approach, especially for transactions that span
different sectors or are intra-EU. Extension Components are created to meet the unique needs of specific
sectors while ensuring they remain compatible and reusable across different sectors. This enhances
interoperability, addressing past challenges where specifications were less adaptable for cross-sector
use.
Software Developers: This development offers a significant opportunity for ERP and accounting
software developers. The creation of reusable components ensures that these can be integrated into
software with confidence, encouraging the industry to invest in embedding these requirements. By
adapting their systems to support these Extension Components, developers can enable their software to
seamlessly create, process, and interpret the additional information. This ensures interoperability across
sectors and intra-EU, enhancing the versatility and reliability of the software.
Policymakers: The key challenge is striking a balance between the flexibility provided by Extension
Components and the need for standardization and compliance. Policies can be developed to guide the
implementation and use of these components effectively. For instance, the use of the Registry of CIUS and
Extensions for Extension Specifications could be mandated to ensure that extensions are developed in an
open and transparent manner. This would enable others to learn from and build upon existing
implementations, supporting broader interoperability, including intra-EU and cross-sector scenarios.
6 Extension Specifications
6.1 General
An Extension Specification is a set of additional Information Elements or business rules that is used to
create an Extended Invoice Instance Document. This document cannot be correctly processed by the
receiver using only the rules of the Core Invoice Model Therefore, it requires an agreement between the
sender and receiver, ideally at a sector-level rather than bilateral, in which the sector agrees to use the
specific Extension Specification.
6.2 The purpose of Extension Specifications
An Extension Specification is developed with the objective of supporting one or more stated business
requirements that are not supported or not sufficiently supported in the Core Invoice Model. These
business requirements may be due to specific needs in a trading relationship, special sectoral
requirements, specific legal requirements or any combination thereof. If however an Extension
Specification is written to cover requirements that are unique to a country (or more generically unique
to a jurisdicti
...