FprCEN/TS 16931-3-4

SLOVENSKI STANDARD
01-april-2026
Elektronsko izdajanje računov - 3-4. del: Sintaksa povezav za UN/EDIFACT INVOIC
D16B
Electronic invoicing - Part 3-4: Syntax binding for UN/EDIFACT INVOIC D16B
Elektronische Rechnungsstellung - Teil 3-4: Umsetzung in die Syntax UN/EDIFACT
INVOIC D16B
Facturation électronique - Partie 3-4 : Correspondance syntaxique pour les factures -
Schéma D16B UN/EDIFACT
Ta slovenski standard je istoveten z: FprCEN/TS 16931-3-4
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-4:2020
English Version
Electronic invoicing - Part 3-4: Syntax binding for
UN/EDIFACT INVOIC D16B
Facturation électronique - Partie 3-4 : Correspondance Elektronische Rechnungsstellung - Teil 3-4: Umsetzung
syntaxique pour les factures - Schéma D16B in die Syntax UN/EDIFACT INVOIC D16B
UN/EDIFACT
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-4: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 UN/EDIFACT . 7
4.1 Introduction . 7
4.2 Data types . 8
4.3 Codes and identifiers .16
4.4 Mapping the Invoice model .17
Bibliography . 210

European foreword
This document (FprCEN/TS 16931-3-4: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 and
Council Directive 2006/112/EC.
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-2 Electronic invoicing - Part 3 - 2: Syntax binding for ISO/IEC 19845 (UBL) invoice
and credit note
— CEN/TS 16931-3-3 Electronic invoicing - Part 3 - 3: Syntax binding for UN/CEFACT XML Cross
Industry Invoice
— CEN/TS 16931-3-4 Electronic invoicing - Part 3 - 4: Syntax binding for UN/EDIFACT INVOIC
— CEN/TR 16931-4 Electronic invoicing - Part 4: Guidelines on interoperability of electronic invoices
at the transmission level
— CEN/TS 16931-5 Electronic invoicing - Part 5: Guidelines on the use of sector or country extensions
in conjunction with EN 16931-1, including a methodology to be applied in the real environment
— CEN/TR 16931-6 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” . 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 [5] 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 document CEN/TS 16931-3-4 defines the binding of the core elements of the invoice to the
ISO/IEC 9735 syntax (UN/EDIFACT). 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
ISO/IEC 19845 (UBL 2.1) (CEN/TS 16931-3-2) and the Cross Industry Invoice of UN/CEFACT XML
(CEN/TS 16931-3-3).
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
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0712:FIN:en:PDF.
1 Scope
This document specifies the mapping between the semantic model of an electronic invoice, included in
EN 16931-1 and the ISO/IEC 9735 (UN/EDIFACT) 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.
2 Normative references
There are no normative references in this document.
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 [5]]
3.2
semantic data model
structured set of logically interrelated information elements
3.3
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:2026, 6.3 is a
table of information elements contained in the Core Invoice Model.

