PEPPOL, was designed to support the european eInvoicing interoperability. Used as e-Invoicing standard by many member states, since has disseminated over the World and was adopted by countries like Singapour, Australia, New Zealand and more recently Japan. France accepts invoices from PEPPOL in B2G to Chorus Pro. With the coming mandate based on a federated model of registered service providers connecting to each others, the acute question of interoperability comes back again.
The french B2B mandate starting 2024 onward, has introduced the so called « Y »model where e-Invoicing and e-Reporting can be carried out following three ways:
- through the centrally managed gateway (PPF) an evolution of Chorus Pro
- through a dematerialization partner (PDP) a registered e-Invoicing service provider carrying out e-Reporting on behalf of the tax authority
- A third mode that would involve a combination of 1 &2
The article 242 nonies I of the decree 2022-1299 of october 7 makes obligation to an immatriculated service provider (PDP) to reach any recipient regardless of its position in the network and to ensure that interoperability can be achieved in two ways : « partners of dematerialization (PDP) and the public portal of invoicing (PPF) ensure the interoperability of exchanges by resorting to a bilateral interoperability agreement or a network information exchange protocol ».
How interoperability can be achieved ?
If interoperability is established by bilateral agreements, the number of potential setup would grow dramatically as well as the cost of enablement. For an estimated number of 90 service providers acting as PDP (latest estimation) the number of connections [N=n(n-1) /2] would be, 4005. A reason why the decree has specified that interoperability can also be achieved by implementing « a network protocol ».
PEPPOL offers such a capability. Designed as an overarching architecture based on CEF e-Delivery components (the EU transport infrastructure) PEPPOL makes possible the exchange of e-Invoices (or others procurement messages) through access points. PEPPOL brings a SMP/SML automatic discovery capability for locating any recipient in the network. EESPA EIN uses the same method of communication.
For appraising the potential of PEPPOL and EESPA to solve out that acute question, the French Forum (FNFE) has decided to initiate a Proof Of Concept.
We as TACD CARTENA have joigned the workgroup with Cyrille SAUTEREAU head of FNFE, Didier Lombard PEPPOL and Michel Gillis EESPA to gather businesses requirements make a gap analysis and contemplate a pilot in mid 2023.
What are the key findings ?
It looks like PEPPOL could match most of requirements and a full alignment remains achievable. Nevertheless, to embrace the entire complexity of model looks ambitious and would require some adjustments. Because many enterprises are not PEPPOL users, the communication will not be PEPPOL all along the line. This would probably lead some PDP to cover the last mile and deliver invoices or statuses to the end users (as C1 and C4) using a different protocol than PEPPOL.
First, PEPPOL would provide the SMP discovering capability in link with the National Directory. A sending PDP will discover the end point by their SIREN or SIRET ( as scheme ID) in link with the PDP associated. This would be done considering 3 options : 1- synchronizing the directory to an external SMP or 2- lodging answers from the SML somewhere in the directory or 3- assigning to every recipient into the directory a new scheme ID with electronic address linked to PEPPOL ID. In absence of a central SMP owned by the French authority, an update of the registry would be done by synchronization to the central and replication in every PDPs’ SMP. Any modification into one SMP would be automatically propagated to the entire network in less than 24H.
Secondly, PEPPOL will enable connectivity between PDP’s (as corner 2 and corner 3 in the 4 corners model) and provide the transport capability to any invoice regardless of the format (UBL, UNCEFACT CII or FACTUR-X) . A first way, would be to use PEPPOL BIS minimal format as envelop conveying the invoice itself, a second way to use PEPPOL BIS 3.1 in full extended format and conformant to the EU 16931 eInvoicing norm. This would entail some extensions of the format for alignment to the french requirements.
Thirdly, the feedback of statuses will use the same channel. France is working on CDAR, a lifecycle status message designed to cover a large array of use cases. In comparison, PEPPOL BIS Invoice Response 3.1 equivalent to CDAR is a more straight forward message. Even if it implements different code list, the gap has shown that alignment is achievable because messages are quite similar in their structure.
And now, what’s next ?
Regarding governance, the idea is not to make PEPPOL or EESPA EIN a mandatory network protocol but an interoperability option that would not ban other solution. Even if the tax authority (as corner 5) is absent and do not play any role in the pilot at this stage, nothing would impeach the central administration to join the experiment at any time. The question of using a central SMP replicating the central directory would of course be something. But we know that this decision has to be taken at the administrative level. And of course, nothing happens without good reason…!