Page tree

eInvoicing standard compliance


1. Explaining the standard


A key objective of the European standard on eInvoicing 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 and includes a list of all business terms that may be used in a compliant invoice, and also defines how they shall be understood and how they shall be 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 eInvoicing standard.

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.

Take the example of a paper invoice. .The invoice needs to contain the amounts, text and dates that allow the buyer to process it and then pay as the seller expects. To do that, the buyer and the seller must share the same understanding of the information printed on the invoice such as the different amounts stated, dates and references. The paper invoice is printed on a paper in a language that both parties understand. And finally, it is sent by a postal service which both parties have access to.

When humans exchange information in this way they can usually, to some extent, draw on experience and common knowledge to adjust for some inaccuracy in the information 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 European standard 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 standardization since it defines the invoice content and the meaning of that content.

The European standard does not define the technical structure (syntax) of the electronic invoice but instead uses two international XML message standards that were recognized to be able to carry the information defined in the core invoice data model. The European standard specifies how the information in the core invoice is to 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
Term ID:BT-27
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 sellers name would provided as follows.

Syntax binding to UBL (Defined in EN 16931 part 3.2)

<Invoice>
    <cac:AccountingSupplierParty>
        <cac:Party>
            <cac:PartyLegalEntity>
                <cbc:RegistrationName>Seller name</cbc:RegistrationName>

Syntax binding to UN/CEFACT (Defined in EN 16931 part 3.3)

<rsm:CrossIndustryInvoice>
    <rsm:SupplyChainTradeTransaction>
        <ram:ApplicableHeaderTradeAgreement>
            <ram:SellerTradeParty>
                <ram:Name>Seller name</ram:Name>

When the sellers name is read from a message using either syntax it should be understood according to the definition in the standard.

Validations

When a Seller creates an eInvoice document it is required that he ensures that the content of the messages complies exactly to the specifications of the eInvoicing standard. This requirement is expressed in the compliance requirement of the eInvoicing Standard. This exact compliance is necessary for the Buyer to automatically receive and process the invoice into his accounting system, without manual intervention.

To aid in ensuring the compliance of each invoice instance a set of technical validation artifacts has been created. These enable the Seller to test invoices against the eInvoicing standard, both during development (design-time) and in operation (run-time).


Next >

Navigating the documentation