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

This Technical Report describes how trading partners may extend the core invoice model and the related business rules and code lists, in order to support business cases that are specific to their trading environment, while at the same time maintaining semantic interoperability with the core invoice model.
This Technical Report does not define a methodology for creation of core invoice usage specification, nor does it describe the detailed process of syntax binding.

Elektronische Rechnungsstellung - Teil 5: Leitfaden über die Verwendung von branchen- oder länderspezifischen Erweiterungen der EN 16931-1 einschließlich einer im realen Umfeld einzusetzenden Methodik

Facturation électronique - Partie 5: Lignes directrices pour l'utilisation des extensions de secteur ou de pays conjointement avec la Norme européenne, avec une méthodologie à appliquer dans l'environnement réel

Elektronsko izdajanje računov - 5. del: Smernice za uporabo v sektorju ali državi v povezavi z EN 16931-1, metodologija za uporabo v realnem okolju

To tehnično poročilo podaja smernice o izbirni uporabi v sektorju ali državi v povezavi z evropskim standardom o semantičnem podatkovnem modelu za ključne elemente elektronskega računa, vključno z metodologijo za uporabo v realnem okolju.

General Information

Status
Published
Publication Date
04-Jul-2017
Current Stage
6060 - Definitive text made available (DAV) - Publishing
Due Date
05-Jul-2017
Completion Date
05-Jul-2017

Buy Standard

Technical report
-TP CEN/TR 16931-5:2017 - BARVE na PDF-str 12,13,17,18
English language
19 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

Standards Content (sample)

SLOVENSKI STANDARD
SIST-TP CEN/TR 16931-5:2017
01-oktober-2017

(OHNWURQVNRL]GDMDQMHUDþXQRYGHO6PHUQLFH]DXSRUDERYVHNWRUMXDOLGUåDYLY

SRYH]DYL](1PHWRGRORJLMD]DXSRUDERYUHDOQHPRNROMX

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

Elektronische Rechnungsstellung - Teil 5: Leitfaden über die Verwendung von branchen-

oder länderspezifischen Erweiterungen der EN 16931-1 einschließlich einer im realen

Umfeld einzusetzenden Methodik

Facturation électronique - Partie 5: Lignes directrices pour l'utilisation des extensions de

secteur ou de pays conjointement avec la Norme européenne, avec une méthodologie à

appliquer dans l'environnement réel
Ta slovenski standard je istoveten z: CEN/TR 16931-5:2017
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
SIST-TP CEN/TR 16931-5:2017 en,fr,de

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
SIST-TP CEN/TR 16931-5:2017
---------------------- Page: 2 ----------------------
SIST-TP CEN/TR 16931-5:2017
CEN/TR 16931-5
TECHNICAL REPORT
RAPPORT TECHNIQUE
July 2017
TECHNISCHER BERICHT
ICS 35.240.20; 35.240.63
English Version
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

Facturation électronique - Partie 5: Lignes directrices Elektronische Rechnungsstellung - Teil 5: Leitfaden

pour l'utilisation des extensions de secteur ou de pays über die Verwendung von branchen- oder

conjointement avec la Norme européenne, avec une länderspezifischen Erweiterungen der EN 16931-1

méthodologie à appliquer dans l'environnement réel einschließlich einer im realen Umfeld einzusetzenden

Methodik

This Technical Report was approved by CEN on 14 May 2017. It has been drawn up by the Technical Committee CEN/TC 434.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,

Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,

Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,

Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels

© 2017 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 16931-5:2017 E

worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST-TP CEN/TR 16931-5:2017
CEN/TR 16931-5:2017 (E)
Contents Page

European foreword ....................................................................................................................................................... 3

Introduction .................................................................................................................................................................... 4

1 Scope .................................................................................................................................................................... 6

2 Normative references .................................................................................................................................... 6

3 Terms and definitions ................................................................................................................................... 6

4 The challenge of interoperability .............................................................................................................. 7

4.1 Interoperability through standardization ............................................................................................. 7

4.2 The challenge .................................................................................................................................................... 7

