SIST-TS CEN/TS 16931-3-3:2026

SLOVENSKI STANDARD
01-oktober-2026
Elektronsko izdajanje računov - 3-3. del: Povezava EN 16931-1 s sintakso
UN/CEFACT XML Industry Invoice
Electronic invoicing – Part 3-3: Syntax binding of EN 16931-1 to UN/CEFACT XML
Industry Invoice
Elektronische Rechnungsstellung - Teil 3‑3: Syntaxbindung von EN 16931‑1 nach
UN/CEFACT XML Industry Invoice
Ta slovenski standard je istoveten z: CEN/TS 16931-3-3:2026
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-3-3
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
July 2026
TECHNISCHE SPEZIFIKATION
ICS 35.240.63; 35.240 Supersedes CEN/TS 16931-3-3:2020
English Version
Electronic invoicing - Part 3-3: Syntax binding of EN
16931-1 to UN/CEFACT XML Industry Invoice
Elektronische Rechnungsstellung - Teil 3-3:
Syntaxbindung von EN 16931-1 nach UN/CEFACT XML
Industry Invoice
This Technical Specification (CEN/TS) was approved by CEN on 15 June 2026 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 NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

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

Contents Page
European foreword . 3
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Syntax binding to the UN/CEFACT XML Cross Industry Invoice . 8
4.1 Introduction . 8
4.2 CII XML versions . 9
4.3 Mismatches and Discrepancies .11
4.3.1 Semantic alignment .11
4.3.2 Structural alignment .12
4.3.3 Cardinality assessment .12
4.3.4 Datatype Alignment .13
4.4 Effective Cardinality .14
4.5 Codes and identifiers .15
4.6 Mapping the Invoice model .15
4.7 Validation artefacts . 148
4.8 Syntax Business Rules . 148
4.8.1 Syntax constraints . 148
4.8.2 Data Type constraints . 148
4.9 Necessary Mapping for Backwards Compatibility . 148
5 Mapping Mismatches . 149
5.1 Semantic level . 149
5.2 Structural level . 150
5.3 Cardinality level . 150
5.4 Syntactical level . 150
Bibliography . 151

