SIST EN 16931-8:2025

SLOVENSKI STANDARD
01-februar-2025
Elektronsko izdajanje računov - 8. del: Semantični podatkovni model elementov e-
potrdila ali poenostavljenega elektronskega računa
Electronic invoicing - Part 8: Semantic data model of the elements of an e-receipt or a
simplified electronic invoice
Elektronische Rechnungsstellung - Teil 8: Semantisches Modell vereinfachter
Rechnungen und elektronischer Belege
Facturation électronique - Partie 8 : Modèle sémantique de données des éléments d'un
reçu électronique ou d'une facture électronique simplifiée
Ta slovenski standard je istoveten z: CEN/TS 16931-8:2024
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-8
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
October 2024
TECHNISCHE SPEZIFIKATION
ICS 35.240.20; 35.240.63
English Version
Electronic invoicing - Part 8: Semantic data model of the
elements of an e-receipt or a simplified electronic invoice
Facturation électronique - Partie 8 : Modèle Elektronische Rechnungsstellung - Teil 8:
sémantique de données des éléments d'un reçu Semantisches Modell vereinfachter Rechnungen und
électronique ou d'une facture électronique simplifiée elektronischer Belege
This Technical Specification (CEN/TS) was approved by CEN on 23 September 2024 for provisional application.

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

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

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

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16931-8:2024 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 The concept of an e-receipt . 8
4.1 Introduction. 8
4.2 Contents of the e-receipt model . 8
4.3 How to use the e-receipt model . 9
4.4 Compliance . 9
5 Use cases and functionality supported by the e-receipt .10
5.1 Introduction.10
5.2 U1: B2C and G2C e-receipts .10
5.3 U2: Online shop e-receipts .12
5.4 U3: e-Receipt is used to claim expenses .13
5.5 U4: e-receipt is used for returns, guarantee and refund .15
5.6 U5: Simplified invoice for B2B transactions .16
6 The semantic data model of the elements of an e-receipt .17
6.1 General .17
6.2 Legend .20
6.3 The semantic model .22
6.4 Business rules .47
6.5 Semantic data types .51
6.6 Rounding .54
6.7 Calculation.55
6.8 Cash withdrawal .57
Annex A (informative) Examples .58
A.1 Household items .58
A.2 Returns .60
A.3 Dental care .62
A.4 Clothing .66
A.5 Taxi .69
A.6 Groceries .72
A.7 Concert(1) .77
A.8 Concert (2) .79
A.9 Restaurant .81
A.10 Train ticket.84
A.11 Hotel .90
A.12 Pharmaceuticals (1).93
A.13 Pharmaceuticals (2).97
A.14 Simplified invoice . 102
Annex B (informative) BPMN symbols . 105
Bibliography . 106