4.3 The purpose of extension specifications ................................................................................................ 8

4.4 Who will develop extension specifications and why? ........................................................................ 8

5 Conformance ..................................................................................................................................................... 9

5.1 Conforming objects ......................................................................................................................................... 9

5.2 Conformance of the extension specifications ....................................................................................... 9

5.3 Conformance of sending or receiving party .......................................................................................... 9

5.4 Conformance of an invoice instance document................................................................................. 10

6 Extension specification rules ................................................................................................................... 10

6.1 Introduction to extension specification rules.................................................................................... 10

6.2 What may be specified in an extension specification ..................................................................... 10

6.3 Documentation of extension specifications ....................................................................................... 12

6.4 Publication of specifications .................................................................................................................... 12

6.5 Mapping to syntax ........................................................................................................................................ 12

6.6 Relation between extension specifications ........................................................................................ 12

6.7 Governance of extension specifications ............................................................................................... 12

6.8 Identification of extension specification ............................................................................................. 13

6.9 Validation ........................................................................................................................................................ 13

7 The methodology .......................................................................................................................................... 14

7.1 How do parties agree on using an extension ...................................................................................... 14

7.2 Process for defining extensions .............................................................................................................. 14

7.3 Statement of objectives .............................................................................................................................. 16

7.4 Gathering of business requirements ..................................................................................................... 16

7.5 Mapping against norm ................................................................................................................................ 16

7.6 Re-evaluate requirements and/or re-evaluate processes ............................................................ 16

7.7 List requirements ......................................................................................................................................... 17

7.8 Define required changes............................................................................................................................ 17

7.9 Create specification ..................................................................................................................................... 17

7.10 Evaluate type of changes ........................................................................................................................... 17

7.11 Publish extension specification .............................................................................................................. 18

7.12 Bind to syntax ................................................................................................................................................ 18

Bibliography ................................................................................................................................................................. 19

---------------------- Page: 4 ----------------------
SIST-TP CEN/TR 16931-5:2017
CEN/TR 16931-5:2017 (E)
European foreword

This document (CEN/TR 16931-5:2017) has been prepared by Technical Committee CEN/TC 434

“Electronic invoicing”, the secretariat of which is held by NEN.

Attention is drawn to the possibility that some of the elements of this document may be the subject of

patent rights. CEN shall not be held responsible for identifying any or all such patent rights.

This document has been prepared under a mandate given to CEN by the European Commission and the

European Free Trade Association.
This document is part of a set of documents, consisting of:

— EN 16931-1:2017, Electronic invoicing — Part 1: Semantic data model of the core elements of an

electronic invoice;

— CEN/TS 16931-2:2017, Electronic invoicing — Part 2: List of syntaxes that comply with EN 16931-1;

— CEN/TS 16931-3-1:2017, Electronic invoicing — Part 3-1: Methodology for syntax bindings of the

core elements of an electronic invoice;

— CEN/TS 16931-3-2:2017, Electronic invoicing — Part 3-2: Syntax binding for ISO/IEC 19845 (UBL

2.1) invoice and credit note;

— CEN/TS 16931-3-3:2017, Electronic invoicing — Part 3-3: Syntax binding for UN/CEFACT XML

Industry Invoice D16B;

— CEN/TS 16931-3-4:2017, Electronic invoicing — Part 3-4: Syntax binding for UN/EDIFACT INVOIC

D16B;

— CEN/TR 16931-4:2017, Electronic invoicing — Part 4: Guidelines on interoperability of electronic

invoices at the transmission level;

— CEN/TR 16931-5:2017, Electronic invoicing — Part 5: Guidelines on the use of sector or country

extensions in conjunction with EN 16931-1, methodology to be applied in the real environment;

— FprCEN/TR 16931-6:2017, Electronic invoicing — Part 6: Result of the test of EN 16931-1 with

respect to its practical application for an end user.
---------------------- Page: 5 ----------------------
SIST-TP CEN/TR 16931-5:2017
CEN/TR 16931-5:2017 (E)
Introduction

The European Commission states 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” [1]. Based on this recognition “The