European foreword
This document (CEN/TS 16931-3-3:2026) has been prepared by Technical Committee CEN/TC 434
“Electronic invoicing”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association, and supports essential requirements of EU Directive 2014/55/EU [1]
and Council Directive 2006/112/EC [2].
This document supersedes CEN/TS 16931-3-3:2017.
This document is part of a set of documents, consisting of:
— EN 16931-1:2026 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:2026, Electronic invoicing - Part 3 - 1: Methodology for syntax bindings of the
core elements of an electronic invoice
— CEN/TS 16931-3-2:2026, Electronic invoicing - Part 3 - 2: Syntax binding for ISO/IEC 19845 (UBL)
invoice and credit note
— CEN/TS 16931-3-3:2026, Electronic invoicing - Part 3 - 3: Syntax binding for UN/CEFACT XML Cross
Industry Invoice
— CEN/TS 16931-3-4:2026, Electronic invoicing - Part 3 - 4: Syntax binding for UN/EDIFACT INVOIC
— CEN/TR 16931-4:2017, Electronic invoicing - Part 4: Guidelines on interoperability of electronic
invoices at the transmission level
— CEN/TS 16931-5:2026, Electronic invoicing - Part 5: Guidelines on the use of sector or country
extensions in conjunction with EN 16931-1, including a methodology to be applied in the real
environment
— CEN/TR 16931-6:2017, Electronic invoicing - Part 6: Result of the test of the European standard with
respect to its practical application for an end user - Testing methodology
— CEN/TR 16931-7, Electronic invoicing - Part 7: Methodology for the development and use of EN
16931-1 compliant structured Core Invoice Usage Specifications
— CEN/TR 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
— CEN/TR 16931-10, 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 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 e-invoices will generate
savings of around EUR 240 billion over a six-year period” [3]. Based on this recognition “The
Commission wants to see e-invoicing become the predominant method of invoicing by 2020 in Europe.”
As a means 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 (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.
This CEN Technical Specification CEN/TS 16931-3-3 defines the binding of the core elements of the
invoice to UN/CEFACT XML. Other subparts of this CEN Technical Specifications define the binding
method (CEN/TS 16931-3-1) and map the core invoice model to other syntaxes such as UBL XML
(CEN/TS 16931-3-2) and ISO/IEC 9735 (UN/EDIFACT) (CEN/TS 16931-3-4).
By ensuring 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 different national rules and standards – and thus contribute to the goals set by the
European Commission.
1 Scope
This document specifies the mapping between the semantic model of an electronic invoice, included in
EN 16931-1 and the Cross Industry Invoice in the UN/CEFACT XML syntax. For each element in the
semantic model (including sub-elements or supplementary components such as Identification scheme
identifiers) it is defined which element in the syntax is to be used to contain its information contents.
Any mismatches between semantics, format, cardinality or structure are indicated.
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 - Semantic data model of the core elements of an electronic invoice
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
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 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.
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 can
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
3.16
Core Conformant
respect of 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 Syntax binding to the UN/CEFACT XML Cross Industry Invoice
4.1 Introduction
One part of the basis for the European Core Data Model are the CEN MUG CWAs which are a subset of
Cross Industry Invoice (CII) [4]. UN XML standards are developed within UN/CEFACT. This guarantees
an international focus, openness in the process and free usage, as this is the mission of UN/CEFACT [5]
and the policy of UNECE as a global standardisation body. For all published specifications and standards
the Intellectual Property Rights (IPRs) are owned by the UN, and as such are open for free use by
everyone. UN/CEFACT XML and all underlying standards (i.e. Core Component Methodology, Library,
Message Assembly, XML Naming & Design Rules) are maintained on a regular basis by UN/CEFACT,
within the United Nations framework of the Economic and Social Council, the United Nations Economic
Commission for Europe (UNECE). The maintenance process is documented, applied and governed. All
relevant procedural documents are available. Open participation for all interested stakeholders is
ensured through the national delegations, which are usually connected to the national standards bodies.
Also recognised organisations are able to participate in the development and maintenance process.
UN/CEFACT standards are actively used worldwide in various sectors like Agriculture, Transport &
Logistics, B2G EProcurement and cross-sector applicationsin different regions (APAC, US, Europe,
LatAm).
Apart from Invoice (CII) implementations, UN/CEFACT standards are implemented within the US
Department of Defense. Within the global GS1 Community UN/CEFACT XML is used (apart from EANCOM
& GS1 XML) in several countries worldwide. In other industries and domains CII and UN/CEFACT syntax
has been adopted as well, e.g. Japan, Taiwan (Single Window for reference WCO DATA MODEL and
UN/CEFACT XML & UNTDED) or Korea (cross industry tax e-invoice is obligation of law).
CII, as part of cross-sector supply chain processes is implemented in various European countries, e.g.

⎯ French Public eInvocing Platform (CHORUS)
⎯ German B2B and B2C core invoice standard (Factur-X/ZUGFeRD)
UN/CEFACT provides the relevant standards and guidelines on their website.
Support to the implementers and users is provided through other standardisation bodies (e.g. CEN, GS1),
user communities, experts who are members of a national delegation at UN/CEFACT, etc. which building
their recommendations/guidelines upon published UN/CEFACT standards.
UN/CEFACT offers the CCBDA CCL message assembly methodology as guideline on how to modify the
underlying data model to enable subsetting. Applying the respective naming and design rules the syntax
becomes restricted or extended.
CCBDA supports message assembly and message contextual customisation based on the Reference ABIE
Library of the CCL. It is important to explain that extension is supported within the bounds of those
reference ABIEs and, of course, submissions to extend any ABIE can be submitted to Library Maintenance
for future inclusion. The aim is a controlled mechanism on extensions in order to facilitate
interoperability.
In order to facilitate an easy, sustainable, and effective implementation of the EN, the syntax mapping is
aligned with the most current to D25A compatible version of the Cross Industry Invoice XML. This version
contains two sets of schemas. One with coupled code list modules that allow a one-step validation for the
UN/CEFACT Standard; the second with decoupled code list modules. This second set of schemas
(decoupled) must be taken as code lists are being updated every 6 months at a EU website [6].
4.2 CII XML versions
This Syntax binding is based on UN/CEFACT SCRDM D25A. Although it is not restricted to a specific
UN/CEFACT XML version, only CII D25A and any subsequent Dxxx version have all syntax elements which
are needed for the current revision EN 16931-1:2026.

The old EN 16931-3-3:2017 was based on CII D16B. Later versions of UN/CEFACT XML are backwards
compatible with version CII D16B.

The following Tables list the new CII D25A syntax elements being used in EN 16931-3-2:2026 in the order
of the semantic model. For guidance on backwards compatible mapping, see Table 14.

Table 1 — New CII invoice XML
ID XPath (old and new) Reason
Since D25A unbounded: BT-10 changed to have
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransact unbounded cardinality
BT-10 ion/ram:ApplicableHeaderTradeAgreement/ram:BuyerRefe (may appear more than
renceID once) and may have a
Code in BT-10-1
Since D25A:
Qualifying the Buyer
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransact
BT-10-1 Reference with a Code
ion/ram:ApplicableHeaderTradeAgreement/ram:BuyerRefe
from UNTDID 1153 [6]
renceID/@schemeID
Since D22B unbounded:
BG-3 changed to have
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransact
BG-3 unbounded cardinality
ion/ram:ApplicableHeaderTradeSettlement/ram:InvoiceRef
(appear more than once)
erencedDocument
New BT
Since D25A: with
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransact ram:SpecifiedTradeAllo
ion/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedT wanceCharge/ram:Char
BT-213
radeAllowanceCharge/ram:CategoryTradeTax/ram:SupplyT geIndicator/udt:Indicato
ypeCode r[.='false']
Since D25A: New BT
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransact with
ion/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedT ram:SpecifiedTradeAllo
BT-214 radeAllowanceCharge/ram:CategoryTradeTax/ram:SupplyT wanceCharge/ram:Char
ypeCode geIndicator/udt:Indicato
r[.='true']
Since D25A:
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransact
BT-210
ion/ram:ApplicableHeaderTradeSettlement/ram:Applicable New BT

TradeTax/ram:SupplyTypeCode
Since D25A:
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransact
ion/ram:IncludedSupplyChainTradeLineItem/ram:Specified
BT-196 New BT
LineTradeSettlement/ram:ApplicableTradeTax/ram:Supply
TypeCode
4.3 Mismatches and Discrepancies
4.3.1 Semantic alignment
The first step in mapping a semantic model to a syntax is to determine if each element in the semantic
model has a corresponding element in the syntax. The corresponding element in the syntax shall have a
similar or wider semantic definition with respect to the definition of the semantic model element. The
definition of the syntax element may be implied by the name of that element. For example: an element
named “VAT Amount” in the semantic model may be mapped to an element named “Tax Amount” in the
syntax specification. As VAT is a type of tax, the element “Tax Amount” is a wider concept than VAT
Amount. The semantic relation between elements from the semantic model and elements from the syntax
specification can be specified using SKOS [7] relation types
At the semantic level the following types of semantic mismatches between individual elements may
occur.
Table 2 —Semantic alignment
SOURCE
TARGET
ID (Semantic Example Issue Resolution
(Syntax)
)
SEM- wider smaller SOURCE specifies The semantic rules of 1) find another element in
1 ‘Taxes’, while TARGET TARGET may be TARGET to put the violating
specifies ‘VAT’ violated. instances (those taxes that are
not VAT)
(SKOS: narrower) 2) accept that you are abusing
an element in TARGET for
something it was not
(entirely) designed for.
3) Request to widen semantic
definition of TARGET
SEM- smaller wider SOURCE specifies All instances that Unless other elements are
2 "VAT", Target specifies comply to SOURCE will mapped to the wider element
"Taxes" also comply to TARGET, as well, specify the narrower
but some of the meaning in the documentation
(SKOS: broader) semantics are lost: the (VAT instead of Tax).
type of Tax is not
specified any more.
SEM- overlap overlap SOURCE specifies The semantic rules of 1) accept that you are abusing
3 Employee (including TARGET may be an element in TARGET for
teachers, staff, violated. something it was not
researchers –that are on (entirely) designed for.
payroll- etc) and 2) Request to widen semantic
TARGET specifies definition of TARGET
Researcher (can be both
enlisted as employee,
but also be a student).
(SKOS: related)
SEM- match no match TARGET is missing any It is not possible to put 1) Use a (more) generic
4 element to specify a certain information in element
person. the TARGET. 2) Request to add an element
in TARGET.
4.3.2 Structural alignment
The second step is to review the “structural context” of the information element in the respective
syntaxes. The structural context of an element is part of its semantic definition. Electronic messages in
the different syntaxes represent data in different levels, groupings and sequences. For example, a VAT
Amount element on line level in the model should not be mapped on a VAT Amount element on document
level in the syntax specification.
The following structural mismatches may occur
Table 3 —Structural alignment
TARGE
SOURCE T
ID Example Issue Resolution
(Semantic) (Syntax
)
STR-1 Hierarchical Hierarc Packing of items can be Yes Complex mapping. Packs are
order one hical listed as items and then lifted to higher level and
to many order where they are packed or equivalent packs need to be
many to as a list of packs and what combined.
one items are in each pack.
STR-2 element on element SOURCE specifies Possibly if higher level
higher level on element at top level with cardinalities cause
lower a single repetition but conflicts.
level TARGET is in a class that
is also used for other data
that requires repetition of
the class.
STR-3 grouping A- differen SOURCE may define a Possibly.
B-C t group of elements such as
groupin payment instructions that
g may be repeated as a
group but if those
elements are differently
grouped in TARGET, that
repetition may be
problematic.
STR-4 higher less SOURCE has Yes. Agree on a rule to concatenate
detail detail name/lastname> and TARGET
TARGET only has
.
STR-5 less detail higher TARGET has Depends Agree on a rule (if possible) to
detail name/lastname> and several TARGET elements
SOURCE only has
.
4.3.3 Cardinality assessment
Cardinality defines whether or not an element shall be used, may be omitted and how many times it might
be repeated in a specific context. The cardinality of an element in the syntax shall be the same or less
restrictive than the corresponding element in the model. An element that is mandatory in the model may
be optional in the syntax specification, but not the other way around. An element that is repeating in the
model shall also be repeating in the syntax specification.
The following cardinality mismatches may occur.
Table 4 —Alignment of cardinalities
ID SOURCE TARGET Example Issue Resolution

