Navigating the documentation

The European standard on eInvoicing consists of several documents forming six main parts, each addressing a specific subject. The different parts are collectively referred to as a standard, even though some are technical specifications or reports.

Semantic data model

The main part of the eInvoicing standard is the specification of the core invoice model which has the status of being a European standard (EN). This part, known as the semantic data model, lists the business terms of a core invoice, defines the meaning of these terms and sets rules on how they shall be used. When complying to the eInvoicing standard all requirements of part 1 must be met.

Syntax binding

The second and third parts of the European eInvoicing standard address the binding of the eInvoicing standard's semantic data model to the information elements in a particular message syntax.

Part 2 evaluates four syntaxes against Criteria provided by the European commission. This is to support article 3(2) of Directive 2014/55/EU on electronic invoicing in public procurement where it is stated that " The Commission shall request that the relevant European standardisation organisation provide a list with a limited number of syntaxes which comply with the European standard on electronic invoicing". Article 7 of the same Directive states that " Member States shall ensure that contracting authorities and contracting entities receive and process electronic invoices ...  with any of the syntaxes on the list published pursuant to Article 3(2)".

The conclusion of part 2 is that two syntaxes meet the criteria, UBL and CII, which then form the "list" referenced in the Directive. This means that public entities that fall within the scope of the Directive must be able and ready to receive and process invoices by using both of these two syntaxes on this list.

The requirement to be able to receive eInvoices in these two syntaxes is set by Directive 2014/55 so it applies to those organizations and entities who are in scope for the Directive, which are public organizations and entities but not to private ones. Private entities that are not trading with public entities can comply with the eInvoicing standard by using other syntaxes and public entities may also accept other syntaxes as long as they also accept the two syntaxes listed.

Part 3 defines the methodology for syntax binding of the semantic model and then applies that methodology for the two syntaxes on the list in part 2. In addition it applies the methodology to syntax binding for EDIFACT. For public entities this means that they must accept UBL and CII by using the syntax bindings provided in parts 3-2 and 3-3. If, in addition, they wish to receive EDIFACT, they must then use the syntax binding provided in part 3-4.

Parties who wish to comply with the semantic data model by using another syntax will have to create their own syntax bindings following the methodology defined in part 3-1.

Transmission

The European standard on eInvoicing addresses the issue of transmitting the electronic invoices with a guideline (report) that identifies issues that a suitable transport solution should address, and makes recommendations. The guideline does not set any compliance criteria for transmission solutions but is aimed to support implementers in selecting and designing their transmission solutions.

Extensions

Extension do not comply with the standard semantic data model and are therefore specified in a separate guideline (report). The report defines the concept of extensions, lists allowed amendments and sets criteria for documenting extensions. This mirrors the specification of Core Invoice Usage Specifications (CIUS) given in chapter 7 of part 1 of the eInvoicing standard. Because it is documented within the standard, the use of a CIUS is a compliant implementation of the eInvoicing standard while an extension is not.

Testing

The standardisation request made to CEN to develop eInvoicing standard stated that the finished standard should be evaluated against the requirements that were made in the request, most importantly against requirements mandated in other EU legislation. This part tests this and reports on the results. It may thus be useful reading for those wishing to see how these requirements are fulfilled.