Commission wants to see e-invoicing become the predominant method of invoicing by 2020 in Europe

[1].”

As a means to achieve this goal, Directive 2014/55/EU [2] on electronic invoicing in public

procurement aims at facilitating the use of electronic invoices by economic operators when supplying

goods, works and services to public administrations (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 [2], 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 Directive 2014/55/EU;

— it is in conformance with the appropriate mapping defined in the applicable subpart of

CEN/TS 16931-3 (all parts).

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.

It is expected that in most situations, business partners would use the core invoice model exclusively

and the invoices they send or receive would not need to contain any additional structured information

elements. However, in some sectors or situations where there are specific additional information

requirements, the required information may be conveyed in the form of unstructured text.

Unstructured text has the drawback that it cannot be processed automatically and therefore requires

human intervention. Alternatively, the specific information requirements can be implemented using

information elements that extend the core invoice model. In these circumstances, it should be possible

to define a number of required additional information elements whilst still utilizing the concepts of the

core invoice model.

In other situations, additional guidance or restrictions on the use of the information elements already

defined in the core invoice model may be required and documented in a core invoice usage specification

as outlined in EN 16931-1.

In order to comply with the provisions of Directive 2014/55/EU [2], guidelines on the optional use of

extensions to the core invoice model, including a methodology to be applied in the real environment,

are needed. This technical report provides this methodology and complies at least with the following

criteria:
— it is technologically neutral;

— it is compatible with relevant international standards on electronic invoicing;

---------------------- Page: 6 ----------------------
SIST-TP CEN/TR 16931-5:2017
CEN/TR 16931-5:2017 (E)

— it has regard to the need for personal data protection in accordance with Directive 95/46/EC [3], to

a ‘data protection by design’ approach and to the principles of proportionality, data minimization

and purpose limitation;
— it is consistent with the relevant provisions of Directive 2006/112/EC [4];

— it allows for the establishment of practical, user-friendly, flexible and cost-efficient electronic

invoicing;

— 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.

The methodology and rules described in this document are based on the following key design

principles:

— Extension specifications are used to provide user communities with the ability to add information

elements or functions to the core invoice model in order to support their specific business

requirements.

— An extension specification is not intended to be used to specify legally required information

elements and expected to be mandatory by law. However the further specification of specific legal

requirements may be stated in an extension specification in bilateral agreements.

— Information provided in supplementary documents (attachments) to an invoice are not considered

to be extensions, as these are an integral part of the core invoice model.

— Extension specifications should not be used to remove information elements from the core invoice

model, only to add information elements.
— An extension is defined in an extension specification.

— Extension specifications should be made publicly available in an appropriate repository in order to

foster awareness and reuse, as this is expected to foster convergence over time (see 6.7).

— Reuse the syntax binding methodology applied to EN 16931-1.

— The actual implementation and use of an extension specification is subject to agreement between

the trading partners.
---------------------- Page: 7 ----------------------
SIST-TP CEN/TR 16931-5:2017
CEN/TR 16931-5:2017 (E)
1 Scope

This Technical Report describes how trading partners may extend the core invoice model and the

related business rules and code lists, in order to support business cases that are specific to their trading

environment, while at the same time maintaining semantic interoperability with the core invoice model.

This Technical Report does not define a methodology for creation of core invoice usage specification,

nor does it describe the detailed process of syntax binding.
2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are

indispensable for its application. For dated references, only the edition cited applies. For undated

references, the latest edition of the referenced document (including any amendments) applies.

EN 16931-1:2017, Electronic Invoicing — Part 1: Semantic Data Model of the Core Elements of an

Electronic Invoice

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 Industry Invoice

D16B

CEN/TS 16931-3-4, Electronic invoicing — Part 3-4: Syntax binding for UN/EDIFACT INVOIC D16B

3 Terms and definitions

For the purposes of this document the terms and definitions given in EN 16931-1:2017 and the

following, apply.
3.1
core invoice usage specification

specification that provides additional explanations and examples, as well as (business) rules related to

the actual implementation and use of the core invoice model in a specific trading situation

3.2
invoice instance document
individual electronic invoice
3.3
core invoice instance document

instance of an electronic invoice that is compliant to a core invoice usage specification

3.4
extended invoice instance document

electronic invoice instance document that is compliant to an extension specification

Note 1 to entry: An extended invoice instance document is then also conformant to the core invoice model.

---------------------- Page: 8 ----------------------
SIST-TP CEN/TR 16931-5:2017
CEN/TR 16931-5:2017 (E)
3.5
extension specification

specification that describes the use of additional information elements, i.e. information elements not

defined in the core invoice model, or other alterations that add functionality

Note 1 to entry: The resulting invoice model will contain information elements that do not form a strict subset

of the core invoice model. An extension specification may also provide additional explanations and examples.

3.6
compliant

using some features of the core invoice model, but all features that are used are in accordance with the

rules of the core invoice model
Note 1 to entry: Based on TOGAF definition of a compliant specification [5].
3.7
conformant

using all features of the core invoice model in accordance with its rules, and extended with additional

features
Note 1 to entry: Based on TOGAF definition of a conformant specification [5].
4 The challenge of interoperability
4.1 Interoperability through standardization

The core invoice model has been carefully designed to meet the commercial requirements for electronic

invoicing in the vast majority of public procurement situations, whilst also meeting the needs for a core

invoice instance document in transactions between business enterprises. The core invoice model is

expected to meet the needs of EU Member State legal systems for both VAT and other commercial laws

and regulations. Information elements will usually be structured and allow for automated processing,

although some may only be available in textual form and thus require human intervention.

The core invoice model thus represents the baseline for semantic interoperability in electronic

invoicing.

Trading partners are, however, free to organize the use of appropriate extensions comprising additional

information elements and functionalities not included in the core invoice model. Such extensions should

preferably be created on a community basis.
4.2 The challenge

A key challenge to the goal of semantic interoperability is that industry sectors have industry specific

requirements and in specific business processes trading partners may require specific information.

Also, if a higher degree of automation is required due to more complex business processes between

trading partners or within a sector, that may also require the support of additional requirements.

A core invoice model that would support all possible requirements would be enormous in size and very

complex in its business rules, and thus impractical to implement. In order to relieve suppliers from

having to support data requirements which are only needed for implementing more complex and

specialized invoicing scenarios and to enable as many participants as possible to take part in electronic

invoicing (without bilateral arrangements), a focus on the central, cross-industry requirements for the

transmission of a core invoice instance document is necessary.

Additional requirements that are not supported in the core invoice model could be analysed and

categorized as sector specific, and may be added to the semantic data model as an extension. A sector

---------------------- Page: 9 ----------------------
SIST-TP CEN/TR 16931-5:2017
CEN/TR 16931-5:2017 (E)

extension would then contain information elements that are only a concern to that industry sector or to

a specific community.

It should be noted that extended invoice instance documents cannot be expected to be processed by the

recipient without prior bilateral arrangement (direct or indirect).
4.3 The purpose of extension specifications

An extension specification is developed with the objective of supporting one or more stated business

requirements that are not or not sufficiently supported in the core invoice model. These business

requirements may be due to specific needs in a trading relationship, special sectoral requirements,

specific legal requirements or any combination thereof.

Each extension specification describes a set of defined additions to the core invoice model and as

required to support the business functions or legal requirements that are its objective.

An extension specification is typically a set of additional information elements and/or additional

business rules that, when followed, result in an extended invoice instance document that cannot be

correctly processed by the receiver by only following the rules defined for the core invoice model.

Consequently, it can only be used through an agreement between the sender and the receiver that

includes an agreement by the receiver to use a specific extension specification. Through such an

agreement the receiver is committed to take those additions into account and process them accordingly.

The main reasons for developing extension specifications include:

— A receiver requires information that is not provided for in the core invoice model.

— A sender or an industry sector defines additional business terms that are relevant to its business

for those of its customers who require it.
4.4 Who will develop extension specifications and why?

The creation of an extension specification may be driven by different requirements, including but not

limited to the following:

— A buying party who wishes to increase automation in receiving and processing incoming electronic

invoices may require certain additional information elements to be used in order to provide

information that is needed to drive the automation. Such information may include purchase order

identifiers, commodity codes or other details. If the required elements are not within the core

invoice model, the buying party may state these requirements as an extension specification that he

provides to his suppliers when asking them to engage in electronic invoicing. If the suppliers agree

to support these requirements the buying party can implement them in its system according to the

specification.

— For an industry that uses information elements that are specific to that industry the relevant

community (industry association or a similar party) may initiate a project to define an extension

specification that defines how these specific information elements are used in addition to the core

invoice model. This specification then describes the specific requirements of the industry and how

they are supported by additional information elements. This specification can then be shared by all

companies in this industry to support a business process that is common in that industry.

— A service provider who intends to provide invoice related services such as invoice processing or

financing may require the purchaser of the service to include information in the invoice that is

additional to the core invoice model. The service provider may specify an extension specification

that describes these additional requirements and require the user of the service to implement

them.
---------------------- Page: 10 ----------------------
SIST-TP CEN/TR 16931-5:2017
CEN/TR 16931-5:2017 (E)

— Extension specifications may be developed with a different functional scope than what is supported

in the EN 16931-1 semantic model, e.g. for more advanced support of customs clearance.

— An extension specification may be defined to support a specific function that is common across

several industries. As an example: a particular business process where orders and invoices are

matched along with a dispatch advice and/or a receiving advice. The extension specification would

describe the additional information requirement, but this extension specification may be shared

among any party who uses this business process irrespective of its industry.

Extension specifications should preferably not be developed on a bilateral basis, but instead on a

multilateral basis, e.g. sector. Whilst bilateral agreements are possible, European-wide collaboration

among communities, for example through national standardization bodies, should be encouraged to

preserve semantic interoperability.
5 Conformance
5.1 Conforming objects

The conformance to the core invoice model, in the context of using extension specifications, can be

measured at three points:
— the conformance of the extension specification itself,

— the conformance of the actual implementation by a given sender or receiver, and

— the conformance of the invoice instance document.
Each of these levels of conformance is discussed in the following subclauses.
5.2 Conformance of the extension specifications

The extension specifications that are used in conjunction with the core invoice model shall themselves

adhere to the methodology and rules described in this guideline and expressed in the following criteria:

— The specification shall clearly state what business functions and/or legal requirements it is

intended to support in addition to those covered by the core invoice model.
— The specification shall clearly state its publisher and governor.

— The specification shall clearly state in what way it differs from the core invoice model. The

specification and, when relevant, its version shall be uniquely identifiable both for referencing and

for identification in processing.
— The specification shall state its underlying specifications and their version.

— The syntax binding of a specification shall follow the syntax binding methodology defined in

CEN/TS 16931-3-1.

A resulting semantic data model is defined as being conformant to the core invoice model if its

information elements, together with the business rules defined on them, do not form a subset of the

core invoice model but add to it.
5.3 Conformance of sending or receiving party

Directive 2014/55/EU [2] defines the use of electronic invoices and when applied to the use of

extension specification those requirements impose the following rules on the relevant parties:

---------------------- Page: 11 ----------------------
SIST-TP CEN/TR 16931-5:2017
CEN/TR 16931-5:2017 (E)

— A receiving party may only claim compliance to the core invoice model if he accepts invoices that

comply with the core invoice model, even if he in parallel accepts invoices based on an extension

specification.

— A sending party may only claim compliance to the core invoice model if he is able to send invoices

that comply with the core invoice model, even if he additionally can provide invoices that are based

on an extension specification.

The above implies that parties who process invoices using extension specifications that are conformant

to the core invoice model shall in parallel operate processes for invoices that comply with the core

invoice model.
5.4 Conformance of an invoice instance document

An invoice instance document is compliant to the core invoice model if it respects all rules defined for

the core invoice model and does not contain additional business terms.

An invoice instance document that contains additional information with regard to the core invoice

model cannot be processed by a receiver that is not supporting the rel
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.