An extension for EN16931
Following the last exchange summit in Lisbon, the presentation of the French CTC and B2B mandate reform has shown the need for extension to the EN16931 in order to address 100% of B2B domestic e-invoices, but also to reach CTC objectives, especially on VAT return pre-filling.In order to better understand, we have to come back on how the EN16931 was created. Indeed, EN16931 was built following the 2014/55/EU which is focused on e-invoicing in public procurement, under a constraint to mandate any public sector entity of EU members to accept e-invoices sent in the respect of the EN16931 under their UBL and UN/CEFACT CII syntax implementations.
Even if the EN16931 was built with inputs from B2B needs, it remains a Standard which was not designed to address 100% of invoices, but most of them : a “Core e-invoice standard”. As an example, a strong hypothesis was taken to exclude multi delivery or multi purchase order invoices, which do exist in real life. Furthermore, the EN16931 standard was designed only to replace the paper invoice with an electronic invoice to automate its processing, but without taking into account the end-to-end invoice process, whether it is the rules of accounting for invoices on both sides, the treatment of VAT for specific use cases (such as a prepaid invoice followed by a final invoice), the existence of third parties who could play a role in the invoicing process and be identified in order to organize the access rights to the invoice. Likewise, no fiscal and accounting experts or TAXUD were involved in the working group in charge of the EN16931. It is not surprising then that we discover some missing elements when we add Digital Reporting Requirement extracted from e-invoice exchange.
It does not mean that we should have done differently. Starting with a simplified perimeter was the best way to have a concrete result with EN16931, knowing that the goal was to create a Core Invoice Standard for the more common use cases, under an obligation to accept it by all public sector entities. Taking in account all specificities would have forced any public entity to be prepared to accept e-invoices for any potential use case. This is why the EN16931 was designed with a concept of CIUS, which allow to “restrict” the EN16931 for countries or communities which need to do it, and with EXTENSION which can be used to extend the EN16931, with NO obligation for any public entity to accept EXTENDED e-invoices.
However, when it comes to an obligation to send 100% e-invoices, it is easy to understand that it is then not possible to consider that all business use cases have to adapt to a simplified Core Invoice. In addition, after an inventory of the more common use cases as we did in France, we have seen that some invoice information are also missing to the EN16931 in order to address an automatic VAT Return prefilling coming from the invoice exchange flows (DRR).
The first idea was then to ask for an EN16931 evolution, which the French Tax Administration did to TC434 this year. However, it came quite late in the process which has already taken 2 years to have a list of 50 potential marginal evolutions. But the main difficulty is that add new business terms, use cases and business rules to the EN16931 could force all public entities to have to accept them. This is a critical issue which in practice restricts the evolutions of the EN16931 Standard to the minimum acceptable by ALL Member States for their respective public sectors.
Then, the only reasonable path is to work on an Extension to the EN16931, adding what is needed to address 100% of invoices and use cases, with no obligation of the public sector entities to accept invoices with extension. This is what France is working on, using UBL and UN/CEFACT SCRDM CII syntaxes on top of their EN16931 implementations, based on what was already been worked with French and German e-invoicing forums on UN/CEFACT CII for Factur-X / ZUGFeRD EXTENDED profile.
This will also be part of the DCTCE POC for France and we hope it will also participate to the EU ViDA thoughts.