Compliance with the European standard on eInvoicing
Explaining the standard
A key objective of the European standard on eInvoicing (EN) 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 on eInvoicing defines the core elements of an electronic invoice in a semantic data model. The definition of the semantic data model is documented in part 1 of the European standard includes a list of all business terms that may be used in a compliant invoice, and defines how they shall be understood and used. The core invoice includes common business terms and business rules that enable trading partners to exchange structured electronic invoices in general trade circumstances. The eInvoicing standard defines the semantics of the core invoice data model. The semantic model can then be bound to a message syntax to create structured messages that can be exchanged and automatically processed.
The following video explains some key concepts in the European standard on eInvoicing.
Semantic data model
The main publication of the European standard on eInvoicing is the semantic data model (EN 16931-1) and its business rules.
When exchanging information between two parties, the following considerations must be addressed so that the exchange succeeds.
- The information exchanged must be relevant to the situation. It needs to include what is needed and should leave out what is not.
- The meaning of the information must be understood in the same way by both parties.
- The information must be expressed in a format that both parties understand.
- The information must be exchanged using a method that both parties can access.
When taking the example of a paper invoice, the invoice must contain amounts, text and dates allowing the buyer to process it and pay as the seller expects. To do so, the buyer and the seller must have the same understanding of the information printed on the invoice such as the different amounts, dates and references. This invoice is printed on a paper in a language that both parties understand. Finally, it is sent by a postal service that both parties can access.
When humans exchange information in this way they can usually, to some extent, draw on the experience and common knowledge to adjust some information inaccuracies or fill in certain gaps. When the same information is exchanged between computers for automatic processing it must, however, be defined more precisely because computers are not as flexible in “understanding” information.
The EN defines a core invoice data model that contains information commonly used in invoices and is sufficient for most invoice exchanges. It then defines the exact meaning of the business terms used in that model. This data model is called the core invoice data model. It is a semantic standardisation that defines the invoice content and the meaning of that content.
The EN does not define the technical structure (syntax) of the electronic invoice but instead uses two international XML message standards to carry the information defined in the core invoice data model. The European standard specifies how the information in the core invoice must be mapped into each message standard. The syntaxes supported are the UBL 2.1 Invoice message and the UN/CEFACT Cross Industry Invoice (CII) message.
The example below explains the relations between the semantic data model and the syntax binding.
An example of syntax bindings
The semantic information model in part 1 of the European standard on eInvoicing defines business terms and assigns an identifier to each of them. That identifier can be used to trace how the business term is bound to the relevant syntax. The following example shows business term BT-27 (Seller name) and how it is bound to the UBL and the CII syntaxes.
Semantic information specification (Defined in EN 16931 part 1)
The seller name is defined in the standard invoice core as follows.
|Business term:||Seller Name|
|Definition:||The full formal name by which the seller is registered in the national registry of legal entities or as a taxable person or otherwise trades as a person or persons.|
|Cardinality:||1..1 (meaning it must appear at least once (1..) and at most once (..1)|
In an electronic message, the seller's name would be provided as follows.
Syntax binding to UBL (Defined in EN 16931 part 3.2)
Syntax binding to UN/CEFACT (Defined in EN 16931 part 3.3)
When the sellers name is read from a message using either syntax it should be understood according to the definition in the standard.
When a seller creates an eInvoice document it is mandatory for them to ensure that the content of the messages complies exactly to the specifications of the EN. This obligation is expressed in the compliance requirement of the standard. This exact compliance is necessary for the buyer to automatically receive and process the invoice into their accounting system, without manual intervention.
To aid in ensuring the compliance of each invoice instance a set of technical validation artefacts has been created. These enable the seller to test invoices against the standard, both during development (design-time) and in operation (run-time).
Amendments/Revisions to the European standard on eInvoicing
The European standard on eInvoicing (EN 16931) was developed and published by the European Committee for Standardization (CEN), at the request of the European Commission. Requesting amendments and/or revisions to the standard (EN 16931) and supporting documents can be done using the CEN procedure for maintaining deliverables. Any request made via CEF Digital's Service Desk which relates to a request for amendment or revision to the standard will be forwarded to CEN using the same procedure.
In the section, we refer to is:
"1.1 The CEN Members, the TC, the EC, the EFTA Secretariat, the international or European trade organizations, professional, technical or scientific organizations send a request for an amendment to an existing EN to the appropriate TC via the TC Secretary."