Electronic invoicing - Part 7: Methodology for the development and use of EN 16931-1 compliant structured Core Invoice Usage Specifications

This document applies in case a CIUS is produced as a specification with the objective of registering it in the appropriate registry. This document also establishes requirements for the steps to be taken in the process of creating Core Invoice Usage Specifications (CIUS) as defined in EN 16931-1. Furthermore, this document provides guidance for the creation and implementation of a CIUS.
The following points are the focus:
-   steps that need to be taken in consideration to avoid unnecessary proliferation and fragmentation in the use of CIUSs;
-   guidance on the creation and implementation of CIUSs, with a quality control objective.
It should be noted that it is planned to apply the same principles and processes to extensions that are documented in a separate document.

Elektronische Rechnungsstellung - Teil 7: Methode zur Entwicklung und Anwendung einer Anwendungsspezifikation der Kernrechnung nach EN 16931-1

Dieses Dokument gilt für den Fall, dass eine CIUS als Spezifikation erstellt wird mit dem Ziel, sie in dem entsprechenden Register zu registrieren. Dieses Dokument legt auch Anforderungen für die Schritte fest, die in dem Prozess zur Erstellung von Anwendungsspezifikation der Kernrechnung (en: Core Invoice Usage Specification, CIUS) nach EN 16931 1 zu veranlassen sind. Darüber hinaus gibt dieses Dokument Leitlinien zur Erstellung und Implementierung einer CIUS vor.
Folgende Schwerpunkte werden behandelt:
-   Schritte, die berücksichtigt werden müssen, um eine unnötige Verbreitung und Fragmentierung in der Verwendung von CIUS zu vermeiden;
-   Leitlinien zur Erstellung und Implementierung von CIUS mit dem Ziel der Qualitätskontrolle.
Es sollte beachtet werden, dass die Anwendung derselben Grundsätze und Prozesse auf Erweiterungen, die in einem gesonderten Dokument dokumentiert werden, vorgesehen ist.

Facturation électronique - Partie 7 : Méthodologie pour l’élaboration et l’utilisation de spécifications d’usage de la facture de base structurées et conformes à l’EN 16931-1

Elektronsko izdajanje računov - 7. del: Metodologija za razvoj in uporabo strukturirane specifikacije uporabe osrednjega računa (CIUS), skladne s standardom EN 16931-1

General Information

Status
Published
Current Stage
6060 - Definitive text made available (DAV) - Publishing
Due Date
29-Apr-2020
Completion Date
29-Apr-2020

Buy Standard

Technical specification
-TS CEN/TS 16931-7:2020 - BARVE
English language
32 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

Standards Content (sample)

SLOVENSKI STANDARD
SIST-TS CEN/TS 16931-7:2020
01-julij-2020
Elektronsko izdajanje računov - 7. del: Metodologija za razvoj in uporabo
strukturirane specifikacije uporabe osrednjega računa (CIUS), skladne s
standardom EN 16931-1

Electronic invoicing - Part 7: Methodology for the development and use of EN 16931-1

compliant structured Core Invoice Usage Specifications
Elektronische Rechnungsstellung - Teil 7: Methode zur Entwicklung und Anwendung
einer Anwendungsspezifikation der Kernrechnung nach EN 16931-1
Ta slovenski standard je istoveten z: CEN/TS 16931-7:2020
ICS:
03.100.20 Trgovina. Komercialna Trade. Commercial function.
dejavnost. Trženje Marketing
35.240.63 Uporabniške rešitve IT v IT applications in trade
trgovini
SIST-TS CEN/TS 16931-7:2020 en,fr,de

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

---------------------- Page: 1 ----------------------
SIST-TS CEN/TS 16931-7:2020
---------------------- Page: 2 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
April 2020
TECHNISCHE SPEZIFIKATION
ICS 35.240.63; 35.240.20
English Version
Electronic invoicing - Part 7: Methodology for the
development and use of EN 16931-1 compliant structured
Core Invoice Usage Specifications
Elektronische Rechnungsstellung - Teil 7: Methode zur
Entwicklung und Anwendung einer
Anwendungsspezifikation der Kernrechnung nach EN
16931-1

This Technical Specification (CEN/TS) was approved by CEN on 15 December 2019 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to

submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS

available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in

parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

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

Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,

Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and

United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels

© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16931-7:2020 E

worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
Contents Page

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

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