CAR-1 optional mandatoy If the element is not Agree on ‘default value if missing’
(0.x) (1.x) present, the target rules (e.g. 0, 1-1-1970, AAA).
are violated.
CAR-2 mandatoy optional None. Add a rule in the target that the
(1.x) (0.x) element shall be present.

CAR-3 single multiple None. Add a rule in the target that the
(X.1) (X.N) element shall not be repeated.

CAR-4 multiple single Repeating elements cannot 1) If possible, repeat a higher level
(X.N) (X.1) be handled. in the structure
2) In the case of text elements,
concatenate the repeating
elements
CAR-5 element element Yes. Agree on ‘default value if missing’
missing mandatory (e.g. 0, 1-1-1970, AAA).
4.3.4 Datatype Alignment
EN 16931-1 defines the following semantic data types:
Table 5 —Semantic data types
Basic type Definition
An amount states a numerical monetary value. The currency of the amount is defined as a
separate business term. This EN16931_ Amount. Type is based on the Amount. Type as
Amount. Type
defined in ISO 15000-5:2014 Annex A. EN16931_ Amount. Type is floating up to two fraction
digits.
A unit price amount states a numerical monetary amount value for data elements that contain
item prices that may be multiplied by item quantities. The currency of the amount is defined
Unit Price Amount. Type
as a separate business term. This EN16931_ Unit Price_ Amount. Type is based on the Amount.
Type as defined in ISO 15000-5:2014 Annex A.
Quantities are used to state a number of units such as for items. The code for the Unit of
Measure is defined as a separate business term. This EN16931_ Quantity. Type is based on the
Quantity. Type
Quantity. Type as defined in ISO 15000-5:2014 Annex A. EN16931_ Quantity. Type is floating
up to five fraction digits.
Percentages are given as fractions of a hundred (per cent) e.g. the value 34.78 % in percentage
Percentage. Type terms is given as 34.78. This EN16931_ Percentage_ Numeric. Type is based on the Numeric.
Type as defined in ISO 15000-5:2014 Annex A. EN16931_ Percentage_ Numeric.
Identifiers (IDs) are keys that are issued by either the sender or recipient of a document or by
a third party. For each identifier in the model it is stated whether an identification scheme
shall be defined and if so, from what list the identification schemes may be chosen. This
Identifier. Type
EN16931_ Identifier. Type is based on the Identifier. Type as defined in ISO 15000-5:2014
Annex A. The Scheme identifier Identifies the scheme on which the identifier is based.
The use of this attribute is specified for each information element in the semantic model.
Identifiers that were assigned to a document or document line by the Buyer, the Seller or by a
Document Reference.
third party. This EN16931_ Document Reference_ Identifier. Type is based on the Identifier.
Type
Type as defined in ISO 15000-5:2014 Annex A.
Dates shall be in accordance to the “Calendar date complete representation” as specified by
ISO 8601 (see ISO 8601:2004, 5.2.1.1). Calendar dates do not include a specification for the
Date. Type
time of the day. This EN16931_ Date_ Date Time. Type is based on the Date Time. Type as
defined in ISO 15000-5:2014 Annex A.
Text is the actual wording of anything written or printed. The language of the textual business
terms in the invoice is defined in a separate business term in the model (BT-4 Invoice
Text. Type
language code). This EN16931_ Text. Type is based on the Text. Type as defined in ISO 15000-
5:2014 Annex A. Line breaks in the text may be present.
Times shall be represented as specified by ISO 8601 (see ISO 8601-1:2019, Date and time
— Representations for information interchange — Part 1: Basic rules). The
representation shall include timezone information. This EN 16931_ Time_ Date Time.
Time Type
Type is based on the Date Time. Type as defined in ISO 15000-5:2014, Annex B. The
content of the Date Time. Format. Text attribute is left to the syntax in which the Time is
represented.
Basic type Definition
Binary objects can be used to describe files which are transmitted together with the Invoice.
Attachments shall be transmitted together with the Invoice. There shall be only one way
defined per syntax. This EN16931_ Binary Object. Type is based on the Binary Object. Type as
Binary Object. Type
defined in ISO 15000-5:2014 Annex A. EN16931_ Binary Object. Type has two supplementary
components: a Mime Code, which specifies the Mime type of the attachment and a Filename
that is provided by (or on behalf of) the sender of the invoice.
These data types are further defined in EN 16931-1. These definitions are based on the data type
definitions in ISO 15000-5. Data types are composites, consisting of a content and zero or more
supplementary components. Syntax specifications may deviate from the EN 16931-1 definitions, while
being based on the same ISO 15000-5 data types. For example, the set of supplementary components
may be different. They also may define different restrictions, such as field lengths.
The following issues may arise at data format level when mapping the model to a syntax:
Table 6 —Data type alignment
ID SOURCE TARGET Example Issue Resolution