3.4
Structured Information Element
information element that can be processed automatically
3.5
syntax
machine-readable format used to represent the information elements contained in an Electronic Invoice
instance
3.6
business term
label assigned to a given information element which is used as a primary reference
3.7
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.8
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.9
core elements of an electronic invoice
set of essential information elements that an electronic invoice may contain in order to enable cross-
border interoperability, including the necessary information to ensure legal compliance
3.10
Extended Information Element
information element within the Scope for Extensions but outside the Core Invoice Model
Note 1 to entry: Extended Information Elements are sometimes informally referred to as extensions in other
documents.
3.11
Core Invoice Usage Specification (CIUS)
specification that provides detailed guidance, explanations, and examples, as well as rules (business
rules) related to the actual implementation and use of structured information elements present in the
Core Invoice Model in a specific trading situation
3.12
Core Invoice Instance Document
instance of an Electronic Invoice that is conformant with the Core Invoice Model
3.13
Extension Specification
specification describing the use of Extended Information Elements to the Core Invoice Model that may
reuse Extension Components
Note 1 to entry: An Extension Specification is intended to be published in the 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.14
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
3.15
identification scheme
collection of identifiers applicable for a given type of object governed under a common set of rules
3.16
Compliant
meets all the legal requirements and follows all the legal rules of any Directive associated with the
standard, particularly the VAT Directive
3.17
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.
4 Syntax binding to UN/EDIFACT
4.1 Introduction
UN/EDIFACT (ISO 9735) is a syntax for electronic data interchange for administration, commerce and
transport. UN/EDIFACT constructs are character strings in which the content of data elements is
separated by tags and delimiters. UN/EDIFACT has a hierarchical structure where the top level is referred
to as an interchange, and lower levels contain multiple messages which consist of segments, which in turn
consist of composites. The final iteration is an element which is derived from the United Nations Trade
Data Element Directory (UNTDED); these are normalized throughout the UN/EDIFACT standard .
The United Nations Economic Commission for Europe (UNECE), since the 1980s supported a number
projects to enable trade based on electronic messaging – UN/CEFACT and specific Recommendations.
In UN/CEFACT, standard messages using the UN/EDIFACT syntax (ISO 9735) were developed by various
working groups across the globe to facilitate administration, commerce and transport. These messages
mimicked standard paper documents used in everyday business transactions and were called United
Nations Standard Message types (UNSMs). Today these UNSMs are the most widely used e-messages
across the globe. UNSMs are built using the United Nations Trade Data Elements Directory (UNTDED)
with reusable elements, code sets, standard composites and segments which can be configured to meet
the function of a particular message such as an Invoice.
In the IT UNECE Trade Facilitation process, formal guidance is provided by publishing Recommendations.
These Recommendations cover a wide variety of topics but some are specific to electronic messaging.
For more information, please refer to http://www.unece.org/cefact/EDIFACT/welcome.html