European foreword
This document (CEN/TS 16931-8:2024) 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 is part of a series of documents, consisting of the following parts:
— 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 2.1)
invoice and credit note
— CEN/TS 16931-3-3, Electronic invoicing - Part 3-3: Syntax binding for UN/CEFACT XML Cross
Industry Invoice D16B
— CEN/TS 16931-3-4, Electronic invoicing - Part 3-4: Syntax binding for UN/EDIFACT
INVOIC D16B
— CEN/TR 16931-4, Electronic invoicing - Part 4: Guidelines on interoperability of electronic
invoices at the transmission level
— CEN/TR 16931-5, Electronic invoicing - Part 5: Guidelines on the use of sector or country
extensions in conjunction with EN 16931-1, methodology to be applied in the real environment
— CEN/TR 16931-6, Electronic invoicing - Part 6: Result of the test of EN 16931-1 with respect to
its practical application for an end user - Testing methodology
— CEN/TS 16931-7, Electronic invoicing - Part 7: Methodology for the development and use of
EN 16931-1 compliant structured Core Invoice Usage Specifications
— CEN/TS 16931-8, Electronic invoicing - Part 8: Semantic data model of the elements of an e-
receipt or a simplified electronic invoice (this document)
Any feedback and questions on this document should be directed to the users’ national standards
body. A complete listing of these bodies can be found on the CEN website.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece,
Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain,
Sweden, Switzerland, Türkiye and the United Kingdom.
Introduction
What separates a receipt document from an invoice document is basically the dynamics of the
usage. An invoice is mainly issued to achieve a payment for delivered goods and services and a
receipt is issued to document the payment for the purchase of goods and services. In addition, the
invoices always contain information about the buyer, whereas the receipt only needs that in
certain cases and is for the most part issued without a buyer identification.
These conditions are regulated differently by laws and practice in different countries, and this has
been taken into consideration.
This document complies at least with the following criteria:
— it is technologically neutral;
— it is compatible with relevant international standards on electronic invoicing;
— it is consistent with the relevant provisions of Directive 2006/112/EC (the “VAT directive”);
— it allows for the establishment of practical, user-friendly, flexible and cost-efficient electronic
invoicing and cash register systems;
— it takes into account the special needs of small and medium-sized enterprises as well as of
sub-central contracting authorities and contracting entities;
— it is suitable for use in commercial transactions between enterprises and between enterprises
and consumers.
NOTE Attention is drawn to the requirements for the protection of personal data of Regulation (EU)
2016/679, having due regard to the principles of privacy and data protection by-design, data minimization,
purpose limitation, necessity and proportionality.
1 Scope
This document establishes a semantic data model of an e-receipt or a simplified electronic invoice.
NOTE In the remainder of this document, when “e-receipt” is mentioned, “simplified invoice” is also
meant.
The semantic model includes essential information elements that an electronic receipt needs to
ensure legal (including fiscal) compliance and to enable interoperability for cross-border, cross
sector and domestic trade. The semantic model can be used by organizations in the private and
the public sector for documenting by issuing a receipt for the purchase of services and /or goods.
It can also be used for documenting a purchase between private sector enterprises. In addition, it
has been designed for the use of consumers.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
EN ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1:
Country code (ISO 3166-1)
ISO 4217, Codes for the representation of currencies
ISO 8601-1:2019, Date and time — Representations for information interchange — Part 1: Basic
rules
ISO 15000-5:2014, Electronic Business Extensible Markup Language (ebXML) — Part 5: Core
Components Specification (CCS)
ISO/IEC 6523 (all parts), Information technology — Structure for the identification of organizations
and organization parts
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 https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
NOTE Business terms that are part of the semantic model are defined in the model itself.
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]
3.2
simplified invoice
invoice with a total amount below a certain threshold that may contain less data elements than a
normal invoice
[SOURCE: Directive 2006/112/EC]
3.3
electronic receipt
receipt that has been issued in a structured electronic format which allows for its automatic and
electronic processing also to be transmitted and received by the customer if the customer so
decides
3.4
semantic data model
structured set of logically interrelated information elements
3.5
information element
semantic concept that can be defined independent of any particular representation in a syntax
3.6
structured information element
information element that can be processed automatically
3.7
syntax
machine-readable language or dialect used to represent the information elements contained in an
electronic document (e.g. an electronic receipt)
3.8
business term
label assigned to a given information element which is used as a primary reference
3.9
receipt model
semantic data model of the elements of an electronic receipt
3.10
elements of an e-receipt
set of essential information elements that an electronic receipt may contain in order to enable
domestic and cross-border interoperability, including the necessary information to ensure legal
compliance
3.11
identifier
character string used to establish the identity of, and distinguish uniquely, one instance of an
object within an identification scheme from all other objects within the same scheme
Note 1 to entry: An identifier may be a word, number, letter, symbol, or any combination of those,
depending on the identification scheme used.
3.12
identification scheme
collection of identifiers applicable for a given type of object governed under a common set of rules
3.13
POS
cash register, or cash register system that allows communication between different components
and systems
Note 1 to entry: A POS system is designed to facilitate user-friendly administration of sales for employees.
The system also helps with the management of a business.
3.14
compliant
some or all features of the e-receipt model are used and all rules of the e model are respected
Note 1 to entry: Based on TOGAF definition of a compliant specification.
3.15
conformant
all rules of the e-receipt model are respected and some additional features not defined in the
model are also used
Note 1 to entry: Based on TOGAF definition of a conformant specification.
4 The concept of an e-receipt
4.1 Introduction
A receipt is a proof that payment was affected both for the seller and the customer. For the buyer
the receipt is an instrument mainly for consumer protection, guaranteeing that the purchase was
legitimate and correct, but in the case the buyer is a taxable business entity the receipt may also
serve the buyer as verification in bookkeeping and for deduction of VAT upon fulfilment of the
respective legal requirements.
It should be noted that the legislation on receipts in the EU member states has national scope – the
only exception is the EU VAT Directive (directive 2006/112/EC) that has been transposed into
national law.
In many countries retail businesses are required to use certified cash registers or point of sales
systems (POS) to produce receipts for each transaction, and to record and preserve the sales data
for audit. The purpose is to better tax compliance and set the stage for fair competition. The
requirements set for the content of the receipt, and the sales data to be preserved, have strong
seller emphasis, linking also to the seller’s obligations for bookkeeping and VAT declaration.
The VAT directive recognizes invoice and simplified invoice as valid forms of transaction. This
means that, to the extent a receipt is to substantiate reporting of VAT, it shall satisfy the
requirements as either invoice or simplified invoice. But, again, while the invoice is implemented
consistently across the member states, the implementation of the simplified invoice may be
adapted to national practice.
Consequently, under current legal regimes the receipt has mainly domestic reach; if one wants to
do transactions internationally in many cases one needs to use the invoice.
4.2 Contents of the e-receipt model
Semantic building blocks for the e-receipt have been chosen, when applicable, from EN 16931 or
from simplified invoice requirements (https://ec.europa.eu/taxation_customs/business/vat/eu-
vat-rules-topic/vat-invoicing-rules_en). The EU’s Digital Single Market aims to overcome
challenges by creating the right environment for digital networks and services to flourish.
This is not only achieved by setting the right regulatory conditions, but also by providing cross-
border digital infrastructures and services.
To achieve these in the e-receipt standardization, required elements for e-receipt are chosen so
that already existing national receipt solutions could find needed elements from the e-receipt
standard and optional requirements support functionality that may vary depending on national
interests, needs and legislation allowing future developments.
Semantic building blocks for required and optional elements have been described in Clause 5
introducing some examples of use cases.
In cases where new optional semantic elements were introduced or arise during handling of
comments after enquiry from national standardization bodies, work needs to be done during the
standardization process to add and introduce those into existing references e.g. to UBL or
UN/CEFACT CII.
Caveat: The content of the semantic model has been drafted to satisfy a wide range of stakeholder
needs and application/industry areas. Only a limited set of legislations was considered but the
ambition has been to designate a framework standard that can accommodate for the various
legislations in Europe. However, it cannot be guaranteed that various regulations (for tax
compliance, VAT reporting, bookkeeping, and more) recognize the concept of receipt. As can be
concluded from 4.1, implementation has to be done on a national level and, furthermore,
implementers need to verify that the selected transaction format supports the relevant
regulations.
4.3 How to use the e-receipt model
This document lists business terms (information elements) and business term groups that may be
included in an e-receipt or electronic simplified invoice. An e-receipt is transmitted between a
sending and a receiving application. Sending applications may take any subset of the set of
business terms listed in this document, provided it respects the stated cardinality
(mandatory/conditional status and minimum/maximum repetition) and the business rules that
apply to the business terms used. Receiving applications shall be able to receive all business terms
listed, but may interpret and process only the information elements they need for their purpose.
No prior agreement between sending and receiving applications is needed. Sending applications
obviously should advertise to their users for what purposes the e-receipt transmitted is fit, e.g. by
identifying the type of document it is.
Different countries have varying legislation on the content and conditions of e-receipts. In some
countries, businesses may deduct the VAT that is specified on e-receipts, in other not. Some
countries have specific legislation on the content of e-receipts. It is the responsibility of the e-
receipt sender to adhere to the legislation that applies. This document does not list business rules
that check such legal compliance. The purpose of the business rules that are listed is to ensure
proper calculation of totals etc.
4.4 Compliance
4.4.1 Compliance of sending or receiving party
A receiving party may only claim compliance to the e-receipt model if it can accept all documents
that comply with the model. It nevertheless only needs to understand and process the information
elements that it needs for its purposes.
A sending party may claim compliance if it sends documents that comply with the e-receipt model.
4.4.2 Compliance of a receipt document instance
An e-receipt document instance is compliant to the model if it respects all rules and cardinalities
defined for the e-receipt model.
5 Use cases and functionality supported by the e-receipt
5.1 Introduction
This subclause describes processes that are supported by the e-receipt model. How the receipts
are electronically exchanged is not described in the process models. Parties may handle document
exchange with their own resources or outsource (part of) it. See also CEN/TR 16931-4.
The processes described here are examples. The set of processes is not exhaustive. The process
models included in this subclause are intended to indicate the business contexts that are
supported by the e-receipt model. The models do not give a full definition of those processes.
The process models focus on the external activities of the parties and do not describe internal
activities.
The process model diagrams are presented in the Business Process Model and Notation (BPMN)
of the Object Management Group (OMG). A short legend of the symbols used can be found in
Annex B.
The following processes are supported by the e-receipt model:
• U1: B2C and G2C e-receipts,
• U2: Online shop e-receipt,
• U3: e-Receipt is used to claim expenses,
• U4: e-receipt is used for returns, guarantee and refund,
• U5: Simplified invoice for B2B transactions.
5.2 U1: B2C and G2C e-receipts
5.2.1 Introduction
The most common case for an e-receipt is when a consumer purchases goods or services, pays
and receives the receipt as proof of purchase and payment.
5.2.2 Short description
The receipt is a result of a purchase process carried out by a Consumer. The receipt is issued by a
cash register (ECR/POS) or with a ticket or vending machine, after the payment has been made.
There exist different options how the document is sent to the buyer.
• The document can be transferred to the buyer’s mobile device by means of a wireless protocol
(e.g. NFC, Bluetooth);
• The document (or a link to the document) can be represented in a barcode (e.g. a QR-code)
which is scanned by the buyer;
• The buyer may use a service provider (e.g. a bank or an application provider) to receive the
e-receipts, so that the buyer may represent a secondary address, as the service provider is the
primary address (applicable in a “four corner” network);
• The buyer may provide their electronic address and the receipt is sent to that address,
possibly by means of one or more service providers;
• The buyer may use an app to receive the receipt. That app may contain another address for
sending the receipt further e.g. to a bookkeeping system.
The cash register and the payment terminal may not be connected with each other. In that case
either the e-receipt may not contain payment authorization information or the buyer’s application
gets the payment information through another channel from the payment terminal. It is also
possible that the e-receipt is completed (manually) with payment authorization information by
the seller or the buyer.
The buyer may use the receipt information to get an overview of their spending and to reconcile
the spending with the payment record (credit or debit card slip / bank statement).
The Seller uses the information on the e-receipt for his bookkeeping and VAT administration. In
some countries the cash registers may directly be connected to the system of the tax authorities.
A copy of the e-receipt as provided to the customer may then be sent to the tax system as proof of
the tax declaration to support sellers’ and buyers’ automated electronical VAT-filing.
5.2.3 Process or workflow description

