prEN 16931-8
(Main)Electronic invoicing - Part 8: Semantic data model of the elements of an e-receipt or a simplified electronic invoice
Electronic invoicing - Part 8: Semantic data model of the elements of an e-receipt or a simplified electronic invoice
This document:
• describes the content of electronic simplified invoices and e-receipts
• describes business processes in which simplified invoices and e-receipts are exchanged
Elektronische Rechnungsstellung - Teil 8: Semantisches Modell vereinfachter Rechnungen und elektronischer Belege
Dieses Dokument führt ein semantisches Datenmodell eines elektronischen Belegs oder einer vereinfachten elektronischen Rechnung ein. Wenn im weiteren Verlauf dieses Dokuments von einem "elektronischen Beleg" die Rede ist, schließt dies auch die "vereinfachte Rechnung" mit ein. Das semantische Modell umfasst wesentliche Informationselemente, die ein elektronischer Beleg enthalten muss, um die Einhaltung rechtlicher (einschließlich steuerrechtlicher) Vorschriften sicherzustellen und die Interoperabilität für den grenzüberschreitenden Handel, den branchenübergreifenden Handel und den Binnenhandel zu ermöglichen. Das semantische Modell kann von Organisationen des privaten und öffentlichen Sektors bei der Dokumentation mittels Ausstellung eines Belegs über den Kauf von Dienstleistungen und/oder Waren angewendet werden. Es kann auch bei der Dokumentation eines Kaufgeschäfts zwischen Unternehmen des privaten Sektors angewendet werden. Weiterhin wurde es für die Anwendung im Verbraucherkontext entwickelt.
Der Unterschied zwischen Belegdokument und Rechnungsdokument besteht grundsätzlich in der Dynamik der Anwendung. Eine Rechnung wird hauptsächlich ausgestellt, um eine Zahlung für gelieferte Waren und Dienstleistungen zu erhalten, während ein Beleg dazu dient, die Zahlung für den Kauf von Waren und Dienstleistungen zu dokumentieren. Außerdem enthalten Rechnungen immer Informationen zum Käufer, was bei Belegen nur in bestimmten Fällen erforderlich ist; meistens werden Belege ohne Angaben zum Käufer ausgestellt.
Die Tatsache, dass diese Bedingungen in den verschiedenen Ländern unterschiedlich gesetzlich geregelt sind und gehandhabt werden, wurde berücksichtigt.
Dieses Dokument erfüllt mindestens die folgenden Kriterien:
es ist technologieneutral;
- es ist mit den einschlägigen internationalen Normen für die elektronische Rechnungsstellung vereinbar;
- die Anwendung dieses Dokuments soll die Anforderungen zum Schutz von personenbezogenen Daten nach Richtlinie 95/46/EG erfüllen, unter Berücksichtigung der Grundsätze für Privatsphäre und Datenschutz durch Technik ("data protection by design"), Datenbegrenzung, Zweckbegrenzung, Notwendigkeit und Verhältnismäßigkeit;
- es steht mit den einschlägigen Bestimmungen der Richtlinie 2006/112/EG in Einklang;
- es ermöglicht die Einrichtung von zweckmäßigen, benutzerfreundlichen, flexiblen und kosteneffizienten Registrierkassensystemen und Systemen zur elektronischen Rechnungsstellung;
- es berücksichtigt die speziellen Bedürfnisse von kleinen und mittleren Unternehmen sowie von subzentralen öffentlichen Auftraggebern und anderen Auftraggebern;
- es eignet sich für die Verwendung bei kaufmännischen Transaktionen zwischen Unternehmen sowie zwischen Unternehmen und Verbrauchern.
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
Le présent document établit un modèle sémantique de données d'un reçu électronique ou d'une facture électronique simplifiée. Dans la suite du présent document, le terme « reçu électronique » est également employé pour désigner une « facture simplifiée ». Ce modèle sémantique comporte les éléments d'information essentiels qu'un reçu électronique doit contenir pour assurer le respect de la législation (y compris fiscale) et permettre l'interopérabilité du commerce transfrontalier, intersectoriel et national. Ce modèle sémantique peut être utilisé par des organisations des secteurs public et privé pour documenter l'achat de services et/ou de biens en émettant un reçu. Il peut également être utilisé pour documenter un achat entre entreprises du secteur privé. En outre, il a été conçu pour l'usage du grand public.
Ce qui distingue fondamentalement le document de reçu du document de facture est la dynamique de l'utilisation. Une facture est essentiellement émise pour finaliser le paiement de biens et de services livrés, et un reçu est émis pour documenter le paiement de l'achat de biens et de services. En outre, les factures contiennent toujours des informations relatives à l'acheteur, tandis que le reçu ne les nécessite que dans certains cas et qu'il est, pour l'essentiel, émis sans identification de l'acheteur.
Selon les pays, ces conditions sont régies différemment par les lois et la pratique, et cela a été pris en compte.
Le présent document remplit au moins les critères suivants :
- il est technologiquement neutre ;
- il est compatible avec les normes internationales applicables en matière de facturation électronique ;
- son application est destinée à satisfaire aux exigences de protection des données personnelles de la Directive 95/46/CE, dans le respect des principes de confidentialité et de protection des données dès la conception, de minimisation des données, de limitation des finalités, de nécessité et de proportionnalité ;
- il est compatible avec les dispositions pertinentes de la Directive 2006/112/CE ;
- il permet l'établissement de systèmes de facturation électronique pratiques, conviviaux, flexibles et efficaces en matière de coûts, ainsi que de systèmes de caisse ;
- il tient compte des besoins particuliers des petites et moyennes entreprises ainsi que des pouvoirs adjudicateurs sous-centraux et des entités adjudicatrices ;
- il peut être appliqué dans le cadre de transactions commerciales entre entreprises et entre entreprises et consommateurs.
Elektronsko izdajanje računov - 8. del: Semantični podatkovni model elementov e-potrdila ali poenostavljenega elektronskega računa
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
oSIST prEN 16931-8:2022
01-marec-2022
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: prEN 16931-8
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
oSIST prEN 16931-8:2022 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 16931-8:2022
---------------------- Page: 2 ----------------------
oSIST prEN 16931-8:2022
DRAFT
EUROPEAN STANDARD
prEN 16931-8
NORME EUROPÉENNE
EUROPÄISCHE NORM
January 2022
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
Elektronische Rechnungsstellung - Semantisches
Modell vereinfachter Rechnungen und elektronischer
Belege
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 434.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.
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.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.
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
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 16931-8:2022 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
1 Contents Page
2 European foreword . 3
3 1 Scope . 4
4 2 Normative references . 4
5 3 Terms and definitions . 5
6 4 The concept of an e-receipt . 6
7 5 Use cases and functionality supported by the e-receipt . 8
8 6 The semantic data model of the elements of an e-receipt . 33
9 7 Restrictions and extensions . 64
10 Annex A (informative) Examples . 65
11 A.1 Calculation examples . 65
12 A.2 Number of decimals and rounding . 65
13 A.3 Use cases . 65
14 Annex B (informative) BPMN symbols . 66
15 Bibliography . 69
16
2
---------------------- Page: 4 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
17 European foreword
18 This document (prEN 16931-8:2022) has been prepared by Technical Committee
19 CEN/TC “Electronic Invoicing”, the secretariat of which is held by NEN.
20 This document is currently submitted to the CEN Enquiry.
21 This document is part of a series of documents, consisting of the following parts:
22 — EN 16931-1, Electronic invoicing - Part 1: Semantic data model of the core elements of an
23 electronic invoice
24 — CEN/TS 16931-2, Electronic invoicing - Part 2: List of syntaxes that comply with EN 16931-1
25 — CEN/TS 16931-3-1, Electronic invoicing - Part 3-1: Methodology for syntax bindings of the core
26 elements of an electronic invoice
27 — CEN/TS 16931-3-2, Electronic invoicing - Part 3-2: Syntax binding for ISO/IEC 19845 (UBL 2.1)
28 invoice and credit note
29 — CEN/TS 16931-3-3, Electronic invoicing - Part 3-3: Syntax binding for UN/CEFACT XML Cross
30 Industry Invoice D16B
31 — CEN/TS 16931-3-4, Electronic invoicing - Part 3-4: Syntax binding for UN/EDIFACT INVOIC
32 D16B
33 — CEN/TR 16931-4, Electronic invoicing - Part 4: Guidelines on interoperability of electronic
34 invoices at the transmission level
35 — CEN/TR 16931-5, Electronic invoicing - Part 5: Guidelines on the use of sector or country
36 extensions in conjunction with EN 16931-1, methodology to be applied in the real environment
1
37 — CEN/TR 16931-6 , Electronic invoicing - Part 6: Result of the test of EN 16931-1 with respect to
38 its practical application for an end user - Testing methodology
39 — CEN/TS 16931-7, Electronic invoicing - Part 7: Methodology for the development and use of EN
40 16931-1 compliant structured Core Invoice Usage Specifications
41 — prEN 16931-8, Electronic invoicing - Part 8: Semantic data model of the elements of an e-receipt
42 or a simplified electronic invoice (this document)
43
1
In preparation.
3
---------------------- Page: 5 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
44 1 Scope
45 This document establishes a semantic data model of an e-receipt or a simplified electronic invoice.
46 In the remainder of this document, when "e-receipt" is mentioned, "simplified invoice" is also
47 meant. The semantic model includes essential information elements that an electronic receipt
48 needs to ensure legal (including fiscal) compliance and to enable interoperability for cross-border,
49 cross sector and domestic trade. The semantic model can be used by organizations in the private
50 and the public sector for documenting by issuing a receipt for the purchase of services and /or
51 goods. It can also be used for documenting a purchase between private sector enterprises. In
52 addition, it has been designed for the use of consumers.
53 What separates the receipt document from the invoice document is basically the dynamics of the
54 usage. An invoice is mainly issued to achieve a payment for delivered goods and services and a
55 receipt is issued to document the payment for the purchase of goods and services. In addition, the
56 invoices always contain information about the buyer, whereas the receipt only needs that in
57 certain cases and is for the most part issued without a buyer identification.
58 These conditions are regulated differently by laws and practice in different countries and this has
59 been taken into consideration.
60 This document complies at least with the following criteria:
61 — it is technologically neutral;
62 — it is compatible with relevant international standards on electronic invoicing;
63 — the application of this document is intended to comply with the requirements for the
64 protection of personal data of Directive 95/46/EC, having due regard to the principles of
65 privacy and data protection by-design, data minimization, purpose limitation, necessity and
66 proportionality;
67 — it is consistent with the relevant provisions of Directive 2006/112/EC;
68 — it allows for the establishment of practical, user-friendly, flexible and cost-efficient electronic
69 invoicing and cash register systems;
70 — it takes into account the special needs of small and medium-sized enterprises as well as of
71 sub-central contracting authorities and contracting entities;
72 — it is suitable for use in commercial transactions between enterprises and between enterprises
73 and consumers.
74 2 Normative references
75 The following documents are referred to in the text in such a way that some or all of their content
76 constitutes requirements of this document. For dated references, only the edition cited applies.
77 For undated references, the latest edition of the referenced document (including any
78 amendments) applies.
79 EN ISO 3166-1, Codes for the representation of names of countries and their subdivisions - Part 1:
80 Country code (ISO 3166-1)
81 ISO 8601-1:2019, Date and time - Representations for information interchange - Part 1: Basic rules
82 ISO 15000-5:2014, Electronic Business Extensible Markup Language (ebXML) - Part 5: Core
83 Components Specification (CCS)
4
---------------------- Page: 6 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
84 3 Terms and definitions
85 For the purposes of this document, the following terms and definitions apply.
86 ISO and IEC maintain terminological databases for use in standardization at the following
87 addresses:
88 — IEC Electropedia: available at https://www.electropedia.org/
89 — ISO Online browsing platform: available at https://www.iso.org/obp
90 NOTE Business terms that are part of the semantic model are defined in the model itself.
91 3.1
92 electronic invoice
93 invoice that has been issued, transmitted and received in a structured electronic format which
94 allows for its automatic and electronic processing
95 [SOURCE: Directive 2014/55/EU]
96 3.2
97 electronic receipt
98 receipt that has been issued in a structured electronic format which allows for its automatic and
99 electronic processing also to be transmitted and received by the customer if customer so decides
100 3.3
101 semantic data model
102 structured set of logically interrelated information elements
103 3.4
104 information element
105 semantic concept that can be defined independent of any particular representation in a syntax
106 3.5
107 structured information element
108 information element that can be processed automatically
109 3.6
110 syntax
111 machine-readable language or dialect used to represent the information elements contained in an
112 electronic document (e.g. an electronic invoice)
113 3.7
114 business term
115 label assigned to a given information element which is used as a primary reference
116 3.8
117 receipt model
118 semantic data model of the elements of an electronic receipt
119 3.9
120 elements of an e-receipt
121 set of essential information elements that an electronic invoice may contain in order to enable
122 cross-border interoperability, including the necessary information to ensure legal compliance
5
---------------------- Page: 7 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
123 3.10
124 identifier
125 character string used to establish the identity of, and distinguish uniquely, one instance of an
126 object within an identification scheme from all other objects within the same scheme
127 Note 1 to entry: An identifier may be a word, number, letter, symbol, or any combination of those,
128 depending on the identification scheme used.
129 3.11
130 identification scheme
131 collection of identifiers applicable for a given type of object governed under a common set of rules
132 3.12
133 POS
134 cash register, or cash register system that allows communication between different components
135 and systems
136 Note 1 to entry: A POS system is designed to facilitate user-friendly administration of sales for employees.
137 The system also helps with the management of a business.
138 3.13
139 compliant
140 some or all features of the e-receipt model are used and all rules of the e model are respected
141 Note 1 to entry: Based on TOGAF definition of a compliant specification.
142 3.14
143 conformant
144 all rules of the e-receipt model are respected and some additional features not defined in the
145 model are also used
146 Note 1 to entry: Based on TOGAF definition of a conformant specification.
147 4 The concept of an e-receipt
148 4.1 Introduction
149 In many countries retail businesses are required to use certified cash registers or point of sales
150 systems (POS) to produce receipts for each transaction, and to record and preserve the sales data
151 for audit. The purpose is to better tax compliance and set the stage for fair competition. The
152 requirements set for the content of the receipt, and the sales data to be preserved, have strong
153 seller emphasis, linking also to the seller’s obligations for bookkeeping and VAT declaration.
154 For the buyer the receipt is an instrument mainly for consumer protection, guaranteeing that the
155 purchase was legitimate and correct, but in the case the buyer is a taxable business entity the
156 receipt may also serve the buyer as verification in bookkeeping and for deduction of VAT.
157 It should be noted that the legislation on receipts in the EU member states has national scope – the
158 only exception is the EU VAT Directive that has been transposed into national law.
159 The VAT directive recognizes invoice and simplified invoice as valid forms of transaction. This
160 means that, to the extent a receipt is to substantiate reporting of VAT, it shall satisfy the
161 requirements as either invoice or simplified invoice. But, again, while the invoice is implemented
162 consistently across the member states, the implementation of the simplified invoice may be
163 adapted to national practice.
6
---------------------- Page: 8 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
164 Consequently, under current legal regimes the receipt has mainly domestic reach; if one wants to
165 do transactions internationally in many cases one needs to use the invoice.
166 4.2 Contents of the e-receipt model
167 Semantic building blocks for the e-receipt have been chosen, when applicable, from EN 16931 or
168 from simplified invoice requirements (https://ec.europa.eu/taxation_customs/business/vat/eu-
169 vat-rules-topic/vat-invoicing-rules_en). The EU’s Digital Single Market aims to overcome
170 challenges by creating the right environment for digital networks and services to flourish.
171 This is not only achieved by setting the right regulatory conditions, but also by providing cross-
172 border digital infrastructures and services.
173 To achieve these in the e-receipt standardization, required elements for e-receipt are chosen so
174 that already existing national receipt solutions could find needed elements from the e-receipt
175 standard and optional requirements support functionality that may vary depending on national
176 interests, needs and legislation allowing future developments.
177 Semantic building blocks for required and optional elements have been described in Clause 5
178 introducing some examples of use cases.
179 In cases where new optional semantic elements were introduced or arise during handling of
180 comments after enquiry from national standardization bodies, work needs to be done during the
181 standardization process to add and introduce those into existing references e.g. to UBL,
182 UN/CEFACT, CII or else source that EU CEF would support.
183 Caveat: The content of the semantic model has been drafted to satisfy a wide range of stakeholder
184 needs and application/industry areas. Only a limited set of legislations was considered but the
185 ambition has been to designate a framework standard that can accommodate for the various
186 legislations in Europe. However, it cannot be guaranteed that various regulations (for tax
187 compliance, VAT reporting, bookkeeping, and more) recognize the concept of receipt. As can be
188 concluded from 4.1, implementation has to be done on a national level and, furthermore,
189 implementers need to verify that the selected transaction format supports the relevant
190 regulations.
191 4.3 How to use the e-receipt model
192 This document lists business terms (information elements) and business term groups that may be
193 included in an e-receipt or electronic simplified invoice. An e-receipt is transmitted between a
194 sending and a receiving application. Sending applications may take any subset of the set of
195 business terms listed in this document, provided it respects the stated cardinality
196 (mandatory/conditional status and minimum/maximum repetition). Receiving applications shall
197 be able to receive all business terms listed, but may interpret and process only the information
198 elements they need for their purpose. No prior agreement between sending and receiving
199 applications is needed. Sending applications obviously should advertise to its users for what
200 purposes the e-receipt transmitted is fit by identifying the type of document it is.
201 4.4 Compliance
202 4.4.1 Compliance of sending or receiving party
203 A receiving party may only claim compliance to the e-receipt model if it can accept all invoices
204 that comply with the model. It nevertheless only needs to understand and process the information
205 elements that it needs for its purposes.
206 A sending party may claim compliance if it sends invoices that comply with the e-receipt model.
7
---------------------- Page: 9 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
207 4.4.2 Compliance of a receipt/invoice document instance
208 An e-receipt document instance is compliant to the model if it respects all rules defined for the e-
209 receipt model.
210 5 Use cases and functionality supported by the e-receipt
211 5.1 Use case requirements supported
212 5.1.1 Introduction
213 The e-receipt model supports a basic purchase-to-pay process.
214 Using payment card as payment method, the card schemes may require special information into
215 given receipt.
216 Some countries have also legal requirements for point of sales (POS) and information into given
217 receipt.
218 This subclause describes the processes that are supported by the e-receipt model. How the
219 receipts are electronically exchanged is not described in the process models. Parties may handle
220 document exchange with their own resources or outsource (part of) it. See also CEN/TR 16931-4.
221 The process models focus on the external activities of the parties and do not describe internal
222 activities.
223 The process model diagrams are presented in the Business Process Model and Notation (BPMN)
224 of the Object Management Group (OMG). A short legend of the symbols used can be found in
225 Annex B.
226 The process models included in this clause are intended to indicate the business contexts that are
227 supported by the e-receipt model. The models do not give a full definition of those processes.
228 The e-receipt model shall include elements that allow the trading parties to represent any receipt
229 transaction according to the EU VAT directives and should support the following types of business
230 processes:
231 • U1: B2C e-receipts
232 • U2: Online shop e-receipt
233 • U3: e-Receipt is used to claim expenses
234 • U4: Buyer uses receipt information for VAT reclaim
235 • U5: Seller use receipts information for VAT declaration
236 • U6: e-receipt is used for returns, guarantee and refund
237 • U7: Simplified invoice for B2B transactions
8
---------------------- Page: 10 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
238
239 Figure 1 — Overview of use cases
240 5.1.2 U1: B2C e-receipts
241 5.1.2.1 Introduction
242 The most common case (about 95 %) for an e-receipt is when a consumer purchases goods or
243 services, pays and receives the receipt as proof of purchase and payment.
244 5.1.2.2 Short description
245 • A receipt is a result from a purchase process carried out by a Consumer
246 • A receipt is issued by a cash register (ECR/POS)
247 5.1.2.3 Parties involved
248 i. Seller (Merchant)
249 ii. Buyer (Consumer)
250 5.1.2.4 Purpose
251 The buyer uses the receipt information to get an overview of their spending and to reconcile the
252 spending with the payment record (credit or debit card slip / bank statement).
253
9
---------------------- Page: 11 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
254 5.1.2.5 Advantages
255 Seller advantages
256 • Legal compliance
257 • Customer satisfaction, in early stages winning the customer's preferences
258 • Identifying the discount(s) and promoting agreements and advantage programs, attracting
259 customers to prefer their services by giving customers better oversight and possibility to
260 control agreement loyalty
261 • Evaluating loyalty programs and agreements
262 • Reducing receipt paper costs
263 • Securing reference to product documentation and tracking, easy referencing and
264 documenting the features of the products and services
265 • Easier search for the purchase in the ECR/POS in case of service, return of product, warranty
266 handling
267 • Relaying information about warranties and handling of them
268 • Relaying information about loyalty saving (coupons)
269 • Potential information channel between the seller and the customer
270 • Information about the business:
271 o Opening hours
272 o Telephones
273 o Mail address
274 o etc.
275 Buyer advantages
276 • Legal compliance
277 • Consumers need to manage different type of budgets as part of their daily life
278 • If the buyer wants to return the product, the e-receipt is easily available and searchable on
279 the mobile wallet, computers and other applications from service providers
280 • Seller information like Seller name (Seller’s business name) and Organization VAT identifier
281 are essential for high quality services for private customers
282 • Additional information like business address as well as the line item information, can help
283 customers to identify payments, tracking and searching for information about the goods and
284 services
285 • With e-receipts sharing costs with other party and documenting refund claims.
10
---------------------- Page: 12 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
286 • Better fraud detection
287 • When infrastructure and applications are made:
288 o Oversight over expenditure on a personal level
289 o Automatic categorization and expenditure budgeting
290 o Ease of storing receipts
291 o Searching for information and no old paper receipts where the text has vanished
292 5.1.2.6 Process or workflow description
293
294 Figure 2
295 1. The Buyer purchases goods and/or services from the Seller
296 2. If necessary, the Buyer provides additional information to the Seller (e.g. ID number)
297 3. The Seller calculates the total amount of the purchase
298 4. The Buyer selects a payment method from the options offered by the Seller
299 5. The Buyer pays or initiates the payment (cash, voucher or with electronic means)
300 6. The Seller generates the e-receipt with their cash register and sends it to the Buyer
301 7. The Buyer imports the e-receipt in their application
11
---------------------- Page: 13 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
302 5.1.2.7 Variants and exceptions
303 For some product and service types specific information exists that is needed in the e-receipt:
304 • ATMs and currency exchange
Business requirement Business Reason
Term
Currency
Amount
Exchange rate
305
306 • Food (nutrition value, ingredients, allergy issues, source, etc.)
Business requirement Business Reason
Term
Nutrition value consumer need
Allergy information consumer need
Quality marks consumer need
307
308 • Textile and clothing
Business requirement Business Reason
Term
Composition consumer need
Washing instructions consumer need
Quality marks ? consumer need
309
310 • Electronics, hardware and machinery
Business requirements Business Reason
Term
Guarantee/warrantee consumer need
Recycling instructions consumer need
311
312 • Access to cultural and other events or facilities
Business requirements Business Reason
Term
Token consumer need
Rang and seat consumer need
313
12
---------------------- Page: 14 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
314 5.1.2.8 Legal aspects
315 TBD
316 5.1.2.9 Technical aspects
317 Usually, the e-receipt is generated with a cash register or with a ticket or vending machine. There
318 exist different options how the document is sent to the buyer.
319 • The document can be transferred to the buyer’s mobile device by means of a wireless protocol
320 (e.g. NFC, Bluetooth)
321 • The document (or a link to the document) can be represented in a barcode (e.g. a QR-code)
322 which is scanned by the buyer
323 • The buyer may provide their electronic address and is sent to that address, possibly by means
324 of one or more service providers
325 The cash register and the payment terminal may not be connected with each other. In that case
326 either the e-receipt may not contain payment information or the buyer’s application gets the
327 payment information through another channel from the payment terminal. It is also possible that
328 the e-receipt is completed (manually) with payment information by the seller or the buyer.
329 5.1.2.10 Other aspects
330 An e-receipt should contain the means of payment and an identifier of the payment transaction.
331 5.1.2.11 Data requirements
Business requirements Business Reason
Term
Merchant/Business name general receipt requirement
Merchant Business ID general receipt requirement if VAT
vat/org/number registered see national thresholds
Seller contact details general receipt requirement
Place of delivery
Cash register id requirement e.g. if fiscal cash
registers
Payment terminal ID Control info which could be used
like in fiscal cash register solutions,
also Payment location for STATistics
purposes
Address where the cash register is
Receipt id/ number general receipt requirement
Date and time of issue general receipt requirement
Type of goods product/service general receipt requirement
name description at line level
Product/service Quantity general receipt requirement
Discounts and allowances Merchant + consumer need
Total amount general receipt requirement
13
---------------------- Page: 15 ----------------------
oSIST prEN 16931-8:2022
prEN 16931-8:2022 (E)
Business requirements Business Reason
Term
Currency
Other taxes and fees; Charges
structure
Tax category and rate on line level details to separate each items VAT
treatment – if VAT registered seller
– see national thresholds
Payment mean requirement (e.g.
cash/card)
Payment transaction ID
Retail price modifiers merchant need
Welcome message consumer need
Opening hours consumer need
Return policies consumer need
Warranty terms varies, in some member states
different thresholds – in Nordics
receipt itself is VAT deductible also
without
Payment card information
Payment card primary account Control info which could be used
number like in fiscal cash register solutions
AuthorizationCode Control info which could be used
like in fiscal cash register solutions
MessageChecksum, Checksum Control info which could be used
based on receipt information like in fiscal cash register solutions
ControlChecksum, Receipt only those that suitable for receipt –
continuity checksum based on the see e.g. OSS
previous receipt checksum
eAddress, eWallet - where to route STATistic Authority collects
e-receipt
Seller Company, Sector code Related “Merchant/Business name”
but different trading locations may
operate under “trading name”
Seller trading name Location related as "Payment
location, STAT" ”Payment terminal
ID”
Merchant category
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.