1 Scope .......................................................................................................................................................... 5

2 Normative references .......................................................................................................................... 5

3 Terms and definitions ......................................................................................................................... 5

4 Compliance (Source: EN 16931-1:2017) ...................................................................................... 6

5 Premises ................................................................................................................................................... 9

6 Issues that should be considered to avoid unnecessary proliferation .............................. 9

7 Steps for the issuer of the CIUS ...................................................................................................... 11

8 Guidance on the creation and implementation of CIUS, with a quality control objective

................................................................................................................................................................... 12

9 Machine readable format ................................................................................................................. 14

Annex A (normative) W3C XML Schema for CIUS configuration ..................................................... 18

Annex B (informative) Example of CIUS configuration ...................................................................... 28

Bibliography ....................................................................................................................................................... 32

---------------------- Page: 4 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
European foreword

This document (CEN/TS 16931-7:2020) has been prepared by Technical Committee CEN/TC 434

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

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

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

According to the CEN/CENELEC Internal Regulations, the national standards organisations of the

following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,

Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,

Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of

North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United

Kingdom.
---------------------- Page: 5 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
Introduction

The European Commission estimates that “The mass adoption of e-invoicing within the EU would lead to

significant economic benefits and it is estimated that moving from paper to e-invoices will generate

savings of around EUR 240 billion over a six-year period”. Based on this recognition “The Commission

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

To achieve this goal, Directive 2014/55/EU on electronic invoicing in public procurement aims at

facilitating the use of electronic invoices by economic operators when supplying goods, works and

services to the public administration. The Directive sets out the legal framework for the establishment

and use of a European Standard (EN) for the semantic data model of the core elements of an electronic

invoice.

The semantic data model of the core elements of an electronic invoice, the core invoice model, is based

on the proposition that a quite limited, but sufficient set of information elements can be defined that

supports generally applicable invoice-related functionalities. The core invoice model contains

information elements that are commonly used and accepted including those that are legally required.

A “Core Invoice Usage Specification” (CIUS) is a specification that provides a seller with detailed guidance,

explanations and examples, as well as rules (business rules) related to the actual implementation and use

of structured information elements present in the core invoice model in a specific trading situation. An

instance document created following a given CIUS will always be compliant with the European Standard.

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

with the core invoice model in general, or with a CIUS, that is itself compliant with the core invoice model.

A sending party may claim compliance if he sends invoices that comply with the core invoice model,

including those issued in accordance with a compliant CIUS.

This specification aims to give guidance on the creation and implementation of a CIUS with a quality

control objective. Therefore it is necessary to define a clear set of criteria which a CIUS will comply with

before the CIUS can be registered in the appropriate registry. Some of these criteria will be validated

automatically while others are not.

To hinder excessive proliferation and to guide implementation, publication of CIUSs in a registry is

mandatory and the use of a machine processable format is recommended.
---------------------- Page: 6 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
1 Scope

This document applies in case a CIUS is produced as a specification with the objective of registering it in

the appropriate registry. This document also establishes requirements for the steps to be taken in the

process of creating Core Invoice Usage Specifications (CIUS) as defined in EN 16931-1. Furthermore, this

document provides guidance for the creation and implementation of a CIUS.
The following points are the focus:

— steps that need to be taken in consideration to avoid unnecessary proliferation and fragmentation in

the use of CIUSs;

— guidance on the creation and implementation of CIUSs, with a quality control objective.

It should be noted that it is planned to apply the same principles and processes to extensions that are

documented in a separate document.
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 16931-1:2017, Electronic invoicing — Part 1: Semantic data model of the core elements of an electronic

invoice

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

elements of an electronic invoice

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

3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp/ui
3.1
Core Invoice Usage Specification
CIUS

specification that provides a seller with detailed guidance, explanations and examples, as well as rules

(business rules) related to the actual implementation and use of structured information elements present

in the core invoice model in a specific trading situation
[SOURCE: EN 16931-1:2017]
---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
3.2
extension specification

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

defined in the core invoice model, or alterations that add functionality
[SOURCE: EN 16931-1:2017 and CEN/TR 16931-5:2017]
3.3
compliant invoice instance

invoice instance that respects all rules defined for the core invoice model, which could include the

specification contained in a compliant CIUS
[SOURCE: EN 16931-1:2017]
3.4
structured CIUS

CIUS that can be registered in the appropriate registry and therefore complies with the specifications in

