FprCEN/TS 16931-13

SLOVENSKI STANDARD
01-februar-2026
Elektronsko izdajanje računov - 13. del: Funkcionalna specifikacija in navodila za
register e-računov CIUS in razširitve
Electronic invoicing - Part 13: Functional specification and guidance for the eInvoice
Registry of CIUS and Extensions
Elektronische Rechnungsstellung - Teil 13: Funktionsspezifikation und Leitlinien für das
Register der Anwendungsspezifikation der Kernrechnung und Erweiterungen
Facturation électronique - Partie 13: Spécification fonctionnelle et recommandations pour
le registre des factures électroniques des CIUS et extensions
Ta slovenski standard je istoveten z: FprCEN/TS 16931-13
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.

FINAL DRAFT
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
December 2025
ICS 35.240.63; 35.240.20
English Version
Electronic invoicing - Part 13: Functional specification and
guidance for the eInvoice Registry of CIUS and Extensions
Facturation électronique - Partie 13: Spécification Elektronische Rechnungsstellung - Teil 13:
fonctionnelle et recommandations pour le registre des Funktionsspezifikation und Leitlinien für das Register
factures électroniques des CIUS et extensions der Anwendungsspezifikation der Kernrechnung und
Erweiterungen
This draft Technical Specification is submitted to CEN members for Vote. 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.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a Technical Specification. It is distributed for review and comments. It is subject to change
without notice and shall not be referred to as a Technical Specification.

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

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Registry Services . 10
4.1 Overview . 10
4.2 Purpose of the Registry. 10
4.3 Registerable Artefacts . 11
5 Governance Model . 11
5.1 Overview . 11
5.2 Governance Objectives. 11
5.3 Roles and responsibilities . 12
5.4 Submission and Verification Process . 13
5.5 Operational Dependencies and Ecosystem Context . 14
6 Functional Requirements . 15
6.1 Overview . 15
6.2 Key Functionalities . 15
6.3 Input Structure . 15
6.4 Key Functionalities per User Group . 16
6.5 Metadata Requirements . 19
6.6 Future Enhancements . 19
7 The User Experience . 20
7.1 Overview . 20
7.2 User Roles . 20
7.3 Registry Submission Statuses . 46
8 Implementation Roadmap and Ecosystem Engagement . 47
8.1 Overview . 47
8.2 Deployment Phases . 47
8.3 Ecosystem Alignment and Governance Readiness . 48
Annex A (informative)  Extract from EMSFeI recommendations on the use of Core Invoice Usage
Specifications (CIUS) . 49
Bibliography . 50