Figure 1
1. The Buyer purchases goods and/or services from the Seller.
2. If necessary, the Buyer provides additional information to the Seller (e.g. ID number).
3. The Seller calculates the total amount of the purchase.
4. The Buyer selects a payment method from the options offered by the Seller.
5. The Buyer pays or initiates the payment (cash, voucher or with electronic means).
6. The Seller generates the e-receipt with their cash register and sends it to the Buyer.
7. The Buyer imports the e-receipt in their application or in the system of a service provider.
5.2.4 Variants
Many payment options exist that may be offered to the Buyer. Some options need specific
information that is included in the receipt. Options include cash, vouchers and electronic
payments of several kinds. Parts of the amounts may be paid with different means. In some cases,
a cash withdrawal may be part of the transaction. In other cases, a tip may be given that increases
the calculated amount.
In some cases (e.g. in restaurants) first a pro-forma receipt is issued and after payment the final
receipt is generated.
In some environments specific (product) information needs to be included in the receipt:
— For selected product categories sold in Europe a Digital Product Passport is required. A DPP
identifier enables linking to the verified product information, adding transparency of the full
life cycle of a product. The passport will tell how sustainably materials are sourced, what are
the social and environmental impacts of used materials, production, use and end of life;
— When purchasing food, Best Before dates, lot numbers, a list of ingredients, information about
the source, quality labels, nutrition value and allergy issues may need to be given;
— With textile products, the composition, washing instructions and a non-child labour
statement may be needed;
— With electronics, serial numbers, warrantee information and safety instruction may need to
be included;
— With cultural events or facilities and means of transport, a unique token may need to be
included together with rang and seat information;
— With pharmaceuticals or medical services, the receipt may need to include information
identifying the patient, the prescriber and the treatment, in order for the patient to reimburse
the expense. Each country has different legislation with regards to financing or refunding
pharmacy and health care services. In some cases, the State or an insurance company directly
pays the health care provider, in other cases the buyer needs to pay and may later get
refunded. In both cases the buyer may be entitled to receive a receipt. Usually the patient
(who can be different from the buyer) is identified on the receipt, as is the doctor who
prescribed the pharmaceutical or treatment.
5.3 U2: Online shop e-receipts
5.3.1 Introduction
In online sales to consumers the receipt is by definition electronic.
5.3.2 Short description
Usually, after having ordered the goods or services and having initiated the payment, the buyer
receives the e-receipt as a download on the web page or in their mailbox, possibly together with
a PDF representation. The e-receipt is provided to the buyer after ordering, in some cases after
delivery.
The purpose of the e-receipt for the Seller is to provide the required information related to the
purchase to fulfil the obligations set by the law and ensure that the customer has a good customer
experience so as to minimize customer service costs. The purpose for the buyer is to receive the
information to their selected service in a structured format to further utilize the receipt and enable
sharing this information. The receipt documents the rights or at least the ownership of a specific
product or service (e.g. a concert ticket) with the reference to the seller’s legal identity,
obligations, etc.
The seller may be registered in accordance with VAT legislation. If applicable, the seller collects
and pays the VAT to the tax authorities where the customer is living. In case the customer is a
company, the VAT amount may be deducted/refunded according to local rules and regulations.
5.3.3 Process or workflow description

