CEN/TS 16931-3-4:2017

SLOVENSKI STANDARD
01-januar-2018
(OHNWURQVNRL]GDMDQMHUDþXQRYGHO6LQWDNVDSRYH]DYYVNODGX]81(',)$&7
,192,&'%
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: CEN/TS 16931-3-4:2017
ICS:
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-4
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
October 2017
TECHNISCHE SPEZIFIKATION
ICS 35.240.20; 35.240.63
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 Technical Specification (CEN/TS) was approved by CEN on 30 July 2017 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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2017 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16931-3-4:2017 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 . 6
4.1 Introduction . 6
4.2 Data types . 6
4.3 Codes and identifiers . 10
4.4 Mapping the Invoice model . 10
4.5 Validation artefacts . 140
5 Mismatches . 140
5.1 Semantic level . 140
5.2 Structural level . 140
5.3 Cardinality level . 140
Annex A (informative) Examples . 141
A.1 Introduction . 141
A.2 Invoice with multiple line items . 141
A.3 IT equipment . 156
A.4 Subscription . 172
A.5 Domestic payment . 176
A.6 Maximum content . 181
A.7 Minimum content . 192
A.8 Taxes . 197
A.9 Electricity . 201
A.10 Licenses. 216
Bibliography . 221

European foreword
This document (CEN/TS 16931-3-4:2017) 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 [and/or CENELEC] 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.
This document is part of a set of documents, consisting of:
— EN 16931-1:2017 Electronic invoicing - Part 1: Semantic data model of the core elements of an
electronic invoice
— CEN/TS 16931-2:2017 Electronic invoicing - Part 2: List of syntaxes that comply with EN 16931-1
— CEN/TS 16931-3-1:2017 Electronic invoicing - Part 3 - 1: Methodology for syntax bindings of the
core elements of an electronic invoice
— CEN/TS 16931-3-2:2017 Electronic invoicing - Part 3 - 2: Syntax binding for ISO/IEC 19845
(UBL 2.1) invoice and credit note
— CEN/TS 16931-3-3:2017 Electronic invoicing - Part 3 - 3: Syntax binding for UN/CEFACT XML
Cross Industry Invoice D16B
— CEN/TS 16931-3-4:2017 Electronic invoicing - Part 3 - 4: Syntax binding for UN/EDIFACT
INVOIC D16B
— CEN/TR 16931-4:2017 Electronic invoicing - Part 4: Guidelines on interoperability of electronic
invoices at the transmission level
— CEN/TR 16931-5:2017 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
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, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey 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” . 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).
In line with Directive 2014/55/EU [5], and after publication of the reference to EN 16931-1 in the
Oficial Journal of the European Union, all contracting public authorities and contracting entities in the
EU will be obliged to receive and process an e-invoice as long as:
— it is in conformance with the semantic content as described in EN 16931:1;
— it is represented in any of the syntaxes identified in CEN/TS 16931-2, in accordance with the
request referred to in paragraph 1 of article 3 of the Directive 2014/55/EU;
— it is in conformance with the appropriate mapping defined in the applicable subpart of
CEN/TS 16931-3.
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-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 CEN Technical Specification (TS) 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. Any mismatches between semantics, format, cardinality or structure are
indicated.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 9735, Electronic data interchange for administration, commerce and transport (EDIFACT) –
Application level syntax rules
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 [5]]
3.2
semantic data model
structured set of logically interrelated information elements
3.3
information element
semantic concept that can be defined independent of any particular representation in a syntax
3.4
syntax
the machine-readable language or dialect used to represent the information elements contained in an
electronic document (e.g. an electronic invoice)
3.5
business term
the label assigned to a given information element which is used as a primary reference
3.6
core invoice model
semantic data model of the Core elements of an electronic invoice
3.7
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.8
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.9
identification scheme
collection of identifiers applicable for a given type of object governed under a common set of rules
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
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