European foreword
This document (FprCEN/TS 16931-13:2025) has been prepared by Technical Committee CEN/TC 434
“Electronic invoicing”, the secretariat of which is held by NEN.
This document is currently submitted to the Vote on TS.
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, 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/TS 16931-5, 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/TR 16931-10:2025, Electronic invoicing – Part 10: Additional requirements to extend to B2B
Introduction
The European Commission has estimated that the widespread adoption of electronic invoicing
(eInvoicing) within the European Union could yield significant economic benefits.
Between 2010 and 2020, the European Multi-Stakeholder Forum on eInvoicing (EMSFEI) brought
together representatives from national eInvoicing fora and the user community to promote broader
adoption of eInvoicing across the EU. Its deliverables influenced the development of the European
eInvoicing Standard and the accompanying document parts.
The first legal mandate was Directive 2014/55/EU on electronic invoicing in public procurement. Its aim
is to facilitate the uptake of eInvoicing by economic operators when supplying goods, services and works
to public administrations. This Directive provided the legal foundation for the development of a European
Standard on eInvoicing, resulting in the publication of the EN 16931 set of standards. As stipulated in
Article 7 of Directive 2014/55/EU, all contracting authorities and contracting entities in the EU were
required, from April 2020, to be able to receive and process electronic invoices that conform to this
standard and are expressed in one of the syntaxes identified in CEN/TS 16931-2.
EN 16931-1 establishes a structured and standardized dataset — the Core Invoice Model — that enables
interoperability across sectors, Member States and systems. The Core Invoice Model facilitates
automated processing of invoices and contributes to the removal of market barriers caused by divergent
national or sectoral practices.
In order to address specific business, regulatory or sectoral needs, EN 16931-1 also defines mechanisms
for both restriction and extension of the Core Invoice Model. A Core Invoice Usage Specification (CIUS)
allows organizations, sectors or Member States to apply additional constraints to the Core Invoice Model,
either to simplify or tailor it for particular use cases. Depending on the level of conformance with the
normative rules of the Core Invoice Model, a CIUS may be designated as Core Conformant or Partly Core
Conformant.
Where structured information outside the scope of the Core Invoice Model is required, Extension
Specifications may be developed, following the principles and methodology set out in CEN/TS 16931-5,
which provides guidance on the use of sector or country extensions in conjunction with EN 16931-1.
Following the adoption of the EN, CEN/TC 434 has continued to produce supporting deliverables to
facilitate its implementation and practical use. In 2017, a Study Group under CEN/TC 434 assessed the
potential for a central registry to improve the discoverability, transparency and reuse of CIUS and
Extension Specifications. The Study Group concluded that a formal Registry would enhance semantic
interoperability by offering a structured environment where these Specifications could be registered,
maintained, and accessed consistently by all stakeholders.
As a result, CEN/TC 434 established a dedicated Working Group (WG7) tasked with developing a
Technical Specification for Registry Services. The Registry, as defined in this document, aims to support
the discovery and alignment of eInvoicing Specifications across sectors and Member States. It also
provides for the inclusion of supporting artefacts such as metadata and validation assets, promoting a
harmonized and efficient approach to eInvoicing throughout the internal market.
In 2024, WG5 drafted a document to analyse requirements for B2B requirements, leading to the
published document CEN/TR 16931-10:2025, Electronic invoicing – Additional requirements to extend to
B2B. This document established the need for Extension Components that helped ensure that Extensions
can be cross-sectoral and used intra-EU. It also re-established the need for a Registry of CIUS and
Extensions that can catalogue the usage of CIUS and Extensions, reducing any unnecessary proliferation.
1 Scope
This document defines the purpose, governance and functional requirements of the eInvoicing Registry
for CIUS and Extension Specifications. This document is not to be confused with other business / project
focused Technical Specifications. It follows CEN rules and will be published as a CEN document with
normative statements.
A key part of this document is to provide a functional specification, which will describe the various
functions of eInvoice Registry Services.
The Registry is intended to serve as a structured, transparent and publicly accessible repository that
facilitates the discovery, registration and management of eInvoicing Specifications that either restrict the
conditional elements of the Core Invoice Model and/or extend it in conformance with Part 5 Extension
Methodology.
The scope of this document includes:
— Definition of Registry Services – the structure and capabilities of the Registry including the types of
artefacts it stores or references, e.g. CIUS, Extension Specifications, Validation Artefacts and Services,
and Code Lists;
— Governance Model – the roles and responsibilities of entities involved in managing and maintaining
the Registry;
— Submission and Verification Processes – how Specifications are submitted, reviewed and verified for
inclusion in the Registry;
— Functional Specification – the required functionality, processes and procedures that enable the
Registry to operate efficiently.
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-5, 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
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, sent and received in a structured electronic format which allows for its
automatic and electronic processing
[SOURCE: Directive 2014/55/EU [2]
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:2017+A1:2019,
Clause 6 is a table of information elements contained in the Core Invoice Model.
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:2017+A1:2019,
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
Specification
documented set of rules, guidelines, and requirements that define the usage and implementation of
structured information elements in relation to the Core Invoice Model, either by restricting, clarifying, or
extending its application to meet specific business or sectoral needs
Note 1 to entry: A Specification can either be a CIUS or an Extension Specification.
3.12
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 structured information elements present in the
Core Invoice Model in a specific trading situation
3.13
Core invoice instance document
instance of an electronic invoice that is conformant with the Core Invoice Model
3.14
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 submitted to the eInvoice Registry. 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.15
Extended invoice instance document
instance of an electronic invoice that is valid with an Extension Specification
3.16
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.17
identification scheme
collection of identifiers applicable for a given type of object governed under a common set of rules
3.18
Mandatory Syntaxes
list of syntaxes identified in CEN/TS 16931-2 that comply with EN 16931-1
3.19
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.20
eInvoice Registry
Registry of CIUS, Extension Components, and Extension Specifications (Restrictions of and Extensions to
the Core Invoice Model)
Note 1 to entry: Currently hosted by EU Commission, see: https://ec.europa.eu/digital-building-
blocks/sites/display/EINVCOMMUNITY/Registry+of+CIUS+%28Core+Invoice+Usage+Specifications%29+and+Ex
tensions
Note 2 to entry: The Registry is open, transparent and free of charge.
3.21
compliant
meets all the legal requirements and follows all the legal rules of any Directive associated with the
standard, particularly the VAT Directive
3.22
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.23
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.24
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.25
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.
3.26
artefact
Registrable Artefact
item (specification, data file, list, and dataset or link to validating services) capable of being identified
according to agreed criteria with the expectation of being registered in the Registry Services
3.27
Governing Entity
entity that creates a Registrable Artefact and becomes responsible for its maintenance and development
on an ongoing basis
3.28
Submitter
entity that submits a Specification and related Registrable Artefacts to the Registry
3.29
Registry Groups
collective term for organizational entities that manage, evaluate, and govern the Registry Services
Note 1 to entry: This includes the Registration Authority (RA), the Registration Management Group (RMG), and one
or more Standards Evaluation Groups (SEGs).
Note 2 to entry: Registry Groups are responsible for strategic direction, operational review, and the technical
verification of submitted specifications.
3.30
Registration Authority
RA
organization nominated or created to provide governance and management services for the
establishment, implementation and ongoing operation of the Registry Services
Note 1 to entry: The RA will be governed by a Registration Management Group (RMG).
3.31
Registration Management Group
RGM
management and advisory group for the Registry Services
3.32
Registry Operator
organization created or nominated and contracted to provide technical services to the Registration
Authority for the development, implementation, maintenance and day-to-day operation of the Registry
Services
3.33
Registry Services
services for the provision of a publicly available Registry and for the collection, review, and publication
of information about Registrable Artefacts created by stakeholders to support the implementation of
EN 16931-1 in accordance with its stated requirements
3.34
Registry User
user of the Registry Services having access and download rights, including contracting entities and
authorities, other public bodies, enterprises, suppliers, service and solution providers, trade associations
and academia, as well as the Submitters and Governing Entities themselves
3.35
Standards Evaluation Group(s)
SEG(s)
group of domain experts appointed to evaluate submission of Registrable Artefacts, nominated by and
reporting to the Registration Management Group within the Registration Authority
4 Registry Services
4.1 Overview
This clause describes the Registry Services, detailing the artefacts managed by the Registry and their role
in supporting the visibility, discovery, and consistency of eInvoicing Specifications.
4.2 Purpose of the Registry
The Registry provides a structured, centralized platform that supports the discovery and visibility of
Specifications extending or profiling EN 16931. It allows Stakeholders to locate, evaluate, and reuse
sector-specific and country-specific requirements that have been formalized into CIUS or Extensions. It
is intended to complement – not replace – national, sectoral, or legally mandated publication
mechanisms.
The Registry enables transparency and consistency across sectors and Member States by supporting
structured, semantically aligned submissions. Whilst the Registry is a powerful tool for discovery and
alignment, it does not act as a legal or authoritative source for any individual Specification. A disclaimer
shall be included on the Registry clarifying that users must refer to the Submitter’s original Specification
(typically linked via the ‘Specification Source Link’) as the definitive version. Implementations shall not
rely solely on the Registry as a legal or normative reference point.
One of the overarching goals of EN 16931 is to promote interoperability across business and public sector
communities by aligning on a shared semantic model. Whilst the Core Invoice Model offers mandatory
elements and a high degree of flexibility via CIUS and Extension mechanisms, this same flexibility can lead
to fragmentation – where multiple, functionally similar but technically distinct Specifications emerge. The
Registry aims to reduce this risk by increasing awareness of existing Specifications and promoting reuse.
Where a sector or organization identifies an existing Specification that meets all or part of their needs,
they may choose to adopt or adapt it, rather than create a new one from scratch. This reuse supports
convergence, promotes semantic alignment, and ultimately increases interoperability within and across
sectors and Member States.
As stated in Part 5 of EN 16931: “It is anticipated that all Extension Specifications will be declared in the
Registry of CIUS and Extensions. CEN/TC 434 is tasked with providing an updated version that includes
storing the information elements being used. This will facilitate searching and analysing how the
European Standard on eInvoicing is being used. The Registry, being a searchable database of CIUS and
Extension Specifications, will also allow these users to view how other organizations are using Extension
Specifications and Extension Components to meet their particular invoicing requirements. This level of
transparency can promote interoperability by allowing organizations to emulate some or all of another
sector or nation’s Extension Specification, aligning more users to fewer Extension Specifications.”
This can also be corroborated by the EMSFEI document referenced in Annex A.
NOTE User-specific interaction with these artefacts is described in Clause 7.
4.3 Registerable Artefacts
Registry submissions consist of a variety of artefacts that support conformance, validation, and
interoperability. These include:
— CIUS (Core Invoice Usage Specifications) – Defines additional business rules and constraints on the
Core Invoice Model;
— Extension Specifications – Defines additional structured elements that extend the Core Invoice Model,
following the methodology in CEN/TS 16931-5;
— Supporting artefacts:
— Validation Artefacts – include rules, schemas, and test cases that help validate conformance with
submitted Specifications (typically linked via Git repositories);
— Code Lists – contain standardized lists used in eInvoices for elements such as tax categories,
currencies, and unit codes;
— Other supporting artefacts – may include links to validation services or additional reference
material.
By using a governed and structured approach, the Registry reduces the risk of duplicative or inconsistent
Specifications. This promotes interoperability, facilitates reuse and simplifies adoption across Industry
sectors and Member States – supporting both domestic and cross-border transactions.
Detailed submission workflows and artefact input guidance are provided in Clauses 6 and 7.
5 Governance Model
5.1 Overview
The eInvoicing Registry operates under a structured governance framework to ensure transparency,
conformance and long-term sustainability. This governance model outlines the roles, responsibilities and
procedures for managing and maintaining the Registry process, whilst ensuring that all CIUS and
Extension Specifications are properly submitted, verified and can be updated over time.
5.2 Governance Objectives
Recognizing that resource availability may fluctuate, two potential approaches should be considered:
— a well-resourced (active) approach;
— a low-resource (passive) approach.
In a low resource approach, governance relies entirely on voluntary contributions. WG7 would establish
a system to collect and log feedback from the eInvoicing community, particularly regarding Extension
Specifications and the use of Extension Components within them. Stakeholders, especially those who
submit Extension Specifications, would be notified of any issues identified. WG7 could periodically hold
discussions to review and address these matters as resources permit.
It would solely be the responsibility of Submitters to ensure that their Specifications are Core Conformant
or Partly Core Conformant as described in EN 16931-1 and CEN/TS 16931-5 and compliant with the
appropriate regulations.
This approach is not ideal and not conducive to ensuring proper reuse and interoperability.
On the other hand, a well-resourced (active) approach ensures that:
— the Registry operates in a transparent and open manner;
— roles and responsibilities for management are clearly defined;
— specifications undergo a structured review / verification process;
— a maintenance feature is in place so that Specifications can be up to date within the Registry;
— supports are in place for Submitters and end-users to be able to effectively use the Registry;
— Specifications are checked for conformance with relevant normative statements;
— Specifications are checked for compliance with appropriate Directives, such as the VAT Directive.
Submitters shall be responsible for keeping their Registry entries up to date and for ensuring that each
Specification remains Core Conformant or Partly Core Conformant with EN 16931-1 and adheres to the
guidance in CEN/TS 16931-5.
Submitters of a Country Extension should also ensure that it remains compliant with domestic law.
Sustaining governance for the Registry Services requires ongoing resources. Initially, resource demands
will be high, and Work Group 7 (WG7) can support this phase by organizing volunteers. However, when
adequate resources are secured, a more proactive governance structure could be implemented. Further
details on this approach are outlined below.
5.3 Roles and responsibilities
5.3.1 General
The Registry is supported by a structured governance model involving clearly defined user roles. This
clause outlines the governance and oversight responsibilities for each role. Practical interactions with the
Registry system and associated workflows for these roles are further detailed in Clause 6.
The primary roles are as follows:
— Submitters: Provide structured Specifications and associated metadata for review
— Registry Groups (RA, RMG, SEG): Review and manage the integrity of Registry content
— End Users: Access and apply Registry content but do not participate in submission or review
processes
See Table 1.
Table 1 — Overview of Governance Roles
Role Description Key Responsibilities
RA Registration Authority Governance policies, strategic direction
RMG Registry Management Group Day-to-day governance, SEG setup
SEG Standards Evaluation Group – a Technical evaluation, review process
Registry Group specializing in a
specific Industry Sector and/or a
Countries’ invoicing regulations
RO Registry Operator Technical hosting, system maintenance
Submitters Governing Entities who submit Responsible to maintain and updated their
specifications on behalf of an submitted specification
Industry sector or Country.
NOTE Operational interactions by each role are detailed in Clause 6.
5.3.2 Registration Authority (RA)
— The primary governing body overseeing the Registry
— Should include representatives from CEN/TC 434, the European Commission, and other Stakeholders
— Should establish policies, validation criteria, and strategic direction for the Registry
5.3.3 Registry Management Group (RMG)
— A subgroup under the RA responsible for overseeing day-to-day governance matters
— Should review governance policies and make recommendations for improvements
— Establish Standards Evaluation Group (SEG)
5.3.4 Standards Evaluation Group (SEG)
— Subject matter experts formed from CEN/TC 434 members, appropriate business sectors, Submitters
and other stakeholders
— Should conduct detailed technical and conformance evaluations of CIUS and Extension Specifications
— Should ensure Specifications conform to EN 16931 and relevant Technical Specifications
— Should provide harmonization recommendations to minimize fragmentation
5.3.5 Registry Operator (RO)
— An organization that provides hosting and technical maintenance services
— Should manage the technical infrastructure of the Registry (database, security, accessibility)
— Should ensure the technical availability of the Registry and its functionalities
5.4 Submission and Verification Process
The Registry follows a two-step review process to ensure that all registered Specifications meet legal
compliance, quality, and interoperability requirements. The main steps involve an initial submission,
followed by evaluation and verification by governance groups.
Figure 1 — Registry Review Process
Figure 1 provides a high-level overview of the Registry process, showing the interactions between
Submitters, and the Standards Evaluation Group (SEG). The Registration Management Group (RMG) has
overall responsibility for the governance of this process.
Each submission progresses through defined status stages as it is reviewed. Descriptions of each Registry
submission status, including user-facing implications, are provided in Clause 7.
This governance model ensures consistency and traceability across all submissions and Registry
decisions. These structured processes underpin the functional requirements outlined in the next clause.
5.5 Operational Dependencies and Ecosystem Context
The Registry Services described in this document are designed to operate within a broader eInvoicing
ecosystem. Their effectiveness relies on supporting structures and community engagement beyond the
scope of standardization alone. This includes consistent development and use of CIUS and Extension
Specifications, widely available validation artefacts, and integration with the tools used by both public
administrations and software vendors.
Whilst the Registry will be hosted and maintained by the European Commission formal operational
commitments are pending. However, the Commission has demonstrated active support by financing
editorial development and being kept regularly informed of progress.
The Registry is envisioned as a service-oriented resource that will eventually expose APIs and
programmatic access to facilitate system integration. Although the prototype may not initially include
APIs, their development is a high priority to support toolmaker adoption.
Validation artefacts for Core Invoice Model and Extension Components will be provided by CEN/TC 434,
WG3. However, Registry Submitters remain responsible for ensuring that their CIUS or Extension
Specification includes customized artefacts if specific deviations or additions are made. This layered
responsibility ensures consistency whilst allowing flexibility and innovation at the edge.
This governance model aligns with EMSFEI’s recommendations on specification quality and validation as
outlined in Clause 4 of the 2018 EMSFEI document, Recommendation on the use of Core Invoice Usage
Specifications (CIUS).
6 Functional Requirements
6.1 Overview
The eInvoicing Registry provides structured services to store, manage, and retrieve CIUS and Extension
Specifications whilst ensuring conformance with EN 16931. This clause defines the core functional
requirements, processes, and procedures that govern the Registry’s operation.
6.2 Key Functionalities
The Registry provides the following key functionalities in Table 2:
Table 2 — Registry key functionalities
Register Specifications
Accept CIUS and Extension Specifications, enabling submission,

review, and promotion.
Store and Search Metadata
Capture Submitter details, version info, conformance level, and artefact

references to support discovery
Verify and Validate
Conduct structured reviews to ensure Specifications meet Registry and
EN 16931 requirements
Support Governance
Facilitate management of Specification lifecycle by Registry Groups.

6.3 Input Structure
This subclause builds on the governance roles introduced in Clause 5 by describing how different user
types interact with Registry content and structure. It introduces how Specifications are composed and
how user roles contribute to the registration and validation process.
Each Specification is assessed to determine whether it includes elements from the Core Invoice Model,
Extension Components, or other information elements:
— Identifying Information
— Core Invoice Model elements (BTs and BGs)
— Extension Components (XTs and XGs)
— If included, additional information elements (free-form entries)
— Supporting Artefacts (e.g. validation artefacts and Code Lists)
6.4 Key Functionalities per User Group
6.4.1 General
This subclause describes how the Registry’s capabilities support different groups of users, which include
Registry Groups, Submitters and end users:
a) Submitters – Sector or Country Representatives (e.g. Member States, Standardization Bodies) who
register new eInvoicing Specifications and associated artefacts.
b) Standards Evaluation Group (SEG) – subject matter experts and other stakeholders helping to verify
the submissions.
c) End users – Stakeholders who rely on submitted Specifications (e.g. businesses, public
administrations, service providers).
See Table 3.
Table 3 — Summary of User capabilities
User Submit Edit Drafts Review Change Status
Specifications Specifications
Submitter Yes Yes No No
SEG No No Yes Yes
End User No No Yes No
6.4.2 Key Functionalities for administration
Although roles like the RMG and SEGs have different responsibilities, such as assigning reviewers and
managing submission lifecycles, the system will not enforce strict access layers during the prototype
phase. A representative from the RMG will coordinate user access and guide feature development,
including assigning SEGs to specific submissions. A more layered management structure will be
introduced gradually to avoid unnecessary complexity and to keep the focus on core functions like
submitting and reviewing specifications.
a) User & Access Administration
1) Grant and revoke permissions for different roles:
i. SEGs will be assigned specific Submissions.
ii. Submitters will be approved or revoked.
iii. Technical operators will be given permission based on their needs for the specific purpose
they are given.
b) Strategic Development & Features Maintenance
1) Plan and prioritize feature enhancements (e.g. integration with automated validation or
analytics).
2) Monitor overall system health, handle resource allocation, and conduct periodic reviews for
continuous improvement.
The Standards Evaluation Group (SEG) will undertake the following functions:
c) Submission Evaluation & Verification
1) Review newly submitted CIUS and Extension Specifications. Check that business requirements
justify the changes and that they are necessary.
2) Verify conformance to normative statements and completeness to ensure all relevant
information is included in the submission.
d) Workflow & Issue Management
1) Manage the end-to-end process—moving submissions from “Submitted” to “Under Review,”
then to “Verified.”
2) Track comments, and final approval decisions.
3) Escalate policy questions or disputes to the RMG for resolution.
6.4.3 Key Functionalities for Submitters
“Submitters” are entities such as Member States, Sector Organizations, or National Standardization
Bodies who wish to register and maintain Specifications and their associated validation artefacts.
a) Specification Registration
1) Provide structured metadata (e.g. Specification name, version, s
...