FprCEN/TS 16931-3-2

SLOVENSKI STANDARD
01-april-2026
Elektronsko izdajanje računov - 3-2. del: Povezava sintakse za račun in dobropis
EN 16931-1 na ISO/IEC 19845 (UBL)
Electronic invoicing – Part 3-2 Syntax binding of EN 16931-1 to ISO/IEC 19845 (UBL)
invoice and credit note
Ta slovenski standard je istoveten z: FprCEN/TS 16931-3-2
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
February 2026
ICS Will supersede CEN/TS 16931-3-2:2020
English Version
Electronic invoicing - Part 3-2 Syntax binding of EN 16931-
1 to ISO/IEC 19845 (UBL) invoice and credit note

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
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. FprCEN/TS 16931-3-2:2026 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 Syntax binding to UBL . 7
4.1 Introduction . 7
4.2 UBL XML versions . 8
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 Mapping the Invoice model .15
4.6 Mapping the Credit Note model . 140
4.7 Necessary Mapping for Backwards Compatibility . 263
4.8 Validation artefacts . 265
5 Mapping Mismatches . 265
5.1 Semantic level . 265
5.2 Structural level . 266
5.3 Cardinality level . 266
5.4 Syntactical level . 266
Bibliography . 267

European foreword
This document (FprCEN/TS 16931-3-2:2026) 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 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-2: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.
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-2 defines the binding of the core elements of the
invoice to UBL. Other subparts of this CEN Technical Specification define the binding method
(CEN/TS 16931-3-1) and map the core invoice model to other syntaxes such as UN/CEFACT XML
(CEN/TS 16931-3-3) and 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 UBL 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 - Part 1: 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 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
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 Syntax binding to UBL
4.1 Introduction
The Universal Business Language (UBL) is developed by the OASIS open standards consortium. OASIS is
a non-profit, international consortium that drives the development, convergence and adoption of open
standards for the global information society.
UBL is designed to provide a universally understood and recognized syntax for legally binding business
documents and to operate within a standard business framework such as ISO 15000 (ebXML)[4] to
provide a complete, standards-based infrastructure that can extend the benefits of existing EDI systems
to businesses of all sizes. UBL is freely available to everyone without legal encumbrance or licensing fees.
UBL is widely used around the world for procurement (e.g. ordering and electronic invoicing), sourcing
(e.g. tendering and catalogues), replenishment (e.g. managed inventory) and transportation and logistics
(e.g. waybills, forwarding instructions, and intermodal freight management). UBL provides the standards
for the PEPPOL (Pan European eProcurement Online) network and public procurement initiatives in
Austria, Belgium, Czech Republic, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy,
Netherlands, Norway, Spain, Sweden, and UK (NHS).
UBL schemas are modular, reusable, and extensible in XML-aware ways. As the first standard
implementation of ebXML Core Components Technical Specification 2.01, the UBL Library is based on a
conceptual model of information components known as Business Information Entities (BIEs). These
components are assembled into specific document models such as invoice and order. These document
models are then transformed in accordance with UBL Naming and Design Rules into W3C XSD schema
syntax as defined from the OASIS UBL Technical Committee [5]. This approach facilitates the creation of
UBL-based document types beyond those specified in this release.
4.2 UBL XML versions
This Syntax binding is based on UBL Version 2.5. Although it is not restricted to a specific UBL version,
only UBL 2.5 and any subsequent UBL 2.x version have all syntax elements which are needed for the
current revision EN 16931-1:2026.
The old EN 16931-3-2:2017 was based on UBL 2.1 (released as an ISO and IEC International Standard,
and given the designation ‘ISO/IEC 19845:2015’). Later versions of UBL are backwards compatible with
version 2.1.
The following Tables list the new UBL 2.5 syntax elements being used in EN 16931-3-2:2026 in the order
of the semantic model. Table 1 shows the XPaths for the Invoice, Table 2 for the Credit Note. For guidance
on backwards compatible mapping, see Tables 14 and 15:
Table 1 — New UBL invoice XML
ID XPath (old and new) Reason
BT-10 changed to have
UBL2.1:
unbounded cardinality
/Invoice/cbc:BuyerReference
BT-10 (appear more than once)
Since UBL 2.5:
and may have a Code in
/Invoice/cac:BuyerReference/cbc:BuyerReference
BT-10-1
Qualifying the Buyer
Since UBL 2.5
BT-10-1 Reference with a Code
/Invoice/cac:BuyerReference/cbc:BuyerReferenceCode
from UNTDID 1153 [6]
Since UBL 2.5:
BT-197 New BT
/Invoice/cac:DeliveryNoteDocumentReference/cbc:ID