Figure 2
1. The buyer finalizes their shopping basket.
2. The buyer initiates the payment.
3. The seller sends the e-receipt to the buyer or makes it available.
5.4 U3: e-Receipt is used to claim expenses
5.4.1 Introduction
Employees frequently travel or do purchases that they may reimburse to their employer. The e-
receipt streamlines this process. Instead of re-keying information from hard-to-read sales slips,
the employee sends the e-receipt as received from the seller to the application of the employer.
5.4.2 Short description
The buyer makes a purchase according to U1 or U2. The buyer then uses the receipt information
to claim expenses with their employer, an insurance company or any other third party. There are
systems that support the process connected with these claims for registering, approval routing
and accounting. Today this process is manual to a large degree. With e-receipts, these processes
can to a large degree be automated, just by entering the receipt in a structured format that will
ease the identification of the type of expense, and thereby the form and extent of documentation
needed for that specific expense type, which in turn will decide the coding and the approval
workflow.
The employee sends the e-receipt as received from the seller to the application of the employer.
The employer refunds the employee. In some countries the employer may use the e-receipt
information for VAT or income tax deduction.
5.4.3 Process or workflow description

Figure 3
1. POS creates a digital receipt (see U1 or U2).
2. Buyer uploads the e-receipt to the Financial Management System of the employer.
3. The buyer might need to add some information like reason, description and ask for approval.
4. Someone approves the expense.
5. Approved expense is sent to company accounting system.
6. Buyer is reimbursed.
NOTE If the company uses the receipt information for deduction of VAT, the company is the legal buyer.
5.4.4 Variants
Several types of expenses need specific information to be included in the receipt. With hotel
expenses, e.g. the dates of the stay are needed. With restaurant bills, a distinction needs to be made
between food and drinks. Taxi rides need the from and to locations.
5.5 U4: e-receipt is used for returns, guarantee and refund
5.5.1 Introduction
In general, the receipt is documenting a purchase and the person having the item and the receipt,
has the right to claim a return, a fault or damage to get a repair or refund in some way. The receipt
can contain such information, and part of the intention with the e-receipt is that this information
shall be presented in the e-receipt whenever it is relevant.
This is also applicable for receipt for online purchases.
5.5.2 Short description
The e-receipt as received from the seller may be used a proof of purchase when returning the
goods or claiming guarantee. It may also serve as a voucher in case of refunds.
Faults with a purchase, whether is on delivery or it arises later within the period of warranty the
purchase may be returned or be repaired. The receipt is used to document the purchase. The use
of e-receipt is simpler and identifies the contractual part / the agreement of the purchase in a
better way than an old faulty paper-based receipt.
The e-receipt makes it easier to handle any claim and makes it even more obvious for the parties
that the receipt in fact is a contract connected to a business transaction.
Buyers always have the receipt with them, e.g. in a mobile app, so return is easier for all parties
because the receipt is not missing or in bad condition (ink faded).
5.5.3 Process or workflow description