See http://www.unece.org/fileadmin/DAM/trade/untdid/texts/d423.htm
4.2 Data types
XML based syntaxes have explicit semantic meanings included in the naming of the element (e.g.
DueDate) and associate a specific data type to it (e.g. xs:DateTime). UN/EDIFACT does it the other way
around. Having a set of clearly defined data types (e.g DTM for any kind of date or time information) the
semantic meaning is added through a qualifier. The information is then given in so called data elements.
This allows implementers to easily implement type checks and then map the information to the
corresponding semantic context: First it is checked, if in this case the given date string forms a valid date
and secondly the date gets a context for instance to be the actual delivery date. Data elements can be
logically grouped into so called composites. This allows to create a logic bracket for instance to define the
type of date or time information.
To allow efficient automatic processing the semantic meaning is added by using standardized code lists.
The following example illustrates this with the invoice issue date.
DTM+137:20161213:102’
Table 1 — The DTM segment for the invoice issue date
Type Name Description Example Meaning
Segment DTM To specify date, and/or time, or period. DTM
Composite C507 DATE/TIME/PERIOD
Data 2005 Date or time or period function code 137 Issue date/time
element qualifier
Data 2380 Date or time or period text 20161013 13th October 2026
element
Data 2379 Date or time or period format code 102 Format = CCYYMMDD
element
The combination of a qualifier for the date or time type (DTM) together with the corresponding data
elements is called a segment. Segments can be grouped in order to form a semantic container for instance
to define a party (e.g. buyer).
A group or segment can be mandatory (M) or conditional (C) and can be specified to repeat (cardinality).
Like a text document a UN/EDIFACT message is structured into header, details and summary section.
In order to allow a computer to recognize the difference between an XML instance and another text file
XML defines so called processing instructions. In addition, the XML based standards being relevant for
the EN 16931 add groups of elements that define the type of message and the context where it is used in.
In order to be processed an XML file needs to be well-formed.
In order to have a consistent UN/EDIFACT file the same concept is applied to the UN/EDIFACT instance.
So called service segments form the outer brackets of the information being present in a UN/EDIFACT
instance. They define the used version, character sets and ensure the consistency of the message itself.
The following table shows the basic segment structure of a UN/EDIFACT invoice message. Only those
segments, that are relevant for the mapping of the EN 16931-1 are shown.
Table 2 — UN/EDIFACT Standard Message INVOIC Structure according to D.24A
Level Name Status MaxOcc Content
0 UNA A 1 Service string advice
0 UNB M 1 Interchange header
1 UNH M 1 Message header
1 BGM M 1 Beginning of message
1 DTM R 1 Message date
1 DTM O 1 Value added tax point date
1 DTM O 1 Value added tax point date code
1 DTM O 1 Actual delivery date
1 DTM O 1 Invoicing period start date
1 DTM O 1 Invoicing period end date
1 ALI O 1 VAT breakdown goods/services code
1 FTX O 1 Seller additional legal information
The maximum number of FTX segments in header of an INVOIC
shall not exceed 99.
1 FTX O 99 Payment terms text
The maximum number of FTX segments in header of an INVOIC
shall not exceed 99.
1 FTX O 99 INVOICE NOTE
The maximum number of FTX segments in header of an INVOIC
shall not exceed 99.
1 FTX R 1 PROCESS CONTROL
The maximum number of FTX segments in header of an INVOIC
shall not exceed 99.
1 FTX O 1 Payment means text
The maximum number of FTX segments in header of an INVOIC
shall not exceed 99.
1 FTX C 99 VAT exemption reason
The maximum number of FTX segments in header of an INVOIC
shall not exceed 99.
1 SG1 O 1 SG 1 - Project reference
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 Project reference
1 SG1 O 1 SG 1 - Contract reference
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 Contract reference
1 SG1 O 1 SG 1 - Purchase order reference
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 Purchase order reference
1 SG1 O 1 SG 1 - Sales order reference
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 Sales order reference
Level Name Status MaxOcc Content
1 SG1 O 1 SG 1 - Receiving advice reference
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 Receiving advice reference
1 SG1 O 1 SG 1 - Despatch advice reference
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 Despatch advice reference
1 SG1 O 1 SG 1 - Delivery note reference
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 Delivery note reference
1 SG1 O 1 SG 1 - Tender or lot reference
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 Tender or lot reference
1 SG1 O 1 SG 1 - Invoiced object identifier
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 Trigger segment
2 GIR O 1 Invoiced object identifier
1 SG1 O 1 SG 1 - Remittance information
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 Remittance information
1 SG1 O 99999 SG 1 - PRECEDING INVOICE REFERENCE
The maximum number of SG1/RFF segments in header of an
INVOIC shall not exceed 99999.
1 RFF M 1 PRECEDING INVOICE REFERENCE
2 DTM O 1 Preceding invoice issue date
2 FTX O 1 Preceding invoice type
1 SG1 O 1 SG 1 - Mandate reference identifier
1 RFF M 1 Mandate reference identifier
1 SG1 O 1 SG 1 - Bank assigned creditor identifier
1 RFF M 1 Bank assigned creditor identifier
1 SG2 R 1 SG 2 - Seller
The maximum number of SG2/NAD segments in header of an
INVOIC shall not exceed 99.
1 NAD M 1 Seller
2 FII O 1 Seller's financial institution
2 SG3 O 1 SG 3 - Seller legal registration identifier
2 RFF M 1 Reference
2 SG3 O 1 SG 3 - Seller VAT identifier
2 RFF M 1 Sellers's reference number(s)
Level Name Status MaxOcc Content
2 SG3 O 1 SG 3 - Seller tax registration identifier
2 RFF M 1 Sellers's reference number(s)
2 SG5 O 1 SG 5 - SELLER CONTACT
2 CTA M 1 Contact information
3 COM O 1 Communication contact
3 COM O 1 Communication contact
1 SG2 O 99 SG 2 - Seller identifier
The maximum number of SG2/NAD segments in header of an
INVOIC shall not exceed 99.
1 NAD M 1 Seller identifier
1 SG2 O 1 SG 2 - Seller electronic address
The maximum number of SG2/NAD segments in header of an
INVOIC shall not exceed 99.
1 NAD M 1 Seller electronic address
1 SG2 R 1 SG 2 - Buyer
The maximum number of SG2/NAD segments in header of an
INVOIC shall not exceed 99.
1 NAD M 1 Buyer
2 FII O 1 Debited account identifier
2 SG3 O 1 SG 3 - Buyer reference
2 RFF M 1 Buyer reference
2 SG3 O 1 SG 3 - Buyer accounting reference
2 RFF M 1 Buyer accounting reference
2 SG3 O 1 SG 3 - Buyer legal registration identifier
2 RFF M 1 Buyer legal registration identifier
2 SG3 O 1 SG 3 - Buyer VAT identifier
2 RFF M 1 Buyer VAT identifier
2 SG5 O 1 SG 5 - Buyer's purchase contact
2 CTA M 1 Buyer's purchase contact
3 COM O 1 Buyer contact telephone number
3 COM O 1 Buyer contact email address
1 SG2 O 1 SG 2 - Buyer electronic address
The maximum number of SG2/NAD segments in header of an
INVOIC shall not exceed 99.
1 NAD M 1 Buyer electronic address
1 SG2 O 1 SG 2 - Payee
The maximum number of SG2/NAD segments in header of an
INVOIC shall not exceed 99.
1 NAD M 1 Payee
2 SG3 O 1 SG3 - Payee legal registration identifier
2 RFF M 1 Payee's reference number(s)
Level Name Status MaxOcc Content
1 SG2 O 1 SG 2 - SELLER TAX REPRESENTATIVE PARTY
The maximum number of SG2/NAD segments in header of an
INVOIC shall not exceed 99.
1 NAD M 1 Tax representative
2 SG3 R 1 SG 3 - VAT registration number
2 RFF M 1 VAT registration number
1 SG2 O 1 SG 2 - DELIVERY INFORMATION
The maximum number of SG2/NAD segments in header of an
INVOIC shall not exceed 99.
1 NAD M 1 Ship-to
1 SG7 R 1 SG 7 - Invoice currency code
1 CUX M 1 Currencies
1 SG7 O 1 SG 7 - VAT accounting currency
1 CUX M 1 VAT accounting currency code
1 SG8 O 10 SG 8 - Payment terms
The maximum number of SG8/PYT segments in header of an
INVOIC shall not exceed 10.
1 PYT M 1 Payment terms
2 DTM O 1 Payment due date
2 PAI O 1 Payment means type code
2 FII O 1 PAYMENT CARD INFORMATION
1 SG8 O 10 SG 8 - Early Payment Discount
The maximum number of SG8/PYT segments in header of an
INVOIC shall not exceed 10.
1 PYT M 1 Early Payment Discount
2 DTM O 1 Discount end date
2 PCD O 1 Discount percentage
2 MOA O 1 Discount amount
1 SG8 O 10 SG 8 - Penalty terms
The maximum number of SG8/PYT segments in header of an
INVOIC shall not exceed 10.
1 PYT M 1 Penalty terms
2 DTM O 1 Late payment penalty start date
2 PCD O 1 Penalty yearly interest percentage
2 MOA O 1 Penalty amount
1 SG16 O 10 SG 16 - Document level allowances
The maximum number of SG16/ALC segments in header of an
INVOIC shall not exceed 10.
1 ALC M 1 Document level allowances
2 FTX O 1 Document level allowance VAT exemption reason and specification
2 SG19 O 1 SG 19 - Allowance - percentage
2 PCD M 1 Allowance - percentage
2 SG20 D 1 SG 20 - Allowance - base amount
Level Name Status MaxOcc Content
2 MOA M 1 Allowance - base amount
2 SG20 R 1 SG 20 - Allowance - monetary amount
2 MOA M 1 SG 20 - Allowance - monetary amount
2 SG22 R 1 SG 22 - Allowance - applicable tax rate and amount
2 TAX M 1 Allowance - applicable tax rate and amount
1 SG16 O 10 SG 16 - Document level charges
The maximum number of SG16/ALC segments in header of an
INVOIC shall not exceed 10.
1 ALC M 1 Document level charges
2 FTX O 1 Document level charge VAT exemption reason and specification
2 SG19 O 1 SG 19 - Charge - percentage
2 PCD M 1 Charge - percentage
2 SG20 O 1 SG 20 - Charge - base amount
2 MOA M 1 Charge - base amount
2 SG20 R 1 SG 20 - Charge - monetary amount
2 MOA M 1 Charge - monetary amount
2 SG22 R 1 SG 22 - Charge - applicable tax rate and amount
2 TAX M 1 Charge - applicable tax rate and amount
1 SG26 O 99 SG 26 - Additional supporting documents
1 EFI M 1 Additional supporting document
2 COM O 1 External document location
2 RFF O 1 Supporting document reference
1 SG27 R 9999999 SG 27 - INVOICE LINE
The maximum number of SG27/LIN segments in an INVOIC shall
not exceed 9999999.
1 LIN M 1 Line item
2 PIA O 1 Additional product id
The maximum number of PIA segments in a LIN group shall not
exceed 25.
The sequence of the individual IDs in C212 is free. The first C212
must however be filled. The remaining C212 are optional.
2 PIA O 1 Additional product id
The sequence of the individual IDs in C212 is free. The first C212
must however be filled. The remaining C212 are optional.
The maximum number of PIA segments in a LIN group shall not
exceed 25.
2 PIA O 1 Additional product id
The sequence of the individual IDs in C212 is free. The first C212
must however be filled. The remaining C212 are optional.
The maximum number of PIA segments in a LIN group shall not
exceed 25.
2 IMD R 1 Item description
2 MEA O 5 ITEM ATTRIBUTES
2 QTY R 1 Quantity
Level Name Status MaxOcc Content
2 ALI O 1 Additional information
2 DTM O 1 Invoice line actual delivery date
2 DTM O 1 Invoice line period start date
2 DTM O 1 End of invoicing period
2 FTX O 1 Invoiced item Exemption reason text
2 FTX O 99 Invoice line note
The maximum number of FTX segments in a LIN group shall not
exceed 99.
2 FTX O 99 Item description
The maximum number of FTX segments in a LIN group shall not
exceed 99.
2 SG28 R 1 SG 28 - Invoice line net amount
2 MOA M 1 Invoice line net amount
2 SG30 O 1 SG 30 - Calculation net price
2 PRI M 1 Price details
2 SG30 O 1 SG 30 - Calculation gross price
2 PRI M 1 Price details
2 SG31 O 1 SG 31 - Invoice line despatch advice reference
2 RFF M 1 Reference message number
2 SG31 O 1 SG 31 - Invoice line purchase order reference
2 RFF M 1 Reference message number
2 SG31 O 1 SG 31 - Invoice line sales order reference
2 RFF M 1 Reference message number
2 SG31 O 1 SG 31 - Invoice line receiving advice reference
2 RFF M 1 Reference message number
2 SG31 O 1 SG 31 - Invoice line delivery note reference
2 RFF M 1 Reference message number
2 SG31 O 1 SG 31 - Invoice line Buyer accounting reference
2 RFF M 1 Reference message number
2 SG31 O 1 SG 31 - Invoice line object identifier
2 RFF M 1 Reference
2 SG35 O 99 SG 35 - VAT or other tax rate and amount for line item
2 TAX M 1 LINE VAT INFORMATION
2 SG36 O 1 SG 36 - Ship-to party
2 NAD M 1 Ship-to party
2 SG40 O 30 SG 40 - Allowances
The maximum number of SG40/ALC segments in a LIN group shall
not exceed 30.
2 ALC M 1 Allowance/charge
3 FTX O 1 Invoice line allowance reason
3 SG42 O 1 SG 42 - Allowance - percentage
Level Name Status MaxOcc Content
3 PCD M 1 Percentage details
3 SG43 O 1 SG 43 - Allowance - monetary amount
3 MOA M 1 Allowance/charge - monetary amount
3 SG43 O 1 SG 43 - Invoice line allowance base amount
3 MOA M 1 Monetary amount
2 SG40 O 30 SG 40 - Charges
The maximum number of SG40/ALC segments in a LIN group shall
not exceed 30.
2 ALC M 1 Allowance/charge
3 FTX O 1 Free text
3 SG42 O 1 SG 42 - Allowance/charge - percentage
3 PCD M 1 Percentage details
3 SG43 O 1 SG 43 - Allowance/charge - monetary amount
The maximum number of SG43/MOA segments in a LIN group
shall not exceed 2.
3 MOA M 1 Allowance/charge - monetary amount
3 SG43 O 1 SG 43 - Invoice line allowance or charge base amount
The maximum number of SG43/MOA segments in a LIN group
shall not exceed 2.
3 MOA M 1 Monetary amount
3 SG43 O 1 SG 43 - Item price discount
The maximum number of SG43/MOA segments in a LIN group
shall not exceed 2.
3 MOA M 1 Item price discount
0 UNS M 1 Section control
1 SG52 R 1 SG 52 - Sum of Invoice line net amount
1 MOA M 1 Sum of Invoice line net amount
1 SG52 O 1 SG 52 - Sum of allowances on document level
1 MOA M 1 Sum of allowances on document level
1 SG52 O 1 SG 52 - Sum of charges on document level
1 MOA M 1 Sum of charges on document level
1 SG52 R 1 SG 52 - Invoice total amount without VAT
1 MOA M 1 Invoice total amount without VAT
1 SG52 O 1 SG 52 - Invoice total VAT amount
1 MOA M 1 Invoice total VAT amount
1 SG52 O 1 SG 52 - Invoice total VAT amount in accounting currency
1 MOA M 1 Invoice total VAT amount in accounting currency
1 SG52 R 1 SG 52 - Invoice total amount with VAT
1 MOA M 1 Invoice amount in invoicing currency
1 SG52 O 1 SG 52 - Rounding amount
1 MOA M 1 Rounding amount
Level Name Status MaxOcc Content
1 SG52 O 1 SG 52 - Paid amount
1 MOA M 1 Paid amount
1 SG52 R 1 SG 52 - Amount due for payment
1 MOA M 1 Amount due for payment
1 SG54 O 10 SG 54 - VAT BREAKDOWN
1 TAX M 1 Tax type and rate
2 MOA O 1 VAT category tax amount
2 MOA R 1 VAT category taxable amount
1 SG55 O 15 SG 55 - Charges on invoice level (e.g. delivery costs)
1 ALC M 1 Charge
2 MOA R 1 Charge amount
2 FTX O 1 Free text
1 UNT M 1 Message trailer
1 UNO O 1 Object header
1 UNP D 1 Object trailer
0 UNZ M 1 Interchange trailer
This clear hierarchical structure of a UN/EDIFACT message allows to create a path expression which
looks similar to an XPath of XML based messages. It allows the clear identification of each individual data
element with its semantic meaning in the corresponding segment or segment group. For example, the
path for the invoice issue date can be given as:
INVOIC.DTM[D_2005 = ”137”].C507.2380
The path always starts with the root message type (in this case INVOIC). Then all segments, composites
and data elements, traversed through in the hierarchy are given and separated by a point. As with XPath
filter values can be given in square brackets. The example above can be read as “Give me the Date or time
or period text defined in Data Element 2380 that is part of composite C507 in segment DTM of the INVOIC
message, where the Date or time or period function code qualifier defined in Data Element 2005 is equal
to the code 137 that defines the issue date or time.“
4.3 Codes and identifiers
In order to keep UN/EDIFACT up to date with new user semantic requirements as well as the impacts of
legislation, UN/CEFACT publishes new libraries containing updated code lists normally twice a year. The
important point is that the underlaying syntax itself (Syntax Version 4) is kept stable for many years to
reduce system modifications to a minimum. Due to the underlaying methodology to have fixed data types
(segments and data elements) that are combined with codes to define the semantic meaning structural
changes are reduced to a minimum. Thus an instance file is normally backwards compatible. In practice
many systems are implemented based on a directory version, for example D01B (second publication of
the year 2001), while the newest code lists are used if necessary (for instance for currencies, countries
or languages.)
UN/EDIFACT uses mostly code lists maintained by UN/ECE. Every code is mapped in a specific data
element. Although for some of the code lists (e.g. Currency) the code list number is defined by UN/ECE,
the codes as well as their semantic meaning are identical to the corresponding ISO code list. Due to this
situation all codes from the model can be used as defined. The codes that have the described special
situation are listed below:
Table 3 — UN/EDIFACT codes
Semantic model UN/EDIFACT UNTDID
BT-5 UNTDID 6345
BT-6 UNTDID 6345
BT-18–1 UNTDID 1153
BT-21 UNTDID 4451
In BT-157-1, EN 16931 references the semantic values of ISO 6523. All values that correspond to the
identification of an item are used in EDIFACT with UNTDID 7143.
4.4 Mapping the Invoice model
In the following table the semantic data model of EN16931 is mapped to the corresponding paths of the
UN/EDIFACT INVOIC message structure, as explained above. The cardinality of the data model is taken
into account by the corresponding validation artefacts.
The model is mapped to UN/CEFACT INVOIC D.24A S4. Although most existing implementations of
UN/EDIFACT are made using Syntax 3 (S3) or the Syntax 3 compatible profile of Syntax 4 (SX) – ISO 9735
Part 11, some specific requirements of the semantic data model necessitate using Syntax 4 (S4) for easier
and more effective implementation. As no special features of S4, for example interactive EDI, are needed
for implementing the semantic data model, the instances created using S4 will be compatible to SX with
the following differences:
— With the S4 version the service segments UNA, UNB and UNH have minor structural differences that
specifically allow the use of UTF-8 for encoding. The usage of UTF-8 encoding brings the most
possible interoperability in systems that need to implement all syntaxes from the short list. On the
other hand, S3 allows the use of many different character sets based on ISO 8859 which is a subset
of UTF-8 character set. If in cross border invoices local European languages are used the conversion
from S3 to the receiving system needs some additional effort, although this is very common practice.
— S4 also allows the direct embedding of binary data (e.g. image files or PDF-files) with the use of the
UNO and UNP segments. With S3 it is common practice to put the UN/EDIFACT instance in an XML
based Standard Business Document Header (SBDH), which is another standard from UN/ECE. This
is for example done in the automotive industry . S4 allows a One-Syntax-Only approach for this.