See http://www.unece.org/fileadmin/DAM/trade/untdid/texts/d423.htm
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+2:20161214: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 2016
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 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 an UN/EDIFACT message is structures 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 and XML file needs to be well-formed.
In order to have a consistend 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 an
UN/EDIFACT instance. They define for instance the used version, character sets and ensure the
consistency of the message itself.
The following table shows the basic segment structure of an UN/EDIFACT invoice message. Only those
segments are shown, that are relevant for the mapping of the EN 16931.
Table 2 — UN/EDIFACT Invoice structure
Level Name Description Cardinality Example content
Service segments for the start of the instance file
+ UNA Service string adice 1.1 Basic information on the syntax like
separators
+ UNB Interchange header 1.1 Character encoding used
Header section
+ UNH Message header 1.1 Type of message, version
Level Name Description Cardinality Example content
+ BGM Beginning of message 1.1 Type of invoice, language
+ DTM Date/time/period 1.35 Invoice issue date
+ FTX Free text 0.99 Free text applicable to the whole
message in general like Invoice note
+ SG1 Segment group 1 0.99999 References
++ RFF Reference 1.1 Previous invoice
++ DTM Date/time/period 0.5 Date of precious invoice
+ SG2 Segment group 2 0.99 Parties
++ NAD Name and address 1.1 Buyer name and address
++ FII Financial institution information 0.5 Account number
++ SG3 Segment group 3 0.9999 Party specific references
+++ RFF Reference 1.1 Buyer reference
++ SG5 Segment group 5 0.5 Contact information
+++ CTA Contact information 0.1 Contact point
+++ COM Communication contact 0.5 Telephone number
+ SG 7 Segment group 7 0.99 Currency information
++ CUX Currencies 1.1 Invoice currency
+ SG8 Segment group 8 0.10 Payment terms and conditions
++ PYT Payment terms 1.1 Payment means
++ DTM Date/time/period 0.5 Payment due date
++ PAI Payment instructions 0.1 Payment means code
+ SG16 Segment group 16 0.9999 Document allowance or charges
++ ALC Allowance or charge 1.1 Allowance
++ SG19 Segment group 19 0.1 Percentage
+++ PCD Percentage details 1.1 Allowance percentage
++ SG20 Segment group 20 0.2 Monatary amounts
+++ MOA Monetary amount 1.1 Allowance amount
++ SG22 Segment group 22 0.5 Tax information
+++ TAX Duty/tax/fee details 1.1 VAT rate
+ SG26 Segment group 26 0.99 External files
++ EFI External file link identification 1.1 File name
++ COM Communication contact 0.9 External document location
++ RFF Reference 0.9 Supporting document reference
Detail section
+ SG27 Segment group 27 0.9999999 Line item information
Level Name Description Cardinality Example content
++ LIN Line item 1.1 Invoice line identifier
++ PIA Additional product id 0.25 Item Seller’s identifier
++ IMD Item description 0.99 Item name
++ QTY Quantity 0.5 Invoiced quantity
++ ALI Additional information 0.5 Item country of origin
++ DTM Date/time/period 0.35 Invoice line period start date
++ FTX Free text 0.99 Invoice line note
++ SG28 Segment group 28 0.99 Product related monetary amounts
+++ MOA Monetary amount 1.1 Invoice line net amount
++ SG30 Segment group 30 0.25 Price information
+++ PRI Price details 1.1 Item net price
++ SG31 Segment group 31 0.10 Line item references
+++ RFF Reference 1.1 Buyer accounting reference
++ SG35 Segment group 35 0.99 Tax information
+++ TAX Duty/tax/fee details 1.1 VAT information
++ SG40 Segment group 40 0.30 Allowances and charges on line level
+++ ALC Allowance or charge 1.1 Charge indicator
+++ SG42 Segment group 42 0.1 Percentage information
++++ PCD Percentage details 1.1 Item charge percentage
+++ SG43 Segment group 43 0.2 Amount information
++++ MOA Monetary amount 1.1 Charge amount
Summary section
+ UNS Section control 1.1 Separator for summary section
+ SG52 Segment group 52 1.100 Document totals
++ MOA Monetary amount 1.1 Paid amount
+ SG54 Segment group 54 0.10 VAT breakdown
++ TAX Duty/tax/fee details 1.1 VAT rate
++ MOA Monetary amount 0.9 Tax amount
+ UNT Message trailer 1.1 End of business document
Service segments for the end of the instance file
+ SG56 Segment group 56 0.99 Attached binary information
++ UNO Object header 1.1 Start of included object
++ UNP Object trailer 1.1 End of included object
+ UNZ Interchange trailer 1.1 End of instance file
This clear hierarchical structure of an UN/EDIFACT message allows to create a path expression, that
looks similar to a XPath of XML based messages. It allows to clearly identify 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, composits
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 to new user semantic requirements as well as impacts by
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 3 or 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 they use the newest code lists
are used if needed (for instance for currencies, countries or languages.)
UN/EDIFACT uses mostly codelists 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 is 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 the 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. If the semantic codes of ISO 6523
should be used that are not intended to identify an item, it should be requested to add to UNTDID 7143.
4.4 Mapping the Invoice model
In the following table the semantic data model of the EN16931 is mapped to the corresponding paths of
the UN/EDIFACT INVOIC message structure, as explained above. The cardinality column for the
UN/EDIFACT 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.
The model is mapped to UN/CEFACT INVOIC D14B S4. Although most existing implementations of
UN/EDIFACT are made using Syntax 3 (S3), 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 S3 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 usage 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 usage 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 industry3. S4 allows a One-Syntax-Only approach for
this.
The implication of choosing S4 instead of S3 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 S3 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 users 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 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 harmonization of
business terms, which are not common or used in every single member state.