Since UBL 2.5:
BT-182 /Invoice/cac:PaymentTerms/cac:PenaltyInterestRate/cbc:In New BT
terestRatePercent
UBL 2.1:
There was no Invoice
/Invoice/cbc:Note
BT-21 Note Subject Code in
Since UBL 2.5:
UBL 2.1
/Invoice/cac:Annotation/cbc:SubjectCode
UBL 2.1: Invoice Note could be
/Invoice/cbc:Note added in UBL 2.1 only
BT-22
Since UBL 2.5: once. Unbounded were
/Invoice/cac:Annotation/cbc:AnnotationContent its translations.
New BT
Since UBL 2.5: with
BT-213 /Invoice/cac:AllowanceCharge/cac:TaxCategory/cbc:Supply cbc:ChargeIndicator
TypeCode [.='false']
New BT
Since UBL 2.5:
with
/Invoice/cac:AllowanceCharge/cac:TaxCategory/cbc:Supply
BT-214 cbc:ChargeIndicator
TypeCode
[.='true']
ID XPath (old and new) Reason

Since UBL 2.5:
BT-179 /Invoice/cac:CollectionInvoiceLine/cbc:TaxInclusiveLineExt New BT
ensionAmount
Since UBL 2.5:
BT-180
/Invoice/cac:CollectionInvoiceLine/cac:Item/cbc:Descriptio New BT

n
Since UBL 2.5:
BT-210
/Invoice/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cb New BT

c:SupplyTypeCode
Since UBL 2.5:
BT-198 /Invoice/cac:InvoiceLine/cac:Delivery/cac:DeliveryNoteDoc New BT
umentReference/cbc:ID
Since UBL 2.5:
BT-199 /Invoice/cac:InvoiceLine/cac:Delivery/cac:DeliveryNoteLin New BT
eReference/cbc:LineID
Since UBL 2.4:
BT-196 /Invoice/cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategor New BT
y/cbc:ItemSupplyTypeCode
Table 2 — New UBL credit note XML
ID XPath (old and new) Reason
UBL 2.1:
There was no CreditNote
/CreditNote/cac:PaymentMeans/cbc:PaymentDueDate
BT-9 Note cbc:DueDate in
Since UBL 2.2:
UBL 2.1
/CreditNote/cbc:DueDate
BT-10 changed to have
UBL 2.1: /CreditNote/cbc:BuyerReference unbounded cardinality
BT-10 Since UBL 2.5: (appear more than once)
/CreditNote/cac:BuyerReference/cbc:BuyerReference and may have a Code
from UNTDID 1153 [6]
Qualifying the Buyer
Since UBL 2.5
BT-10-1 Reference with a Code
/CreditNote/cac:BuyerReference/cbc:BuyerReferenceCode
from UNTDID 1153 [6]
Since UBL 2.5:
BT-197 New BT
/CreditNote/cac:DeliveryNoteDocumentReference/cbc:ID

ID XPath (old and new) Reason