See https://www.vda.de/en/services/Publications/4983-recommendation-on-the-transmission-of-
attachments-and-signat.html
The implication of choosing S4 instead of SX on existing implementations of UN/EDIFACT in respect to
cost and effort are seen as minimal for the following reasons:
— The differences in the instance files of SX and S4 for the data model are minor.
— As many organizations use service providers that generate or process the instance files and
especially the service segments the implication on a user’s system by the choice of S4 are minor.
— Embedding of binary attachments is only relevant for specific business processes. If attachments are
not embedded in the invoice process, the differences are even further reduced.
— Upgrading an existing e-invoicing system to process the EN16931 for the first time will require effort
due to the new structure, the new code definitions, and the European harmonisation of business
terms, which are not common or used in every single member state.

Table 4 — Semantic model to UN/EDIFACT syntax elements mapping
ID Cardinality BT Description DT Path

BG-0 Invoice INVOIC.UNH
BT-1 1. 1 Invoice number A unique identification of the invoice. I INVOIC.BGM.C106.1004
Usage Note: The sequential number required
in Article 226(2) of the directive 2006/112/
EC [2], to uniquely identify the invoice within
the business context, 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.
BT-2 1. 1 Invoice issue The date when the invoice was issued. D INVOIC.DTM[C507\2005="137"].C507.2380
date
BT-2-1 0. 1 Date, format C INVOIC.DTM[C507\2005="137"].C507.2379