this document
3.5
appropriate registry

registry defined by the CEN Technical Board with the task of implementing the requirements of a

European Standard when the said requirements involve the assignment and registration of unique,

unambiguous names according to the procedures described in the European Standard
4 Compliance (Source: EN 16931-1:2017)
4.1 General
Compliance to the core invoice model, can be measured at three levels:
— at the level of specifications;
— the actual implementation of a given sender or receiver;
— the individual invoice instance documents.
Each of these levels is discussed in 4.2 to 4.4.
4.2 Compliance of the core invoice usage specifications

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

themselves comply 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;
— the specification shall clearly state its issuer and responsible 'governor';

— the specification shall clearly state in what way the requirements of the CIUS differ from the core

invoice model, either by documenting the difference only or by specifically pointing out what the

differences are;

— the resulting invoice document instance shall be fully compliant to the core invoice model.

---------------------- Page: 8 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)

— 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 (the core invoice model as well as other

specifications that it may build upon);

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

CEN/TS 16931-3-1. See Table 1.

Table 1 — Allowed specifications in a CIUS as defined in CEN/TS 16931-3-1:2017, 7.3.2

Type of change Example/remark
Business Terms

Mark conditional Information element not to be used Can be achieved by changing cardinality 0..x to 0..0. This

essentially means that an element which use is
conditional is not to be used. This will not affect the
receivers processing. Care need to be taken to ensure
that the business rules defined for the core invoice
model are not broken.

Make semantic definition narrower A narrower semantic definition of a business term

means that the meaning conveyed is still within the
meaning defined in the core invoice model and is already
recognized by the receiver.
Add synonyms As synonyms will only supplement the original business
terms but do not replace it - the original term is still
normative. A receiver who has designed his processing
based on the core invoice model can continue to do so.
Examples of synonyms are mapping of national or sector
terminology to the terminology used in the core invoice.
Add explanatory text Adding explanatory text that, for example, explains how
a business term is used in a specific use case. There is a
risk is that such text may also affect the semantic
definition and this shall be avoided. Explanatory
information does not require any further action from the
receiver and the automatic processing of the assigned
invoice is still possible.
Cardinality

Make a conditional element mandatory (0..x – > 1..x) If a conditional element is made mandatory it simply

means that the option of using it is applied. The receiver
shall be prepared for the situation that a conditional
element is used, so he does not need to modify his
processing.

Decrease number of repetitions (x..n – > x..1) If the number of repetitions is decreased they will

remain within the limit that the receiver has catered for.
Semantic data type

Change semantic data type from string to ... If the semantic data type of a business term is changed

from string to some other type the receiver can still
process the value as a string.
---------------------- Page: 9 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
Type of change Example/remark
Codes and identifiers

Remove one of multiple defined lists Where the core invoice semantic model defines

more than one allowed list and the core invoice
usage specification reduces the number of allowed
lists then the invoice instance document is still
conformant. However such a change shall leave at
least one of the defined lists in place.

Mark defined values as not allowed If the allowed code values are restricted within an

existing list it simply means that certain values of
the full list are being used and the receiver should
have designed for processing them.
Business Rules

Add new non-conflicting business rule for existing Represents an additional restriction on the allowed

element(s) content within what is defined for the core invoice
model. The receiver should therefore have designed
for that content.

Make an existing business rule more restrictive The exchanged content of the business term

remains within what was defined for the core
invoice model and the receiver should have
designed for it.
Value domain for an element

Restrict text or byte array length If a maximum is set on the length where there was

no limit the content remains within what was
defined for the core invoice model.
Require defined structured values When the core invoice model does not set a
structure on a value the receiver would not have
designed for processing in any particular form.
Rules to enforce a given pattern should therefore
not affect his processing.

Restrict allowed fraction digits Fewer fraction digits result in a value that is within

the accuracy that the receiver would have designed
for when implementing the core invoice model.
4.3 Compliance of sending or receiving party

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

with the core invoice model in general, or with a CIUS, that is itself compliant with the core invoice model.

A sending party may claim compliance if he sends invoices that comply to the core invoice model,

including those issued in accordance with a compliant CIUS.
4.4 Compliance of an invoice document instance

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

core invoice model, which may include the specification contained in a compliant CIUS.

If an invoice instance document supports requirements that can be considered as a use of a CIUS, the