See https://www.vda.de/en/services/Publications/4983-recommendation-on-the-transmission-of-
attachments-and-signat.html
Table 4 — Semantic model to UN/EDIFACT syntax elements mapping
ID BT Desc. Path Match Rules
BT- 1 1.1 Invoice number A unique I INVOIC.BGM.C106.1004
1 identification of 1.1
the Invoice.
BT- 1 1.1 Invoice issue The date when D INVOIC.DTM[D_2005 = ”137”].C507.2380
2 date the Invoice was 1.1
issued.
BT- 1 1.1 Invoice type A code C INVOIC.BGM.C002.1001
3 code specifying the
1.1
functional type
of the Invoice.
BT- 1 1.1 Invoice currency The currency in C INVOIC.SG7[D_6347 = ”2”].CUX.C504.6345  Use UN code
5 code which all list 6345
Invoice amounts
are given,
except for the 1.1
Total VAT
amount in
accounting
currency.
BT- 1 0.1 VAT accounting The currency C INVOIC.SG7[D_6347 = ”6”].CUX.C504.6345  Use UN code
6 currency code used for VAT list 6345
accounting and
reporting
purposes as 1.1
accepted or
required in the
country of the
Seller.
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
BT- 1 0.1 Value added tax The date when D INVOIC.DTM[D_2005 = ”131”].C507.2380
7 point date the VAT
becomes
accountable for
the Seller and
for the Buyer in
so far as that
date can be
1.1
determined and
differs
from the date of
issue of the
invoice,
according to the
VAT directive.
BT- 1 0.1 Value added tax The code of the C INVOIC.DTM[D_2005 = ”3”OR D_2005 = ”35”OR
8 point date code date when the D_2005 = ”432”].C507.2005
VAT becomes
1.1
accountable for
the Seller and
for the Buyer.
BT- 1 0.1 Payment due The date when D INVOIC.SG8[D_4279 = ”1”].DTM.C507.2380
9 date the payment is 1.1
due.
BT- 1 0.1 Buyer reference An identifier T INVOIC.SG2[D_3035 = ”BY”].SG3[D_1153 = ”CR”].RFF.C506.115
10 assigned by the 4
Buyer used for 1.1
internal routing
purposes.
BT- 1 0.1 Project reference The O INVOIC.SG1[D_1153 = ”AEP”].RFF.C506.1154
1.1
11 identification of
the project the
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
invoice refers to.
BT- 1 0.1 Contract The O INVOIC.SG1[D_1153 = ”CT”].RFF.C506.1154
12 reference identification of 1.1
a contract.
BT- 1 0.1 Purchase order An identifier of O INVOIC.SG1[D_1153 = ”ON”].RFF.C506.1154
13 reference a referenced
purchase order, 1.1
issued by the
Buyer.
BT- 1 0.1 Sales order An identifier of O INVOIC.SG1[D_1153 = ”VN”].RFF.C506.1154
14 reference a referenced
sales order, 1.1
issued by the
Seller.
BT- 1 0.1 Receiving advice An identifier of O INVOIC.SG1[D_1153 = ”ALO”].RFF.C506.1154
15 reference a referenced 1.1
receiving advice.
BT- 1 0.1 Despatch advice An identifier of O INVOIC.SG1[D_1153 = ”AAK”].RFF.C506.1154
16 reference a referenced 1.1
despatch advice.
BT- 1 0.1 Tender or lot The O INVOIC.SG1[D_1153 = ”GC”].RFF.C506.1154
17 reference identification of
the call for
1.1
tender or lot the
invoice relates
to.
BT- 1 0.1 Invoiced object The I INVOIC.SG1[D_1153 = ”ATS”].GIR.C206.7402
18 identifier identification of
1.1
the call for
tender or lot the
invoice relates
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
to.
BT- 2 0.1 Scheme The S INVOIC.SG1[D_1153 = ”ATS”].RFF.C506.1153  Use UN code
18– identifier identification list 1153;
1 scheme Use ATS as
1.1
identifier of the default
Invoiced object value
identifier.
BT- 1 0.1 Buyer A textual value T INVOIC.SG2[D_3035 = ”BY”].SG3[D_1153 = ”AOU”].RFF.C506.11
19 accounting that specifies 54
reference where to book
the relevant 1.1
data into the
Buyer's financial
accounts.
BT- 1 0.1 Payment terms A textual T INVOIC.FTX[D_4451 = ”AAB”].C108.4440
20 description of
the payment
terms that apply
to the amount
due for payment 1.1
(Including
description of
possible
penalties).
BG- 1 0.n INVOICE NOTE A group of  INVOIC.FTX[D_4451 = ”GEN”]
1 business terms
providing
0.99
textual notes
that are relevant
for the invoice,
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
together with an
indication of the
note
subject.
BT- 2 0.1 Invoice note The subject of C INVOIC.FTX[D_4451 = ”GEN”].4451  Use UN code
21 subject code the following list 4451;
textual note. GEN as
1.1
default;
others as
appropriate
BT- 2 1.1 Invoice note A textual note T INVOIC.FTX[D_4451 = ”GEN”].C108.4440
22 that gives
unstructured
information that 1.1
is relevant to
the Invoice as a
whole.
BG- 1 1.1 PROCESS A group of  INVOIC.FTX[D_4451 = ”DOC”]
2 CONTROL business terms
providing
information on
1.99
the business
process and
rules applicable
to the
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
BT- 0.1 Business process Identifies the T INVOIC.FTX[D_4451 = ”DOC”].C107.4441
23 type business
process context
in which the
transaction
appears, to
enable the 1.1
Buyer to
process the
Invoice in an
appropriate
way.
BT- 2 1.1 Specification An identification I INVOIC.FTX[D_4451 = ”DOC”].C108.4440
24 identifier of the
specification
containing the
total set of rules
regarding
semantic
content,
1.1
cardinalities and
business rules
to which the
data contained
in the instance
document
conforms.
BG- 1 0.n PRECEDING A group of  INVOIC.SG1[D_1153 = ”OI”]
3 INVOICE business terms
0.99999
REFERENCE providing
information on
one or more
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
preceding
Invoices.
BT- 2 1.1 Preceding The O INVOIC.SG1[D_1153 = ”OI”].RFF.C506.1154
25 Invoice number identification of
an Invoice that
1.1
was previously
sent by the
Seller.
BT- 2 0.1 Preceding The date when D INVOIC.SG1[D_1153 = ”OI”].DTM.C507.2380
26 Invoice issue the Preceding
1.1
date Invoice was
issued.
BG- 1 1.1 SELLER A group of  INVOIC.SG2[D_3035 = ”SE”]
4 business terms
providing 1.99
information
about the Seller.
BT- 2 1.1 Seller name The full formal T INVOIC.SG2[D_3035 = ”SE”].NAD.C080.3036
27 name by which
the Seller is
registered in the
national registry
of legal entities
1.1
or as a Taxable
person or
otherwise
trades as a
person or
persons.
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
BT- 2 0.1 Seller trading A name by T INVOIC.SG2[D_3035 = ”SE”].NAD.C080.3036#2
28 name which the Seller
is known, other
than Seller 0.1
name (also
known as
Business name).
BT- 2 0.n Seller identifier An identification I INVOIC.SG2[D_3035 = ”SE”].NAD.C082.3039
1.1
29 of the Seller.
BT- 3 0.1 Seller identifier The S INVOIC.SG2[D_3035 = ”SE”].NAD.C082.1131  Use
29– identification identification ISO 6523
1 scheme scheme ICD list; e.g.
identifier identifier of the 0088 = Glob
Seller identifier. al Location
Number
0.1
(GLN);
0060 = Data
Universal
Numbering
System (D-
U-N-S)
BT- 2 0.1 Seller legal An identifier I INVOIC.SG2[D_3035 = ”SE”].SG3[D_1153 = ”GN”].RFF.C506.115
30 registration issued by an 4
identifier official registrar
that identifies 1.1
the Seller as a
legal entity or
person.
BT- 3 0.1 Seller legal The S INVOIC.SG2[D_3035 = ”SE”].SG3[D_1153 = ”GN”].RFF.C506.115
30– registration identification 3
1.1
1 identifier scheme
identification identifier of the
Seller legal
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
scheme registration
identifier identifier.
BT- 2 0.1 Seller VAT The Seller's VAT I INVOIC.SG2[D_3035 = ”SE”].SG3[D_1153 = ”VA”].RFF.C506.115
31 identifier identifier (also 4
known as Seller
1.1
VAT
identification
number).
BT- 2 0.1 Seller tax The local I INVOIC.SG2[D_3035 = ”SE”].SG3[D_1153 = ”AHP”].RFF.C506.11
32 registration identification 54
identifier (defined by the
Seller’s address)
of the Seller for
tax purposes or
a reference that 1.1
enables the
Seller to
state his
registered tax
status.
BT- 2 0.1 Seller additional Additional legal T INVOIC.FTX[D_4451 = ”REG”].C108.4440
33 legal information information
1.1
relevant for the
Seller.
BT- 2 0.1 Seller electronic Identifies the I INVOIC.SG2[D_3035 = ”SE”].SG5[D_3139 = ”IC”].COM.C076.314
34 address Seller's 8
electronic
1.1
address to
which a
business
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
document may
be delivered.
BT- 3 1.1 Seller electronic The S INVOIC.SG2[D_3035 = ”SE”].SG5[D_3139 = ”IC”].COM.C076.315 Use EM (=
34– address identification 5 Email) as
1 identification scheme default; look
1.1
scheme identifier of the at code list
Seller electronic mapping for
identifier address other values
BG- 2 1.1 SELLER POSTAL A group of  INVOIC.SG2[D_3035 = ”SE”].NAD
5 ADDRESS business terms
providing
information 1.1
about the
address of the
Seller.
BT- 3 0.1 Seller address The main T INVOIC.SG2[D_3035 = ”SE”].NAD.C059.3042
35 line 1 address line in 1.1
an address.
BT- 3 0.1 Seller address An additional T INVOIC.SG2[D_3035 = ”SE”].NAD.C059.3042#2
36 line 2 address line in
an address that
can be used to
0.1
give further
details
supplementing
the main line.
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
BT- 0.1 Seller address An additional T INVOIC.SG2[D_3035 = ”SE”].NAD.C059.3042#3
162 line 3 address line in
an address that
can be used to
0.1
give further
details
supplementing
the main line.
BT- 3 0.1 Seller city The common T INVOIC.SG2[D_3035 = ”SE”].NAD.3164
37 name of the city,
town or village,
0.1
where the Seller
address is
located.
BT- 3 0.1 Seller post code The identifier T INVOIC.SG2[D_3035 = ”SE”].NAD.3251
38 for an
addressable
group of
0.1
properties
according to the
relevant postal
service.
BT- 3 0.1 Seller country The subdivision T INVOIC.SG2[D_3035 = ”SE”].NAD.C819.3228
0.1
39 subdivision of a country.
BT- 3 1.1 Seller country A code that C INVOIC.SG2[D_3035 = ”SE”].NAD.3207 CAR-2
40 code identifies the 0.1
country.
BG- 2 0.1 SELLER A group of  INVOIC.SG2[D_3035 = ”SE”].SG5[D_3139 = ”SU”]
6 CONTACT business terms
providing
0.5
contact
information
about the
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
Seller.s
BT- 3 0.1 Seller contact A contact point T INVOIC.SG2[D_3035 = ”SE”].SG5[D_3139 = ”SU”].CTA.C056.341
41 point for a legal entity 2 1.1
or person.
BT- 3 0.1 Seller contact A phone T INVOIC.SG2[D_3035 = ”SE”].SG5[D_3139 = ”SU”].COM.C076.314
42 telephone number for the 8 1.1
number contact point.
BT- 3 0.1 Seller contact An e-mail T INVOIC.SG2[D_3035 = ”SE”].SG5[D_3139 = ”SU”].COM.C076.314
43 email address address for the 8 1.1
contact point.
BG- 1 1.1 BUYER A group of  INVOIC.SG2[D_3035 = ”BY”]
7 business terms
providing 1.99
information
about the Buyer.
BT- 2 1.1 Buyer name The full name of T INVOIC.SG2[D_3035 = ”BY”].NAD.C080.3036
1.1
44 the Buyer.
BT- 2 0.1 Buyer trading A name by T INVOIC.SG2[D_3035 = ”BY”].NAD.C080.3036#2
45 name which the Buyer
is known, other
than Buyer 0.1
name (also
known as
Business name).
BT- 2 0.1 Buyer identifier An identifier of I INVOIC.SG2[D_3035 = ”BY”].NAD.C082.3039
1.1
46 the Buyer.
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
BT- 3 0.1 Buyer identifier The S INVOIC.SG2[D_3035 = ”BY”].NAD.C082.1131  Use
46– identification identification ISO 6523
1 scheme scheme ICD list; e.g.
identifier identifier of the 0088 = Glob
Buyer identifier. al Location
Number
1.1
(GLN);
0060 = Data
Universal
Numbering
System (D-
U-N-S)
BT- 2 0.1 Buyer legal An identifier I INVOIC.SG2[D_3035 = ”BY”].SG3[D_1153 = ”GN”].RFF.C506.115
47 registration issued by an 4
identifier official registrar
that identifies 1.1
the Buyer as a
legal entity or
person.
BT- 3 0.1 Buyer legal The S INVOIC.SG2[D_3035 = ”BY”].SG3[D_1153 = ”GN”].RFF.C506.115
47– registration identification 3
1 identifier scheme
identification identifier of the 1.1
Buyer legal
scheme registration
identifier identifier.
BT- 2 0.1 Buyer VAT The Buyer's VAT I INVOIC.SG2[D_3035 = ”BY”].SG3[D_1153 = ”VA”].RFF.C506.115
48 identifier identifier (also 4
known as Buyer
1.1
VAT
identification
number).
Level
Card.
DT
Card.
ID BT Desc. Path Match Rules
BT- 2 0.1 Buyer electronic Identifies the I INVOIC.SG2[D_3035 = ”BY”].SG5[D_3139 = ”IC”].COM.C076.314
49 address Buyer's 8
electronic
address to
which a 1.1
business
document
should be
delivered.
BT- 3 1.1 Buyer electronic The S INVOIC.SG2[D_3035 = ”BY”].SG5[D_3139 = ”IC”].COM.C076.315 Use EM (=
49– address identification 5 Email) as
1 identification scheme default; look
1.1
scheme identifier of the at code li
...