Figure 4
The buyer or owner presents the fault together with the receipt to the seller to prove the
ownership and to correct the error according to the agreement and applicable law.
5.6 U5: Simplified invoice for B2B transactions
5.6.1 Introduction
In some cases of business to business trade, simplified invoices may be used instead of normal
invoices. Simplified invoices do not need all information elements that are required for regular
invoices. The data content of an e-receipt may suffice.
5.6.2 Short description
Buyer use receipt information for VAT or other administrative reporting or update own inventory
accounting.
5.6.3 Process or workflow description

Figure 5
6 The semantic data model of the elements of an e-receipt
6.1 General
This Clause 6 describes the information elements, and groups of information elements, that
constitutes the semantic data model of the elements of an e-receipt, as well as their relationship
and the business rules required to ensure the integrity and consistency in the data provided in a
compliant instance document (an individual e-receipt).
For an instance document to be compliant to the e-receipt model, it shall respect all rules defined
in this Clause 6.
It is the responsibility of the e-receipt issuer to ensure that an e-receipt respects any rules defined
by relevant legislation, including requirements related to personal data protection, as well as rules
stated as part of a trading relationship between the Seller and the Buyer. An e-receipt conforming
to the rules of the semantic data model of the elements of an e-receipt as described in this Clause 6
does not guarantee its legal compliance OR compliance to contractual obligations.
An overview of the groups of information elements contained in the semantic model is provided
in Figure 6. Each of these groups and their detailed content is explained in detail in 6.3.
The business rules defined in order to ensure the integrity and consistency in the data provided
in a compliant instance document can be found in 6.4.
The semantic data type assigned to individual information elements in the e-receipt model to
specify data format and metadata requirements that apply are detailed in 6.5.