invoice instance document is still compliant to the core invoice model. These invoice instance documents

---------------------- Page: 10 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)

can still be received and processed by a party who is not supporting the CIUS because it still complies to

the rules of the core invoice model.
5 Premises

The CIUS has already been subject to extensive discussions, comments, decisions and actual

implementations, all of which shall be taken into consideration and contribute to the premises for this

work:

— CIUS as a concept is described in the EN 16931-1, together with the types of specifications and/or

restrictions that are allowed in a CIUS in order to ensure its compliance with the EN 16931-1;

— other reports generated within CEN/TC 434 and in the European Multi-Stakeholder Forum on e-

Invoicing have already made important recommendations on implementing CIUSs e.g. EMSFEI’s

“Recommendation on the use of ‘Core Invoice Usage Specifications’ (CIUS)”;
— the relationship with ongoing CEN/TC 434 standardization activities.
6 Issues that should be considered to avoid unnecessary proliferation
6.1 General

Various factors will influence the quantity and quality of CIUSs, and each of these should be discussed.

6.2 When should a CIUS be created?

Aside from considerations as to who can issue a CIUS, there is a need to consider when its issuance can

be justified.

The concept of CIUS is mainly to enable buyers to establish restriction specifications needed for correctly

processing the invoice and progressing towards payment. The buyers communicate to invoice issuers

which information they need and it is in the interest of suppliers to provide the information as required

by their customers.

In discussions on CIUSs the question has been raised as to whether simple specifications and/or

restrictions on the use of information elements composing the EN should be treated as a CIUS or whether

these are simply part of the contract between trading parties. The discussions indicate that there are

different views on when it is necessary to create a CIUS, but there seems to be a general consensus to

minimize the number of CIUSs and to recommend that a CIUS should only be considered if:

a) there is a strong business or legal requirement to further restrict or clarify the specifications in the

EN;

b) there is no existing CIUS that covers the requirement (e.g. a sector CIUS or a CIUS made available

through an infrastructure such as PEPPOL or a national platform);

c) the CIUS is likely to apply to a large number of trading parties within a grouping such as a public

sector, sub-sector of the public sector or a private sector community with common requirements;

d) the CIUS doesn’t create cross border trade barriers.
---------------------- Page: 11 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
6.3 Who can issue a CIUS?
The following parties, among others, may issue a CIUS:
a) CEN/TC 434 itself;
b) CEN National Standards Bodies (NSBs);
c) CEN/TC 434 Liaison Organizations;
d) member states;
e) bodies representing a public sector or business community;
f) national or European stakeholder fora;
g) national or European e-invoicing fora;
h) others (e.g. single buyer and single supplier).

Before mandating a CIUS, single buyers or suppliers should carefully consider whether there is a

sufficient business case and whether they can exercise sufficient impact or influence on their trading

partners to make the CIUS operative. This aspect is discussed below in the section ‘Steps for the issuer of

the CIUS’.
6.4 How to create a CIUS?

The tools and other help like templates and support that are made available to the issuer of the CIUS will

have impact on both the quantity and quality of the CIUSs.

An example of such a capability is an appropriate registry as specified by CEN/TC 434 where search

facilities will provide extensive information on individual CIUSs, their associated rules, practices and

minimum requirements.
6.5 Formalization

The degree of formalization will also strongly influence the degree of proliferation and render more

uniform the specification and the publication of a structured CIUS. This will make it easier for both issuers

and implementers of a CIUS to search, identify, compare, create and implement a CIUS. The list below

specifies the minimum degree of formalization:

a) as a minimum, a machine processable representation according to this specification with the

necessary information to identify and describe the CIUS shall be completed;
b) the CIUS shall be published in the appropriate registry;

c) any specific business rules shall be defined and listed with a unique identifier and, when appropriate,

validation artefacts shall be created;

d) simple instructions how to apply the CIUS shall be provided to facilitate the invoice preparation and

to avoid errors;
e) sample files shall be provided;

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

and for identification in processing.
---------------------- Page: 12 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)
6.6 Machine processable representation

The issuer of a CIUS shall create the machine processable representation as specified in the Annex. This

includes the creation and publication of related business rules to ensure that all information required for

processing the CIUS is available. The completion of the machine processable representation may also help

the issuer to reflect on the need for a CIUS.
6.7 Registry

A main benefit of an appropriate registry will be to make it easier for a user to search and sort the stored