BT-166 0. 1 Invoice issue The time of the day when the invoice was INVOIC.DTM[C507\2005="137"].C507.2380
time issued.
Concatenate values of BT-2 and BT-166 with 2379 = "203"
BT-166-1 0. 1 Date, format A finite sequence of characters. C INVOIC.DTM[C507\2005="137"].C507.2379
BT-3 1. 1 Invoice type code A code specifying the functional type of the C INVOIC.BGM.C002.1001
invoice.
Usage Note: Commercial invoices and credit
notes are defined according to the entries in
UNTDID 1001 [6].
Other entries of UNTDID 1001 [6] with
specific invoices or credit notes may be used if
applicable.
The subset of UNTDID 1001 that may be used
is managed by or on behalf of CEN/TC434.
ID Cardinality BT Description DT Path
BT-5 1. 1 Invoice currency The currency in which all invoice amounts C INVOIC.SG7[CUX\C504\6347="2"].CUX.C504.6345
code are given, except for the Total VAT amount
D_6347="2" and 6343 = "4"
in VAT accounting currency.
Usage Note: Only one currency shall be used
in the Invoice, except for the Invoice total
VAT amount in VAT accounting currency
(BT-111) in accordance with article 230 of
Directive 2006/112/EC on VAT [2].
The lists of valid currencies are registered
with the ISO 4217 Maintenance Agency
“Codes for the representation of currencies