Since UBL 2.5:
BT-182 /CreditNote/cac:PaymentTerms/cac:PenaltyInterestRate/cb New BT
c:InterestRatePercent
UBL 2.1:
There was no Credit
/CreditNote/cbc:Note
BT-21 Note Subject Code in
Since UBL 2.5:
UBL 2.1
/CreditNote/cac:Annotation/cbc:SubjectCode
UBL 2.1: Credit Note could be
/CreditNote/cbc:Note added in UBL 2.1 only
BT-22
Since UBL 2.5: once. Unbounded were
/CreditNote/cac:Annotation/cbc:AnnotationContent its translations.
New BT
Since UBL 2.5:
with
/CreditNote/cac:AllowanceCharge/cac:TaxCategory/cbc:Sup
BT-213 cbc:ChargeIndicator
plyTypeCode
[.='false']
New BT
Since UBL 2.5:
with
/CreditNote/cac:AllowanceCharge/cac:TaxCategory/cbc:Sup
BT-214 cbc:ChargeIndicator
plyTypeCode
[.='true']
Since UBL 2.5:
/CreditNote/cac:CollectionCreditNoteLine/cbc:TaxInclusive
BT-179 New BT
LineExtensionAmount
Since UBL 2.5:
BT-180 /CreditNote/cac:CollectionCreditNoteLine/cac:Item/cbc:Des
New BT
cription
Since UBL 2.5:
BT-210
/CreditNote/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory New BT

/cbc:SupplyTypeCode
Since UBL 2.5:
BT-198 /CreditNote/cac:CreditNoteLine/cac:Delivery/cac:DeliveryN New BT
oteDocumentReference/cbc:ID
Since UBL 2.5:
BT-199 /CreditNote/cac:CreditNoteLine/cac:Delivery/cac:DeliveryN New BT
oteLineReference/cbc:LineID
Since UBL 2.4:
BT-196 New BT
/CreditNote/cac:CreditNoteLine/cac:Item/cac:ClassifiedTax
Category/cbc:ItemSupplyTypeCode
As all later UBL 2.x versions are backward compatible with UBL 2.5, implementations should use the
latest backward-compatible UBL 2.x version published by the OASIS UBL Technical Committee [5].
The last column of the mapping table, entitled "Discrepancy and resolution", may include version-
related information of the following types in addition to other content:
1. indication that a data syntax element was introduced after UBL 2.1, e.g. "since UBL 2.5"
2. indication that the syntax cardinality was subsequently aligned with the semantic cardinality, e.g.
"Cardinality since CII D22B". The latter does not apply to UBL
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
The following types of semantic mismatches between individual elements that may occur are listed in
Table 3:
Table 3 —Semantic alignment
SOURCE TARGET
ID Example Issue Resolution
(Semantic) (Syntax)
SEM-1 wider smaller SOURCE specifies ‘Taxes’, The semantic rules of 1) find another element in
while TARGET specifies TARGET may be violated. TARGET to put the violating
‘VAT’ 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-2 smaller wider SOURCE specifies "VAT", All instances that comply Unless other elements are
Target specifies "Taxes" to SOURCE will also mapped to the wider element as
comply to TARGET, but well, specify the narrower
(SKOS: broader) some of the semantics are meaning in the documentation
lost: the type of Tax is not (VAT instead of Tax).
specified any more.
SEM-3 overlap overlap SOURCE specifies The semantic rules of 1) accept that you are abusing an
Employee (including TARGET may be violated. element in TARGET for something
teachers, staff, researchers it was not (entirely) designed for.
–that are on payroll- etc) 2) Request to widen semantic
and TARGET specifies definition of TARGET
Researcher (can be both
enlisted as employee, but
also be a student).
(SKOS: related)
SEM-4 match no match TARGET is missing any It is not possible to put 1) Use a (more) generic element
element to specify a certain information in the 2) Request to add an element in
person. TARGET. 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.
Structural mismatches are listed in Table 4:
Table 4 —Structural alignment
SOURCE TARGET
ID Example Issue Resolution
(Semantic) (Syntax)
STR-1 Hierarchical Hierarch Packing of items can be Yes Complex mapping. Packs are
order one to ical listed as items and then lifted to higher level and
many order where they are packed or as equivalent packs need to be
many to a list of packs and what items combined.
one are in each pack.
STR-2 element on element SOURCE specifies element at Possibly if higher level
higher level on lower top level with a single cardinalities cause
level repetition but TARGET is in a conflicts.
class that is also used for
other data that requires
repetition of the class.
STR-3 grouping A- different SOURCE may define a group Possibly.
B-C grouping of elements such as payment
instructions that may be
repeated as a group but if
those elements are
differently grouped in
TARGET, that repetition may
be problematic.
STR-4 higher detail less SOURCE has Yes. Agree on a rule to concatenate
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 cardinality mismatches that may occur are listed in Table 5:
Table 5 —Alignment of cardinalities
ID SOURCE TARGET Example Issue Resolution