Figure 6 — Overview of the semantic model
Figure 7 — The semantic model
6.2 Legend
Each information element, as well as groups of information elements, that constitutes the
semantic data model of the elements of an e-receipt is described as a row in the table documented
in 6.3 where the following information is provided:
Cardi Business Semantic
ID Level Description Usage Note
nality Term data type
ID: An identifier for the information element (BT - Business Term) and group of information
elements (BG - Business terms Group). The identifiers are not necessarily consecutive or in
sequence.
Level: Indicates on which level in the model the information element occurs:
— +: The first level of the model;
— ++: The second level of the model. The information element (or the group of information
elements) is part of a group of information elements which is defined at the first level of the
model;
— +++: The third level of the model. The information element (or the group of information
elements) is part of a group of information elements which is defined at the second level of
the model;
— ++++: The fourth level of the model. The information element is part of a group of information
elements which is defined at the third level of the model.
Cardinality: Also known as multiplicity is used to indicate if an information element (or group of
information elements) is mandatory or conditional, and if it is repeatable. The cardinality shall
always be analysed in the context of where the information element is used. Example: the Payee
Name is mandatory in the e-receipt model, but only when a Payee is stated and is relevant.
The following cardinalities exist:
— 1.1: Mandatory, minimum 1 occurrence and maximum 1 occurrence of the information
element (or group of information elements) shall be present in any compliant instance
document;
— 1.n: Mandatory and repeatable, minimum 1 occurrence and unbounded upper maximum
occurrences of the information element (or group of information elements) shall be present
in any compliant instance document;
— 0.1: Conditional, minimum 0 occurrences and maximum 1 occurrence of the information
element (or group of information elements) may be present in any compliant instance
document; it's use depends on business rules stated as well as the regulatory, commercial and
contractual conditions that applies to the business transaction;
— 0.n: Conditional and repeatable, minimum 0 occurrences and unbounded upper maximum
occurrences of the information element (or group of information elements) may be present
in any compliant instance document; it's use depends on business rules stated as well as the
regulatory, commercial and contractual conditions that applies to the business transaction.
Business Term: The name of the information element used in the e-receipt model or the name of
a coherent group of related information elements, provided to give logical meaning.
Description: A description of the semantic meaning of the information element.
Usage Note: Clarifying information on how the information element shall or may be used (such as
calculation rules).
Semantic data type: The data format that applies to the information element (see 6.5).
Supplementary components or attributes are specified with the Business Term they belong to.
Note that in the naming of business terms, in descriptions and in usage notes, the term “invoice”
also applies to Credit notes, unless mentioned otherwise.
6.3 The semantic model
Table 1 — Semantic data model of the e-receipt / simplified invoice
Business Semantic
ID Level Cardinality Description Usage Note
Term data type
Receipt
BT-1 + 1.1 A unique identification of the receipt. Sequential number Identifier
number
Receipt issue
BT-2 + 1.1 The date when the Receipt was issued  Date
date
Start of
BT-256 + 0.1 The time the sales transaction started  Time
transaction
BT-201 + 0.1 Time of sale Exact time when the transaction completed Time of 24-h day Time
Operation
BT-202 + 0.1 Business transaction type  Code
type
Receipt type A code specifying the functional type of the
BT-3 + 1.1  Code
code Receipt
Receipt The currency in which all Receipt
BT-5 + 1.1 currency The currency of the amounts in the receipt amounts are given shall be Code
code according to ISO 4217
Receipt VAT
Indication whether the calculations in the
BT-259 + 1.1 incl/excl See subclause 6.7 Indicator
receipt are inclusive or exclusive of VAT
indicator
Reference to
Reference to the sales document related to
BT-204 + 0.1 sales  Reference
eReceipt
document
RECEIPT an object on which the receipt is based,
BG-33 + 0.n
OBJECT given by the Seller
The suffix ".Type" has been deleted for readability.
Business Semantic
ID Level Cardinality Description Usage Note
Term data type
It may be a subscription number,
Receipt
An identifier for an object on which the telephone number, patient,
BT-18 ++ 0.1 object Identifier
receipt is based. meter point, vehicle, person etc.,
identifier
as applicable.
...