CEN/TS 16931-3-4:2020

SLOVENSKI STANDARD
01-julij-2020
Nadomešča:
SIST-TS CEN/TS 16931-3-4:2018
Elektronsko izdajanje računov - 3-4. del: Povezava sintakse 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: CEN/TS 16931-3-4:2020
ICS:
03.100.20 Trgovina. Komercialna Trade. Commercial function.
dejavnost. Trženje Marketing
35.240.63 Uporabniške rešitve IT v IT applications in trade
trgovini
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TS 16931-3-4
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
April 2020
TECHNISCHE SPEZIFIKATION
ICS 35.240.20; 35.240.60 Supersedes CEN/TS 16931-3-4:2017
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 22 December 2019 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

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

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Syntax binding to UN/EDIFACT . 7
4.1 Introduction . 7
4.2 Data types . 8
4.3 Codes and identifiers .11
4.4 Mapping the Invoice model .12
4.5 Validation artefacts . 129
5 Mismatches . 129
5.1 Semantic level . 129
5.2 Structural level . 129
5.3 Cardinality level . 129
Annex A (normative) Code lists . 130
A.1 Introduction . 130
A.2 Code lists . 130
A.2.1 ISO 3166-1 — Country Codes . 130
A.2.2 ISO 4217 — Currency codes . 130
A.2.3 ISO/IEC 6523 — Identifier scheme code . 131
A.2.4 UNTDID 1001 — Document type . 132
A.2.5 UNTDID 1153 — Reference code qualifier . 133
A.2.6 VAT Identifier . 134
A.2.7 VAT Category code . 134
A.2.8 UNTDID 2005/ UNTDID 2475 — Event time code . 135
A.2.9 UNTDID 4451 — Text subject qualifier . 135
A.2.10 UNTDID 4461 — Payment means . 136
A.2.11 UNTDID 5305 — Duty or tax or fee category . 136
A.2.12 UNTDID 5189 — Allowance codes . 137
A.2.13 UNTDID 7143 — Item type identification code . 138
A.2.14 UNTDID 7161 — Charge codes . 138
A.2.15 Mime type codes — Mime codes . 138
A.2.16 CEF EAS — Electronic address scheme identifier . 139
A.2.17 CEF VATEX — VAT exemption reason code . 139
A.2.18 UN/ECE Recommendation N°20 and UN/ECE Recommendation N°21 — Unit
codes . 140
A.3 International registration authority for ISO/IEC 6523 . 140
A.4 UN/Cefact: new code request / code change request . 148
Annex B (informative) Examples . 152
B.1 Introduction . 152
B.2 Invoice with multiple line items . 152
B.3 IT equipment . 167
B.4 Subscription. 182
B.5 Domestic payment . 186
B.6 Maximum content . 191
B.7 Minimum content . 202
B.8 Taxes . 206
B.9 Electricity . 210
B.10 Licenses . 221
Bibliography . 225

European foreword
This document (CEN/TS 16931-3-4:2020) has been prepared by Technical Committee CEN/TC 434
“Electronic invoicing”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes CEN/TS 16931-3-4:2017.
The only change compared to the previous edition is the addition of a new annex, Annex A. This Annex
defines the code lists to be used.
This document is part of a set of documents, consisting of:
— EN 16931-1:2017+A1:2019, 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:2020, Electronic invoicing - Part 3 - 2: Syntax binding for ISO/IEC 19845 (UBL 2.1)
invoice and credit note
— CEN/TS 16931-3-3:2020, Electronic invoicing - Part 3 - 3: Syntax binding for UN/CEFACT XML Cross
Industry Invoice D16B
— CEN/TS 16931-3-4:2020, 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, 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, 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 Official
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 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
See https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0712:FIN:en:PDF.
1 Scope
This documents specifies the mapping between the semantic model of an electronic invoice, included in
EN 16931-1 and the ISO 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 are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 9735 (all parts), Electronic data interchange for administration, commerce and transport (EDIFACT) –
Application level syntax rules
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.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp/ui
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
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
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

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