and funds”.
BT-6 0. 1 VAT accounting The currency used for VAT accounting and C INVOIC.SG7[CUX\C504\6347="3"].CUX.C504.6345
currency code reporting purposes as accepted or required
D_6347="3" and D_6343="18"
in the country of the Seller.
Usage Note: Shall be used in combination
with the Invoice total VAT amount in VAT
accounting currency (BT-111) when the VAT
accounting currency code differs from the
Invoice currency code.
The lists of valid currencies are registered
with the ISO 4217 Maintenance Agency
“Codes for the representation of currencies
and funds”. Please refer to Article 230 of the
Council Directive 2006/112/EC [2] for more
information.
BT-167 0. 1 VAT accounting The value of a VAT accounting currency U INVOIC.SG7[CUX\C504\6347="3"].CUX.5402
currency unit, expressed in invoicing currency.
exchange rate
ID Cardinality BT Description DT Path
BT-7 0. 1 Value added tax The date when the VAT becomes chargeable D INVOIC.DTM[C507\2005="131"].C507.2380
point date for the Seller and for the Buyer in so far as
that date can be determined and differs
from the date of issue of the invoice,
according to the VAT directive.
Usage Note: The tax point is usually the date
goods were supplied or services completed
(the 'basic tax point'). There are some
variations. Please refer to Article 226 (7) of
the Council Directive 2006/112/EC [2] for
more information.
This element is required if the Value added
tax point date is different from the Invoice
issue date.
Both Buyer and Seller should use the Tax
Point Date when provided by the Seller. The
use of BT-7 and BT-8 is mutually exclusive.
BT-8 0. 1 Value added tax The code of the date when the VAT becomes C INVOIC.DTM[C507\2005="3"OR C507\2005="35"OR
point date code chargeable for the Seller and for the Buyer. C507\2005="432"].C507.2005
Usage Note: The code shall distinguish

between the following entries of UNTDID
2005 [6]:
- Invoice document issue date
- Delivery date, actual
- Paid to date. The Value Added Tax point
date code is used if the Value Added Tax point
date is not known when the invoice is issued.
The use of BT-8 and BT-7 is mutually
exclusive.
BT-9 0. 1 Payment due The date when the payment is due. D INVOIC.SG8[PYT\4279="1"].DTM[C507\2005="140"].
date C507.2380
Usage Note: The payment due date reflects
the due date of the net payment. For partial
payments it states the first net due date. The
corresponding description of more complex
payment terms can be stated in BT-20
Payment terms.
ID Cardinality BT Description DT Path
BT-10 0. unbounded Buyer reference An identifier assigned by the Buyer used for I INVOIC.SG2[NAD\3035="BY"].SG3.RFF.C506.1154
internal routing purposes.
Usage Note: The identifier is defined by the
Buyer (e.g. department or office id),and
returned by the Seller in the invoice.

BT-10-0 1. 1 Content A finite sequence of characters. INVOIC.SG2[NAD\3035="BY"
...