artefacts, gain an understanding of the content, and then compare the component elements e.g. to see the

difference between existing CIUSs and/or a planned CIUS and establish whether an existing CIUS could

be completely or partially re-used. The more transparent the information the easier it will be to avoid

duplicates.
7 Steps for the issuer of the CIUS

In order to avoid proliferation a number of specific steps shall be considered by the prospective issuer of

the CIUS prior to creating a new CIUS. The following elements shall be considered.

a. Before creating a CIUS one shall:

— keep in mind that not registering a CIUS increases confusion and complexity in the marketplace

and potentially additional cost for all parties involved;

— consider the economic and other types of influence to mandate suppliers, such as responsibility

for a sector, sub-sector or trading community;

— check if the publication of the CIUS is in line with competition or other laws and regulations;

— keep in mind that mandating a CIUS requires extra effort to create, maintain and publish it;

— consider whether the added value in processing invoice instances is sufficient to justify the

effort;

— keep in mind that the rules applied could potentially create confusion instead of solving issues;

— keep in mind that mandating a CIUS in order to comply with (local) legislation or policy is like

creating rules that one has to comply with. Such a CIUS runs the risk appearing to create new or

different rules and even create confusion.
b. Consider if the intended CIUS is a threat for interoperability.
c. Check if a CIUS covering the needs already exists:
— check the available resources to see if an existing CIUS may cover your needs;

— contact the responsible persons or entity for an existing CIUS that actually or substantially covers

the needs to check if collaboration can be achieved.
d. Before creating a new CIUS consider what is the maximum reach of the CIUS
— consider what the largest reach and number of users is for the CIUS;
---------------------- Page: 13 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)

— contact the authority responsible for the sector, country or other group of users of this largest

reach;
— check if collaboration or support is available at the largest reach possible;
— if a large reach is not feasible, only then consider your own CIUS.

e. The necessary resources (human, technical, budget) shall be available to support the creation and

maintenance
— bear in mind the effort to create, maintain and publish the CIUS;
— bear in mind to clearly inform customers and/or suppliers;
— check if the back-office systems or processes require enhancement or adaption;

— consider a backup plan in case customers and/or suppliers do not respect the CIUS request;

— bear in mind the various types of requests from different types of user;

— define what type of support to give free of charge to the market as a CIUS publisher (e.g. FAQ)

and the type of support belonging to the competitive space (e.g. consultancy).
f. Make sure to publish the CIUS
— publish it on the appropriate registry;
— publish it on the national authority website if available;
— inform customers and/or suppliers so they have access;
— publishing it will allow reuse of your CIUS.
8 Guidance on the creation and implementation of CIUS, with a quality control
objective

The purpose of a CIUS in a broad sense is to clarify how certain information elements in an invoice

instance shall be used, for example by further restricting, mandating or specifying how elements shall be

used. It is obvious that the documentation describing the CIUS shall contain all information for the

stakeholders involved. The nature of the stakeholders may require various levels and types of

information. Some information will be more explanatory while other may be more technical.

At the same time avoiding proliferation, ease of use and reuse of the CIUS is as important as the specific

quality of a CIUS itself.
To achieve the various goals described above, it is necessary that:
— the documentation is presented in a structured and easy to use way;
— the documentation is partly human and partly machine readable, as appropriate;

— the documentation meets quality criteria, for example specified in the appropriate registry;

— the CIUSs are listed in the appropriate registry.
---------------------- Page: 14 ----------------------
SIST-TS CEN/TS 16931-7:2020
CEN/TS 16931-7:2020 (E)

The necessary tools and procedures available facilitate the creation/maintenance of a CIUS. These tools

and procedures will evolve over time to address the necessary requirements at the given time. Below you

find an overview of tools and procedures.
a) Make sure you use the correct notation for the CIUS specification identifier.
A CIUS specification identifier shall be structured as follows:
SourceSpec#compliant#TargetSpec
— SourceSpec shall be the core invoice model.

— Conformance states how the changes relate to the SourceSpec, using TOGAF terminology.

— TargetSpec are the identifiers for the extension specification itself and the extension specification

or core invoice usage specification that it builds on.

The TargetSpec and the SourceSpec shall be identified by giving a uniform resource name (urn). The

identifier for the European Norm is to include its EN number (EN 16931-X:2017)
For clarity, the main part
...

Questions, Comments and Discussion

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