CAR-1 optional mandatory 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 mandatory 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.
ID SOURCE TARGET Example Issue Resolution

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
The semantic data types of EN 16931 are listed in Table 6:
Table 6 —Semantic data types
Basic type Definition
An amount states a numerical monetary value. The currency of the amount is defined as a separate
Amount. Type business term. This EN 16931_ Amount. Type is based on the Amount. Type as defined in ISO 15000-
5:2014 Annex A. EN 16931_ 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 as a separate business
Unit Price Amount. Type
term. This EN 16931_ 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
Quantity. Type defined as a separate business term. This EN 16931_ Quantity. Type is based on the Quantity. Type as
defined in ISO 15000-5:2014 Annex A. EN 16931_ 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 terms is
Percentage. Type given as 34.78. This EN 16931_ Percentage_ Numeric. Type is based on the Numeric. Type as defined in
ISO 15000-5:2014 Annex A. EN 16931_ 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 EN 16931_ Identifier. Type is based on
Identifier. Type
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 third party.
Document Reference. Type This EN 16931_ Document Reference_ Identifier. Type is based on the Identifier. 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
Date. Type ISO 8601:2004, 5.2.1.1). Calendar dates do not include a specification for the time of the day. This EN
16931_ 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 language code). This EN
Text. Type
16931_ 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. Type is based on the Date Time. Type as defined
Time Type
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.
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 EN 16931_ Binary Object. Type is based on the Binary Object. Type as defined in ISO 15000-
Binary Object. Type
5:2014 Annex A. EN 16931_ 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 issues that may arise at data format level when mapping the model to a syntax are listed in Table 7:
Table 7 —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 transformation logic.
TARGET Timestamp.
As stated, UBL messages are constructed using reusable Business Information Entities. The (data) typing
mechanism in UBL also relies heavily on reuse of generic components, both within UBL, but also on the
Core Component Technical Specification. Typically, this has the following structure:
— The message specification (the invoice XSD) imports schema that specifies all the reusable Business
Information Entities (expressed as XML elements);
— The message is constructed by using these BIE’s;
— Each BIE (e.g. DocumentCurrencyCode) is based on a type with a similar name (e.g.
DocumentCurrencyCodeType);
— Each type is based on one of the UBL “Unqualified Data Types” (e.g. CodeType);
— Each Unqualified Data Type is based on one of the Core Component Types (ccts:CodeType).
Some of these datatypes have attributes. In UBL, the “Unqualified Data Types” also have attributes,
comparable with the datatypes in the EN.
When making a mapping from the EN to UBL, datatypes and their attributes (if applicable) have to be
taken into consideration. For each element in the EN, it should be clear where to map the contents of the
element, but also how to map the attributes. In most cases, an element from the EN with a specific
datatype (e.g. a Code) is mapped to an element in UBL that has a comparable datatype (e.g. CodeType).
There are however some exceptions.
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 or 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.
• The Effective Cardinality of a BG calculated like a BT relative to its parent BG.
4.5 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 Universal Business Language
(UBL) XML message structure. The cardinality column for the syntax represents the cardinality as it is defined by UBL 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 for invoice and credit note each. The first table maps the elements of the
semantic model on the syntax elements. This table is normative. Table 8 shows the structure of the normative semantic model to syntax mapping:
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 Discrep
ancy
Effect.
Type and
Card.
resoluti
on
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.:
• "cbc:BuyerReferenceCode/@listID[.='1153']" the value of the attribute @listID shall be "1153"
• "cbc:BuyerReferenceCode[@listID='1153' and @listAgencyID='6'] the element shall have two
attributes: @listID with the value "1153" and @listAgencyID with the value "6".
Column G: Type (XSD types defined by the XSD grammar)
Column H: Effective Cardinality (in the syntax)
Level
Card.
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 for
implementers.
Table 9 shows the structure of the informative syntax to semantic model mapping:
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)
Table 10 provides the normative data of the semantic model to UBL invoice syntax mapping:

