FprEN 16931-1
(Main)Electronic invoicing - Part 1: Semantic data model of the core elements of an electronic invoice
Electronic invoicing - Part 1: Semantic data model of the core elements of an electronic invoice
This European Standard establishes a semantic data model of the core elements of an electronic invoice. The semantic model includes only the essential information elements that an electronic invoice needs to ensure legal (including fiscal) compliance and to enable interoperability for cross-border, cross sector and for domestic trade. The semantic model may be used by organizations in the private and the public sector for public procurement invoicing. It may also be used for invoicing between private sector enterprises. It has not been specifically designed for invoicing consumers.
This European Standard complies at least with the following criteria:
- it is technologically neutral;
- it is compatible with relevant international standards on electronic invoicing;
- the application of this standard should comply with the requirements for the protection of personal data of Directive 95/46/EC, having due regard to the principles of privacy and data protection by-design, data minimization, purpose limitation, necessity and proportionality;
- it is consistent with the relevant provisions of Directive 2006/112/EC [2];
- it allows for the establishment of practical, user-friendly, flexible and cost-efficient electronic invoicing systems;
- it takes into account the special needs of small and medium-sized enterprises as well as of sub-central contracting authorities and contracting entities;
- it is suitable for use in commercial transactions between enterprises.
Elektronische Rechnungsstellung - Teil 1: Semantisches Datenmodell der Kernelemente einer elektronischen Rechnung
Dieses Dokument führt ein semantisches Datenmodell der Kernelemente einer elektronischen Rechnung ein. Das semantische Datenmodell umfasst nur die wesentlichen Informationselemente, die eine elektronische Rechnung enthalten muss, um die rechtliche (einschließlich steuerrechtliche) Richtigkeit sicherzustellen und die Interoperabilität für den grenzüberschreitenden Handel, den branchenübergreifenden Handel und den Binnenhandel zu ermöglichen. Das semantische Datenmodell kann von Organisationen des privaten und öffentlichen Sektors bei der Rechnungsstellung für öffentliche Aufträge angewendet werden. Es kann auch bei der Rechnungsstellung zwischen Unternehmen des Privatsektors angewendet werden. Es ist nicht speziell für die Rechnungsstellung an Konsumenten ausgelegt.
Dieses Dokument Norm erfüllt mindestens die folgenden Kriterien:
es ist technologieneutral;
es ist mit den einschlägigen internationalen Normen für die elektronische Rechnungsstellung vereinbar;
die Anwendung dieser Norm sollte die Anforderungen an den Schutz von personenbezogenen Daten nach Richtlinie 95/46/EG erfüllen, unter Berücksichtigung der Grundsätze für Privatsphäre und Datenschutz durch Technik („data protection by design“), Datenbegrenzung, Zweckbegrenzung, Notwendigkeit und Verhältnismäßigkeit;
sie steht mit den einschlägigen Bestimmungen der Richtlinie 2006/112/EG [2] in Einklang;
sie ermöglicht die Einrichtung zweckmäßiger, benutzerfreundlicher, flexibler und kosteneffizienter Systeme zur elektronischen Rechnungsstellung;
sie berücksichtigt die speziellen Bedürfnisse von kleinen und mittleren Unternehmen sowie von subzentralen öffentlichen Auftraggebern und anderen Auftraggebern;
sie eignet sich für die Verwendung bei kaufmännischen Transaktionen zwischen Unternehmen.
Facturation électronique - Partie 1 : Modèle sémantique de données des éléments essentiels d'une facture électronique
Elektronsko izdajanje računov - 1. del: Semantični podatkovni model osrednjih elementov za elektronski račun
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
01-oktober-2025
Elektronsko izdajanje računov - 1. del: Semantični podatkovni model osrednjih
elementov za elektronski račun
Electronic invoicing - Part 1: Semantic data model of the core elements of an electronic
invoice
Elektronische Rechnungsstellung - Teil 1: Semantisches Datenmodell der Kernelemente
einer elektronischen Rechnung
Facturation électronique - Partie 1 : Modèle sémantique de données des éléments
essentiels d'une facture électronique
Ta slovenski standard je istoveten z: prEN 16931-1
ICS:
03.100.20 Trgovina. Komercialna Trade. Commercial function.
dejavnost. Trženje Marketing
35.240.20 Uporabniške rešitve IT pri IT applications in office work
pisarniškem delu
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.
DRAFT
EUROPEAN STANDARD
prEN 16931-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
July 2025
ICS 35.240.20; 35.240.63 Will supersede EN 16931-1:2017+A1:2019
English Version
Electronic invoicing - Part 1: Semantic data model of the
core elements of an electronic invoice
Facturation électronique - Partie 1 : Modèle Elektronische Rechnungsstellung - Teil 1:
sémantique de données des éléments essentiels d'une Semantisches Datenmodell der Kernelemente einer
facture électronique elektronischen Rechnung
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 434.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.
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 European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.
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. prEN 16931-1:2025 E
worldwide for CEN national Members.
prEN 16931-1:2025 (E)
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 6
4 The concept of a core invoice . 8
4.1 The Core Invoice Model as a response to the challenge of interoperability . 8
4.2 Contents of the Core Invoice Model . 9
4.3 How to use and extend the Core Invoice Model .10
4.4 Conformance .11
5 Business processes and functionality supported by the core invoice .12
5.1 The business parties involved and their roles and relationships .12
5.2 Business process requirements supported .13
5.3 Invoicing functionality supported .22
5.4 The Core Invoice Model in relation to other documents in the procurement process
.................................................................................................................................................................29
6 The Semantic data model of the Core Elements of an Electronic Invoice and credit
note .30
6.1 Introduction .30
6.2 Legend .32
6.3 The Semantic Data Model .34
6.4 Business rules . 102
6.5 Semantic data types . 128
7 Core Invoice Usage Specification . 135
7.1 Introduction . 135
7.2 Conformance . 136
7.3 What may be specified in a CIUS . 136
7.4 Documentation of Core Invoice Usage Specifications . 138
7.5 Mapping to Syntax . 139
7.6 Identification of Core Invoice Usage Specifications . 139
Annex A (Informative) Technical changes with respect to EN 16931-1:2017 . 140
Annex B (informative) How the Semantic Data Model meets legal requirements from
relevant directives . 182
Annex C. (informative) BPMN symbols. 187
Bibliography. 189
prEN 16931-1:2025 (E)
European foreword
This document (prEN 16931-1: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 CEN Enquiry.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
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 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-2Electronic 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 Cross
Industry Invoice D16B
— CEN/TS 16931-3-4 Electronic invoicing - Part 3-4: Syntax binding for UN/EDIFACT INVOIC D16B
— CEN/TR 16931-4 Electronic invoicing - Part 4: Guidelines on interoperability of Electronic Invoices
at the transmission level
— prCEN/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 Electronic invoicing - Part 6: Result of the test of EN 16931-1 with respect to its
practical application for an end user - Testing methodology
— CEN/TS 16931-7 Electronic invoicing - Part 7: Methodology for the development and use of EN
16931-1 compliant structured Core Invoice Usage Specifications
— CEN/TS 16931-8: Electronic invoicing - Part 8: Semantic data model of the elements of an e-receipt
or a simplified electronic invoice
— CEN/TR 16931-9 Electronic invoicing - Part 9: VAT reporting and gap analysis with current e-
invoicing standardization deliverables
— FprCEN/TR 16931-10 Electronic invoicing – Part 10: Additional requirements to extend to B2B
prEN 16931-1:2025 (E)
Introduction
The European Commission estimates that “The mass adoption of e-invoicing 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” . Based on this recognition “The
Commission wanted to see e-invoicing become the predominant method of invoicing by 2020 in
Europe.”
To achieve this goal, Directive 2014/55/EU [1] on electronic invoicing in public procurement aims at
facilitating the use of Electronic Invoices by economic operators when supplying goods, works and
services to the public administration. The Directive sets out the legal framework for the establishment
and use of a European Standard (EN) for the Semantic data model of the Core Elements of an Electronic
Invoice.
The Semantic data model of the Core Elements of an Electronic Invoice – the Core Invoice Model – as
described in this document is based on the proposition that a quite limited, but sufficient set of
Information Elements can be defined that supports generally applicable invoice-related functionalities.
These functionalities are described in Clause 5. The Core Invoice Model, as described in Clause 6,
contains Information Elements that are commonly used and accepted including those that are legally
required.
It is expected that in most situations, business partners would use the Core Invoice Model exclusively
and the invoices they send or receive would not contain any additional structured Information Elements.
However, in some sectors or situations where there are specific information requirements, the required
information may be conveyed in the form of unstructured text. Unstructured text has the drawback in
that it cannot be processed automatically and therefore requires human intervention. Alternatively, the
specific information requirements can be implemented using Information Elements that extend the Core
Invoice Model. Any such extension needs to respect the semantic descriptions in the Core Invoice Model.
Only business partners that are part of such a sector or supply chain would be expected to be able to
process the extensions. In these circumstances, it should be possible to define a number of required
additional Information Elements whilst still utilizing the Core Invoice Model concept.
In line with Directive 2014/55/EU [1] and after the publication of the reference to this document in the
Official Journal of the European Union, all contracting authorities and contracting entities in the EU will
be obliged to be able to receive and process an Electronic Invoice as long as it contains all of the
(applicable) Core Elements of an invoice defined in this European Standard (and provided that it is
represented in any of the syntaxes identified in the related Technical Specification CEN/TS 16931-2
“List of syntaxes that comply with EN 16931-1” in accordance with the request referred to in paragraph
1 of article 3 of the Directive 2014/55/EU. The inclusion of any additional information which is not
contained in the core model will be at the sender’s discretion and contained in unstructured text or
based on an extension, by agreement with the contracting entity. The inclusion of any extension in an
Electronic Invoice will be optional, and it will not form an integral part of the European Standard. See
Clause 4 below for further detail on extensions.
In 2025, the EC also proposes to amend Council Directive. 2006/112/EC [2] (the VAT directive) in order
to introduce a new method of VAT reporting for intra community trade. This method is based on
electronic invoicing, conformant to this European Norm.
By ensuring semantic interoperability of Electronic Invoices, the European Standard and its ancillary
European standardization deliverables will serve to remove market barriers and obstacles to trade
deriving from the existence of various national rules and standards – and thus contribute to the goals
set by the European Commission.
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0712:FIN:en:PDF.
prEN 16931-1:2025 (E)
1 Scope
This document establishes a semantic data model of the core elements of an Electronic Invoice. The
semantic data model includes only the essential information elements that an Electronic Invoice needs
to ensure legal (including fiscal) compliance and to enable interoperability for cross-border, cross sector
and domestic trade. The semantic data model can be used by organizations in the private and the public
sector for public procurement invoicing. It can also be used for invoicing between private sector
enterprises. It has not been specifically designed for invoicing consumers.
This document complies at least with the following criteria:
— it is technologically neutral;
— it is compatible with relevant international standards on electronic invoicing;
— the application of this standard should comply with the requirements for the protection of personal
data of Directive 95/46/EC, having due regard to the principles of privacy and data protection by-
design, data minimization, purpose limitation, necessity and proportionality;
— it is consistent with the relevant provisions of Directive 2006/112/EC [2];
— it allows for the establishment of practical, user-friendly, flexible and cost-efficient electronic
invoicing systems;
— it takes into account the special needs of small and medium-sized enterprises as well as of sub-
central contracting authorities and contracting entities;
— it is suitable for use in commercial transactions between enterprises.
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.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
codes (ISO 3166-1)
ISO 4217, Codes for the representation of currencies
ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates
and times
ISO 15000-5, Electronic Business Extensible Markup Language (ebXML) — Part 5: Core Components
Specification (CCS)
ISO/IEC 6523 (all parts), Information technology — Structure for the identification of organizations and
organization parts
prEN 16931-1:2025 (E)
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/
NOTE Business Terms that are part of the Semantic Data Model are defined in the model itself.
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: This document identifies these elements using Business Terms (BTs). In EN 16931-1 section 6.3
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 Terms Group
group of related Business Terms
Note 1 to entry: BTs can be aggregated within Business Terms 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 shall contain along with conditional elements that can be used when required.
prEN 16931-1:2025 (E)
3.8
Core Elements of an Electronic Invoice
set of information elements that most Electronic Invoices contain in order to enable interoperability,
including the necessary information to ensure legal compliance
3.9
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.10
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.11
Core Invoice Instance Document
instance of an Electronic Invoice that is conformant with the Core Invoice Model
3.12
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 eInvoice Registry. It is typically
written by a Representative/Representatives of a Sectoral Organisation 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.13
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.14
Identification Scheme
collection of Identifiers applicable for a given type of object governed under a common set of rules
3.15
Compliant
meets all the legal requirements and follows all the legal rules of any Directive associated with the
standard, particularly the VAT Directive
prEN 16931-1:2025 (E)
3.16
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 CEN/TC434/WG3
validation artefacts for the Core Invoice Model.
3.17
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 syntaxes that comply with EN 16931-1 and that are
mandatory for public bodies in the European Union.
4 The concept of a core invoice
4.1 The Core Invoice Model as a response to the challenge of interoperability
The establishment of interoperability of business information systems with respect to the exchange of
electronic documents such as invoices is viewed by many as a major challenge for the following reasons:
a) the overall business environment is diverse and consequently so is the information that needs to be
exchanged between business partners;
b) invoices consist of many Information Elements; attempting to define and standardize all occurring
Information Elements would generate a very large and complex information model that no single
organization could implement entirely;
c) even if a complete implementation of such a large model were possible, its implementation across
the business environment would be very challenging and costly;
d) as experience shows, business partners in various industry sectors will agree on subsets of the
model that are supported by their business information systems. Such variety would work against
the principles of using common standards, jeopardize interoperability and result in expensive
implementation projects.
This document is based on a different approach. In contrast to collecting and meeting the requirements
of all businesses, a Semantic Data Model is defined that includes only the essential Information Elements
that an Electronic Invoice needs to ensure legal (including fiscal) compliance and to enable
interoperability for cross-border, cross-sector and domestic trade. The Semantic Data Model may be
used by organizations in both the public and private sectors for electronic invoicing, supporting
transactions in public procurement as well as between private enterprises.
The result of this approach is a Semantic Data Model of core Information Elements for an Electronic
Invoice. The following guiding principles form the basis of the Core Invoice Model:
1) it should be easier to prepare and send, as well as to receive and process Electronic Invoices when
compared to paper invoices;
2) the use of standardized Information Elements should make Electronic Invoice processing more
efficient than processing paper invoices;
prEN 16931-1:2025 (E)
3) conformance with the Core Invoice Model should mean that business partners are able to interpret
and understand the content of an Electronic Invoice at the semantic level without prior consultation
or bilateral agreements;
4) invoices should be composed of structured Information Elements to enable efficient and automatic
processing;
5) invoice processing software should be able to present all Information Elements in the Core Invoice
Model, and automatically process all structured data;
6) the use of structured data should result in optimized business processes;
7) the Core Invoice Model makes no assumption about the method by which an invoice is created,
delivered and processed. It may be exchanged directly between business partners or exchanged
using an intermediary service provider;
8) the Core Invoice Model makes no assumption about the syntax or transmission technology used.
Senders and receivers of Electronic Invoices shall ensure the authenticity and integrity of the
invoice according to relevant regulations. Mapping to several syntaxes is provided in
CEN/TS 16931-3 from subpart 2 onward.
4.2 Contents of the Core Invoice Model
The Core Invoice Model is based on the proposition that a quite limited, but nevertheless sufficient set
of Information Elements can be defined which supports generally applicable invoice-related
functionalities. These functionalities include invoice issuance and delivery, invoice validation,
accounting, VAT reporting, payment and auditing. The Core Invoice Model contains Information
Elements that are commonly used and accepted, including those that are legally required across Europe.
If all organisations in Europe were to implement the Core Invoice Model in their business information
systems using the specified Information Elements, it would be possible to send, receive, and process
Electronic Invoices without human intervention. There would be no need for onerous pre-negotiated
bilateral agreements between organizations on the actual semantic content of the invoice and its
exchange. The only assumption is the existence of a normal business contract or trading agreement. The
Core Invoice Model supports a set of invoice functions, as specified in Clause 5 below.
The set of Information Elements that are contained in the Core Invoice Model is commonly considered
to consist of two parts: a legal part and a common part.
The legal part of the Core Invoice Model supports the observance of both tax and commercial legal and
regulatory requirements pertaining to electronic invoicing commonly in force throughout Europe.
The common part contains commonly used and accepted Information Elements that are not sector or
country specific.
A specific Information Element may be correctly allocated to one or both parts. Therefore, categorizing
elements with respect to these parts in the Semantic Data Model is not considered to be meaningful.
To fulfil the requirements above, judgment has had to be made on the selection of the Information
Elements to be included in the Core Invoice Model. First, for the legal part requirements, the mandatory
elements are those that comply with the EU VAT Directives and most individual state laws, whether local
VAT regulations, or any other local legal provision (regulatory, contractual company law, laws on
business documents, etc.). In some cases, those Information Elements that are exclusively confined to a
single or very small number of countries and therefore fall outside the doctrine of ‘commonly in force
throughout the EU’ have not been included in the Core Invoice Model. Secondly, the elements selected
to satisfy the requirements of the common part form a justifiable selection of requirements required in
commercial practice.
prEN 16931-1:2025 (E)
An important criterion when to include an Information Element in the Core Invoice Model that is above
and beyond one that is legally required is whether it can be assumed that the buyer’s information system
can process (or otherwise handle) such an element. If the business information systems of most buyers
in Europe are incapable of processing such an Information Element, that element should not be part of
the Core Invoice Model. If such an element is nevertheless required in a specific context, it should be
contained within an extension to the Core Invoice Model, specific to either a sector or a country. The
methodology to create extensions is described in CEN/TS 16931-5. When experience shows that an
extension is frequently used, then such an extension could be added as Information Elements to the Core
Invoice Model in a later version rather than continuing to be handled in an extension.
4.3 How to use and extend the Core Invoice Model
As stated in the previous subclause, the Core Invoice Model is intended to be used for all generally
applicable invoicing processes. In many situations, business partners would use the Core Invoice Model
exclusively and the invoices they send or receive would contain only the structured Information
Elements as defined in the model. Where a dedicated field exists for a Business Term or piece of data,
this field shall be used for the information content instead of using a textual field.
There are however circumstances where the trading partners may wish to either: 1. restrict the
conditional Information Elements to be used in an Electronic Invoice or 2. provide additional
Information Elements. The first requirement is satisfied using a Core Invoice Usage Specification (CIUS).
The second requirement is satisfied using an extension specified in an Extension Specification.
In many trading situations, it may be appropriate to restrict the use of conditional Information Elements
present in the Core Invoice Model in some way to support automated processing. The use of a CIUS to
specify these requirements is described in Clause 7 below. The CIUS is a specification that provides a
seller with detailed guidance, explanations and examples, relating to the actual implementation and use
of the Information Elements in the Core Invoice Model in a specific trading situation.
Typically, a CIUS will be created by a contracting entity (buyer) in relation to its own supply chain or by
a group of contracting entities wishing to achieve consistency in the way that the Information Elements
in the Core Invoice Model are to be used by sellers trading with an identified sector or community of
buyers. The requirements set out in such a CIUS will be communicated to sellers or placed on a website
and may be included in the contractual documentation between the parties. Alternatively, a CIUS may
be created by a group of sellers and agreed in turn by their buyer or buyers in the context of a specific
industry or supply chain.
A CIUS is a set of usage guidelines or restrictions made to the Core Invoice Model that will still produce
an invoice instance that is fully conformant with the Core Invoice Model set out in this document. This
means that a receiver of an invoice document instance that has been created in conformance with a CIUS
is still able to receive and process it in accordance with the rules defined for the Core Invoice Model.
In some sectors or situations where there are specific additional information requirements, the required
information may be conveyed in the form of unstructured text. Unstructured text, however, has the
drawback that it cannot be processed automatically and therefore requires human intervention.
Alternatively, the specific information requirements can be implemented using an extension containing
Information Elements that extend the Core Invoice Model (See CEN/TS 16931-5 for the methodology
applicable to the use of extensions). Any such extension should not infringe or contradict the semantic
descriptions in the Core Invoice Model and shall be conformant to CEN/TS 16931-5. Only business
partners that are part of such a sector or supply chain would be expected to be able to process the
extension. In these circumstances, it is possible to carefully define the required additional Information
Elements, whilst still utilizing the Core Invoice Model concept.
Some extensions are not specific to a single supply chain or industry sector but may be specific to
functions or business processes required by more than one sector. For example, the vendor managed
inventory (VMI) process has been implemented by several industries. The VMI business process may
prEN 16931-1:2025 (E)
require additional Information Elements, not present in the Core Invoice Model. Clearly, similar
functions and processes should consistently use the same Information Elements across Europe.
The development of sector-specific or cross-sector extensions shall be based on justified business
requirements. These can only be gathered by industry experts, (private and public) sector organizations
and their customers, who understand those requirements. The Semantic Data Model of these additional
Information Elements will need to be defined and registered as an Extension Specification.
4.4 Conformance
4.4.1 General
Conformance to the Core Invoice Model, can be measured at three levels:
— at the level of specifications;
— the actual implementation by a given sender or receiver; and
— the individual invoice instance documents.
Each of these levels is discussed in 4.4.2 to 4.4.4.
4.4.2 Conformance of the Core Invoice Usage Specifications
The Core Invoice Usage Specifications that are used in conjunction with the Core Invoice Model shall
themselves conform to the methodology and rules described in this guideline and expressed in the
following criteria:
— the specification shall clearly state what business functions and/or legal requirements it is intended
to support;
— the specification shall clearly state its issuer and responsible 'governor';
— the specification shall clearly state in what way the requirements of the CIUS differ from the Core
Invoice Model, either by documenting the difference only or by specifically pointing out what the
differences are;
— the resulting invoice document instance shall be conformant to the Core Invoice Model.
— the specification and, when relevant, its version shall be uniquely identifiable both for referencing
and for identification in processing;
— the specification shall state its underlying specifications (the Core Invoice Model as well as other
specifications that it may build upon);
— the syntax binding of a specification shall follow the syntax binding methodology defined in
CEN/TS 16931-3-1.
4.4.3 Conformance of sending or receiving party
A receiving party may only claim conformance to the Core Invoice Model if they accept invoices that
conform with the Core Invoice Model in general, or with a CIUS, that is itself conformant with the Core
Invoice Model.
A sending party may claim conformance if they send invoices that conform to the Core Invoice Model,
including those issued in accordance with a conformant CIUS.
prEN 16931-1:2025 (E)
4.4.4 Conformance of a Core Invoice Instance Document
A Core Invoice Instance Document is conformant to the Core Invoice Model if it respects all rules defined
for the Core Invoice Model, which may include the specification contained in a conformant CIUS.
If a Core Invoice Instance Document supports requirements that can be considered as a use of a CIUS,
the Core Invoice Instance Document is still conformant to the Core Invoice Model. These Core Invoice
Instance Documents can still be received and processed by a party who is not supporting the CIUS
because it still conforms to the rules of the Core Invoice Model.
5 Business processes and functionality supported by the core invoice
5.1 The business parties involved and their roles and relationships
In the basic purchase-to-pay process there are two business parties, the Customer and the Supplier.
Each party may fulfil two or three roles in the process. The Customer party has the role of the Buyer (the
commercial role that contracts with a Seller and orders the goods and services) and the Receiver (the
operational role that receives the goods and services). The Supplier party has the role of the Seller (the
commercial role that is contracted by a Buyer) and the Payee (the role that receives the payment). Both
parties are considered to be Taxable persons (the role that declares and pays or reclaims VAT), except
for some public entities. The Supplier may delegate the operational aspects of that role to a Tax
representative, who declares and pays VAT on their behalf.
Figure 1 — Parties and roles
In the Core Invoice Model, it is assumed that the Supplier party combines, by default, the roles of Seller
and Payee. Roles may however be outsourced. The role of Payee may be fulfilled by another party, e.g. a
factoring service. The same applies to the roles of the Customer (Buyer and Receiver) that may be
fulfilled by different parties. It is assumed that the Seller issues the invoice. Note that in certain
transactions the Buyer may be liable to pay VAT instead of the Seller.
An invoice consists of a header and one or more line items. All information about the parties is defined
at header level.
Table 1 illustrates the different roles in an invoice:
prEN 16931-1:2025 (E)
Table 1 — Parties and roles
Context Role Explanation
Supplier:
Trade Seller (invoice issuer) Principal role
Additional role, may be a different
Payment Payee party from the Seller (e.g. a
factoring service)
Tax Taxable Person (may engage a Tax representative) Designation for tax purposes
Customer:
Trade Buyer (invoice receiver) Principal role
Additional role, may be a different
party from the Buyer (e.g. a
Delivery Receiver
subsidiary of the Buyer in another
location)
Tax Taxable Person Designation for tax purposes
Other parties may also play roles in the invoicing process, such as (e.g. transport) service providers and
(e.g. tax) authorities. They are however indirectly involved as an agent or counterpart and not included
in the table.
5.2 Business process requirements supported
5.2.1 Introduction
The Core Invoice Model supports a basic purchase-to-pay process. Purchase-to-pay processes can be
complex due to logistics, legal, product and technical requirements. Examples of such complex processes
are: vendor managed inventory, invoicing on behalf of multiple parties in the same invoice, invoicing
complex products or project-related products, or ‘swap’ deals. These processes are out of scope of the
Core Invoice Model. However, the Core Invoice Model can be extended to support such processes. The
extension methodology is described in CEN/TS 16931-5.
This subclause 5.2 describes the processes that are supported by the Core Invoice Model. These
processes include buying, selling, delivering goods and services and payment between Customers and
Suppliers and their respective roles. How the invoice and other documents are electronically exchanged
is not described in the process models. Parties may handle document exchange with their own resources
or outsource (part of) it. See also CEN/TR 16931-4.
The process models focus on the external activities of the parties and do not describe internal activities.
Only the activities of the roles listed in Table 1 are modelled, not those of third parties.
The process model diagrams are presented in the Business Process Model and Notation (BPMN) of the
Object Management Group (OMG) [7]. A short legend of the symbols used can be found in Annex C.
The process models included in 5.2 are intended to indicate the business contexts that are supported by
the Core Invoice Model. The models do not give a full definition of those processes.
The Core Invoice Model shall include elements that allow the trading parties to represent any invoice
transaction according to the EU VAT directives and should support the following types of business
processes:
— P1: Invoicing of deliveries of goods and services against purchase orders, based on a contract;
— P2: Invoicing deliveries of goods and services based on a contract;
prEN 16931-1:2025 (E)
— P3: Invoicing the delivery of an incidental purchase order;
— P4: Pre-payment;
— P5: Spot payment;
— P6: Payment in advance of delivery;
— P7: Invoices with references to a despatch advice;
— P8: Invoices with references to a despatch advice and a receiving advice;
— P9: Credit notes or invoices with negative amounts, issued for a variety of reasons including the
return of empty packaging;
— P10: Corrective invoicing (cancellation/correction of an invoice);
— P11: Partial and final invoicing;
— P12: Self billing.
Other processes are not explicitly supported, but the Core Invoice Model may still be applicable. In more
complex or advanced processes, however, extensions to the information content of the Core Invoice
Model may be needed (see CEN/TR 16931-5).
5.2.2 Invoicing of deliveries against purchase orders, based on a contract (P1)
Figure 2 — Invoicing of deliveries against purchase orders, based on a contract
In this process the Buyer and the Seller conclude a formal contract (or there is an assumed contract by
legal definition) in which the terms and conditions are stated under which goods or services will be
delivered and are paid for. The Buyer orders the goods or services, stating the specifications for goods
prEN 16931-1:2025 (E)
and services, the quantities and the place and time of delivery. The Seller delivers the ordered goods or
services to the Receiver as specified on one or more purchase orders. This delivery or deliveries is/are
then invoiced by the Seller to the Buyer. Finally, the Buyer pays the Payee.
A purchase order is sent by the Buyer as a single document. Depending on the contract between the
Seller and the Buyer the purchase order may be confirmed by the Seller or even be the subject of
negotiation between Buyer and Seller (not shown in the diagram). The resulting purchase order then
may result in one or more deliveries (e.g. regular monthly or periodic supply with multiple deliveries
under one PO). Deliveries result in an invoice. An invoice may refer to multiple deliveries and multiple
purchase orders.
A delivery may include the pick-up and return of returnable packaging from previous deliveries and, for
which a payment (deposit) had previously been made by the Buyer and had been received by the Seller.
Depending on the agreement between the Seller and Buyer, this deposit may need to be reimbursed to
the Buyer using the invoice to account for reimbursement. The invoice may therefore contain lines with
a negative amount. Alternatively, credit notes may be used instead.
In a number of national and legal environments, descriptions of products, names and addresses of
parties, and locations are obligatory in the electronic messages. Therefore, textual representation of
these objects is included in the Core Invoice Model. In other jurisdictions, the Buyer and the Seller may
agree on one or more Identification Schemes for products, locations, parties and other objects. These
schemes remove the need for textual based descriptions and names and addresses of the objects
identified. These schemes are usually agreed in advance of the Purchase to Pay process and there are
various mechanism used for this. This process is called Master Data Synchronisation. In the Core Invoice
Model it is assumed that a Master Data Synchronisation process has not been implemented.
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.