SYN-1 wider Smaller the SOURCE element has Yes, since some of the
datatype string, TARGET has values SOURCE instances
datatype integer (or: can hold, will not be valid
DateTime vs Date). in TARGET.
SYN-2 smaller Wider SOURCE is integer, TARGET is No Not needed.
string.
SYN-3 match no match Source has DateTime, Yes Add tranformation logic.
TARGET Timestamp.
Further information on Data Types and relevant Codelists for the Cross Industry Invoice can be found in
the Requirement Specification Mapping (RSM) document at the UNECE website [8]. The following
additional rules are applied:
⎯ For the udt:DateTimeType only the DateTimeString choice shall be used. For the corresponding
attribute @format the codelist UN/CEFACT 2379 [6] is applied.
⎯ For the mapping of the SDM date only code “102” (CCYYMMDD) shall be used.
⎯ For the mapping of the SDM time only code “208” (CCYYMMDDhhmmssZhhmm ) shall be used.
4.4 Effective Cardinality
Effective Cardinality represents the occurrence count of a Business Term (BT) in a syntax. It is relevant if
the BT consists of multiple XML nodes relative to its parent BG.
It is calculated as follows:
• The cardinality of a BT results from multiplying the cardinalities (either min or max) of each
XML nodes along its XPath hierarchy between BT and its parent – usually the BG. Minimal and
maximal cardinality are being multiplied separately. For example: If a relative BT path of its
parent consists of two elements: A parent element with cardinality (2.4) and with a child with
cardinality (3.5), the Effective Cardinality would be (6.20).
• If the BG is not an ancestor of a BT, the relevant path to evaluate is the “non-common”
(relative) path segments.
• For BTs like BT-10-1, the parent is BT-10, not a BG, and cardinality is relative to the parent BT.

