CIUS and Extension - What is allowed

A key objective of the European standard on eInvoicing (EN16931) is to make it possible for sellers to send invoices to many customers by using a single eInvoicing format and thus not having to adjust their sending and/or receiving to connect with individual trading parties. To achieve this the European standard defines a core invoice data model that a buyer must be able to receive in order to be compliant to the standard. This data model includes more options than are typically used in a single invoice. But if a buyer receives the core then any seller who sends an invoice that falls within the core can be sure that the buyer will process that invoice.

The European standard does take into consideration that buyers who must support specific processes or legal requirements may need to restrict the core data model or they may need to extend the core. The European standard provides for this by defining Core Invoice Usage Specification (CIUS) and Extensions.

CIUS

A buyer can be compliant with the eInvoicing standard by supporting the reception of a CIUS. Specifications on how a CIUS is defined and documented are provided in EN16931 part 1 chapter 7. As an overview the criteria for a compliant CIUS are the following.

Allowed amendments

A compliant CIUS may only contain one or more of the following amendments made to the core invoice specification. If the core invoice model contains one or more amendments that are not on the following list then it is not a CIUS. If such additional amendments are allowed for an extension then it is an Extension. A CIUS may:

• Mark a conditional business terms not to be used
• Make semantic definition of a business term narrower
• Add synonyms (in English or in other languages)
• Add explanatory text to a business terms (e.g. on how it applies in specific use cases.)
• Make a conditional business term a mandatory one (0..x – > 1..x)
• Decrease the number of repetitions allowed for a business term. (x..n – > x..1)
• Change semantic data type of a business term from string to some other data type (e.g. instead of giving a date as string it can be given as structured date)
• Remove one of multiple defined code lists allowed for a code element
• Mark some defined code values as not allowed
• Add new non-conflicting business rule for existing element(s)
• Make an existing business rule more restrictive
• Restrict text or byte array length
• Require a defined structured for values
• Restrict the number of allowed fraction digits

Documentation of a CIUS

A CIUS should be documented in a way similar to the European standard and meet the following requirements:

• Give a clear reference to the core invoice model. This may be in more than one step (that is, CIUS A may restrict the core and a CIUS B may further restrict CIUS A but the full path to the core shall be clear)
• It may document the change from the core invoice model only or it may be documented the CIUS specification in full, in which case the change from the core invoice model must be listed clearly
• There should be a commercial agreement between the buyers and sellers on using a CIUS but that agreement may be indirect
• A CIUS shall have an assigned identifier which shall be stated as Specification identification in invoices that comply to that CIUS
• A CIUS should be made available for retrieval and sharing in an appropriate repository
• Specification and restriction in a CIUS shall be mapped to a syntax using the same syntax binding methodology as used for the core invoice model and is documented in 16931 part 3-1

Extension

Buyers and sellers can agree on using extended specifications of the eInvoicing standard to support specific business requirements that are not supported by the eInvoicing standard. Guideline on using an extension and methodology for applying them is documented in EN16931 part 5. However, a buyer who only accepts an extended eInvoicing standard is not compliant to the standard. To be compliant he must also accept the core invoice model or a CIUS. An extended invoice is not compliant to the eInvoicing standard and a seller who send extended invoices can not expect those who are compliant to the standard to be able to receive and process such extended invoices. The use of extended invoices must be based on bilateral agreement between buyer and seller.

Allowed amendments in an extension specification

One or more of the following amendments may be made in an extension. In addition an extension may contain one or more amendments that are allowed in an CIUS's.

• Add new business terms
• Widen the semantic definition of a business term
• Increase number of repetitions for a business term (x..1 – > x..n)
• Add a new code list to a code element
• Add codes to a defined code list
• Remove an existing Business Rule
• Make an existing business rule less restrictive
• Increase element length
• Change structure definition of values
• Increase allowed fraction digits

Documentation of an Extension

To be conformant to the extension methodology of the European standard an extension must fulfill the following requirements.

• The specification shall state its underlying specifications and their version
• 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 syntax binding of a specification shall follow the syntax binding methodology defined in 16931 Part 3-1

The eInvoicing user community maintains a list of ongoing and planned initiatives across Member States, Additional European Economic Area (EEA) countries or sectors to create CIUS and extensions on the European standard on eInvoicing.