Effect.
Card.
Table 10 — Semantic model to UBL invoice syntax elements mapping (normative)
ID BT Description Path Type Discrepancy and
resolution
The European Core Invoice
BG-0 0 1.1 Core Invoice /Invoice InvoiceType 1.1

(EN16931)
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,
BT-1 1 1.1 /Invoice/cbc:ID cbc:IDType 1.1

number time-frame, operating
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.
Invoice issue The date when the invoice cbc:IssueDateT Date is formatted
BT-2 1 1.1 /Invoice/cbc:IssueDate 1.1
date was issued. ype CCYY-MM-DD
Uses W3C xsd:time
with UTC offset, e.g.
19:05:19+01:00 for
Invoice issue The time of the day when cbc:IssueTime CET time, and it
BT-166 1 0.1 /Invoice/cbc:IssueTime 0.1
time the invoice was issued. Type should be
19:05:19+02:00 for
CEST Time
(summer)
A code specifying the CAR-2; In the EN
functional type of the core, for the "Invoice
invoice. type code", only
Invoice type cbc:InvoiceTyp
BT-3 1 1.1 Usage Note: Commercial /Invoice/cbc:InvoiceTypeCode 0.1 invoice document
code eCodeType
invoices and credit notes types and credit note
are defined according to the document types shall
entries in UNTDID 1001 be used from
Level
Card.
Effect.
Card.
ID BT Description Path Type Discrepancy and
resolution
[6].Other entries of UNTDID UNTDID 1001
1001 [6] with specific (Document name
invoices or credit notes may code), as mandated
be used if applicable.The by the European
subset of UNTDID 1001 that Commission [6], for
may be used is managed by example: "381"
or on behalf of CEN/TC434. ("Credit note").
The currency in which all
invoice amounts are given,
except for the Total VAT
amount in VAT accounting
currency.
Usage Note: Only one
CAR-2; In the EN
currency shall be used in
core, for the "Invoice
the invoice, except for the
currency code", the
Invoice total VAT amount in
cbc:DocumentC code list ISO 4217
Invoice VAT accounting currency
BT-5 1 1.1 /Invoice/cbc:DocumentCurrencyCode urrencyCodeTy 0.1 (Currency codes)
currency code (BT-111) and the VAT
pe shall be used, as
breakdown (BG-23) in
mandated by the
accordance with article 230
European
of Directive 2006/112/EC
Commission [6].
on VAT [2].The lists of valid
currencies are registered
with the ISO 4217
Maintenance Agency "Codes
for the representation of
currencies and funds".
The currency used for VAT
accounting and reporting
purposes as accepted or
SEM-2; In the EN
required in the country of
core, for the "VAT
the Seller.
accounting currency
Usage Note: Shall be used
VAT code", the code list
in combination with the cbc:TaxCurren
BT-6 1 0.1 accounting /Invoice/cbc:TaxCurrencyCode 0.1 ISO 4217 (Currency
Invoice total VAT amount in cyCodeType
currency code codes) shall be used,
VAT accounting currency
as mandated by the
(BT-111) when the VAT
European
accounting currency code
Commission [6].
differs from the Invoice
currency code. The lists of
valid currencies are
Level
Card.
Effect.
Card.
ID BT Description Path Type Discrepancy and
resolution
registered with the ISO
4217 Maintenance Agency
"Codes for the
representation of currencies
and funds" [6]. Please refer
to Article 230 of the Council
...