C = Century, Y = Year; M = Month; D = Day; h = Hour; m = Minute, s = Seconds, Z = leading plus/minus sign, hhmm
= difference to UTC in Hours and Minutes
• The Effective Cardinality of a BG calculated like a BT relative to its parent BG.
4.5 Codes and identifiers
As UN/CEFACT XML fully supports the codelists referenced by the Semantic Data Model (SDM) the
corresponding codes to the semantic requirements of the latest published listscan be used without any
additional mapping. For the following codes lists special rules are applied:
⎯ ISO 4217 (Currencies): The alpha-3-representation shall be used. The currency shall only be given
on document level in /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/
ram:ApplicableSupplyChainHeaderTradeSettlement/ram:InvoiceCurrencyCode. Only if a different
TaxCurrencyCode is to be used the currency code shall be given at the appropriate element.
⎯ BT-8 (Value added tax point date code). While the model defines a restriction of UNTDID 2005, CII
supports in the mapped to element a restriction of UNTDID 2475 as follows:
Table 7 — Codes
Semantic model Code in UNTDID 2005 Code for CII in UNTDID 2475
Invoice document issue date 3 5
Delivery date, actual 35 29
Paid to date 432 72
4.6 Mapping the Invoice model
In the following table the semantic data model of the EN 16931-1 is mapped to the corresponding
XPaths of the Cross Industry Invoice XML message structure. The cardinality column for the syntax
represents the cardinality as it is defined by UN/CEFACT to illustrate differences between the semantic
data model and the respective syntax. The cardinality of the data model is taken into account by the
corresponding validation artefacts.
Syntax binding is represented by two tables defining the mapping. The first table maps the elements of
the semantic model on the syntax elements. This table is normative. The table is represented as follows:
Table 8 —Semantic model to syntax elements table lay-out
Semantic Syntax
A B C D E F G H I
ID BT Description Path Discrepancy
Effect.
Type and
Card.
resolution
The first table contains the following columns:
Column A: Business Term ID (in the semantic model)
Column B: Structural level (in the semantic model)
Column C: Cardinality (in the semantic model)
Column D: Business Term (in the semantic model)
Column E: Description (in the semantic model)
Column F: Path (XPath to the element in the XML syntax)
1. W3C XPath expression pointing to a single element or attribute (with @ prefix)
2. If there are multiple choices for a semantic the union operator | concatenates the choices and
the result is a set of all possibilities
3. If there are conditions a predicate [] defines the condition in structured form, e.g.:
• "udt:DateString/@format[.='102']" the value of the attribute @format shall be "102"
Level
Card.
• "udt:DateString[@format='102']" the element shall have an
attribute with the value "102".
Column G: Type (XSD types defined by the XSD grammar)
Column H: Effective Cardinality (in the syntax)
Column I: Discrepancy and resolution
1. Mismatch (see 4.3 Mismatches and Discrepancies)
2. Resolution
The second table is mapping syntax elements on the elements of the semantic model. This table is
informative and may be helpful to implementers.
Table 9 —Syntax elements to semantic model table lay-out
Syntax specification Semantic model
A B C D E F G
Path ID Level Card. BT Description

Column A: Path (in the syntax)
Column B: Effective Cardinality
Column C: Business Term ID (in the semantic model)
Column D: Structural level (in the semantic model)
Column E: Cardinality (in the semantic model)
Column F: Business Term (in the semantic model)
Column G: Description (in the semantic model)

Effect.
Card.
Table 10 — Semantic model to UN/CEFACT syntax elements mapping (normative)
ID BT Description Path Type Discrepancy and
resolution
rsm:CrossIndu
The European Core Invoice
BG-0 0 1.1 Core Invoice /rsm:CrossIndustryInvoice stryInvoiceTyp 1.1

(EN16931)
e
A unique identification of
the invoice.
Usage Note: The sequential
number required in Article
226(2) of the directive
2006/112/EC [2], to
uniquely identify the invoice
Invoice within the business context, /rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram:
BT-1 1 1.1 udt:IDType 0.1 CAR-2
number time-frame, operating ID
systems and records of the
Seller. It may be based on
one or more series of
numbers, which may
include alphanumeric
characters. No Identification
Scheme is to be used.
BT-2 and BT-166 are
represented by a
single date/time
element.
If BT-166 is not
provided, only the
date shall be given
Invoice issue The date when the invoice /rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram: udt:DateTimeS using format "102"
BT-2 1 1.1 1.1
date was issued. IssueDateTime/udt:DateTimeString[@format='102'] tring (CCYYMMDD), e.g.
"20260115".
If BT-166 is
provided, date and
time shall be given
using format "208"
(CCYYMMDDhhmms
sZhhmm). This
Level
Card.
Effect.
Card.
ID BT Description Path Type Discrepancy and
resolution
format includes a
UTC offset; for
example,"20250115
120503+0100" for
CET and
"20250820190503+
0200" for CEST
(summer time).
CAR-2; In the EN
core, for the "Invoice
issue date code",
only the date format
"102"
("CCYYMMDD") shall
Invoice issue /rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram:
BT-2-1 2 1.1 xs:string 0.1 be used from
date code IssueDateTime/udt:DateTimeString/@format[.='102']
UNTDID 2379 (Date
or time or period
format code), as
mandated by the
European
Commission [6].
BT-2 and BT-166 are
represented by a
single date/time
element.
If BT-166 is not
provided, only the
date shall be given
Invoice issue The time of the day when /rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram: udt:DateTimeS using format "102"
BT-166 1 0.1 1.1
time the invoice was issued. IssueDateTime/udt:DateTimeString[@format='208'] tring (CCYYMMDD), e.g.
"20260115".
If BT-166 is
provided, date and
time shall be given
using format "208"
(CCYYMMDDhhmms
sZhhmm), including
Level
Card.
Effect.
Card.
ID BT Description Path Type Discrepancy and
resolution
the UTC offset, e.g.
"20250115120503+
0100" for CET time,
and would be
"20250820190503+
0200" for CEST Time
(summer)
CAR-2; In the EN
core, for the "Invoice
issue time code",
only the time format
code "208"
("CCYYMMDDHHMM
Invoice issue /rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram:
BT-166-1 2 1.1 xs:string 0.1 SSZHHMM") shall be
time code IssueDateTime/udt:DateTimeString/@format[.='208']
used from UNTDID
2379 (Date or time
or period format
code), as mandated
by the European
Commission [6].
A code specifying the CAR-2; In the EN
functional type of the core, for the "Invoice
invoice. type code", only
Usage Note: Commercial invoice document
invoices and credit notes types and credit note
are defined according to the document types shall
Invoice type entries in UNTDID 1001 /rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram: qdt:Document be used from
BT-3 1 1.1 0.1
code [6].Other entries of UNTDID TypeCode CodeType UNTDID 1001
1001 [6] with specific (Document name
invoices or credit notes may code), as mandated
be
...