As you know (or perhaps you don’t ), electronic invoicing will come into force in France in September 2026. The generic term “electronic invoicing” covers two obligations
E-Invoicing: this concerns the receipt and issuance of invoices between entities subject to French VAT (of course, there are a few exceptions here too)
E-Reporting: for all other operations, including, in short, transactions with individuals, European and international companies.
This reform will be implemented gradually:
September 2026: all companies must be able to receive electronic invoices. Only large companies and medium-sized companies are affected by the issuance of electronic invoices.
September 2027: The obligation to issue electronic invoices extends to all companies (including micro-entrepreneurs).
In order for Tryton to continue its implementation in France, it is essential that it provides the necessary means to meet this obligation. Tryton already has some of the necessary building blocks, primarily the UBL Invoice-2 and UN/CEFACT formats. However, adjustments will need to be made to comply with the chosen format.
I must say that I’m a little bit lost with the French requirements (which seems to change every months).
Normally these electronic invoices are coming to all European countries via ViDA. So they should be quite similar.
It seems that the French requirement is based on the Peppol network but you can not use any access point but only those accepted by the government (aka PDP).
So for me it looks like it just requires to create a module like edocument_peppol_peppyrus but for a PDP.
That was true, but now things are stabilizing, and AFNOR standards are contributing greatly to this. However, even though PDPs must provide an interface that meets these standards, this is not yet the case for all of them.
I don’t know how the implementation of this directive will change anything. For the moment, invoices from European countries are processed by E-Reporting. In summary, E-Reporting must report bank transactions recorded every 10 days maximum to the PA (formerly PDP).
It is a recommendation (not a requirement) from the government that PAs communicate with each other via the Peppol network. This will undoubtedly be implemented, but it does not directly affect Tryton, as it must communicate with the chosen PA, normally in accordance with the AFNOR standard if the PA has implemented it. I think we should stick with this implementation but allow for extensions to the use of other PA APIs.
As stated in their presentation: “The SUPER PDP API allows developers to programmatically send and receive invoices in compliance with France’s electronic invoicing reform, and more generally within the Peppol network.” It only refers to sending and receiving electronic invoices, not E-Reporting at this stage. E-Reporting corresponds to flow 10 of XP Z12-014 below.
Ideally this should be implemented for the 8.0 release in 2 months.
But I think it will be complicated without having a working implementation of the protocol (sending invoice and e-reporting) to test.
So I think someone should contact SUPER PDP to have better schedule.
On a personal note, I find the timeline for such requirement very short. In Belgium the requirement started this year on 1st January 2026 but things have been settle about 4 years ago and was usable also many years before the requirements. And even with all of that it is still a mess.
The standard provides some examples of the different flows. I can provide others to test some of the flows as soon as a version is available for testing.
SUPER PDP was contacted by the PDPLibre association (of which I am a member) and they assure us that the AFNOR API will be available in a month. However, I have my doubts.
I contacted another PDP: https://www.esalink.com/, which is much more expensive but has the AFNOR API available and which we can use for testing (I have a test account).
I completely agree with you, and I know that this is going to be a huge source of problems, but we have no choice.
I don’t think Tryton should choose one PA over another, but simply implement the AFNOR API, test it with several PAs (which provide the AFNOR API), and let users choose the one that suits them best.
For the moment, I only know of Esalink, who responded to me and are responsive to technical questions. And there’s nothing stopping us from testing the dev on SuperPDP when their API becomes available. I can also try to find a third one that would allow us to run tests.
I doubt that the AFNOR API will bring real interchangeable provider for few reasons. First they describe it using the Swagger format and from experience it is often not precise enough to guarantee an completely defined behavior. And second the devil hides in the details, each implementation will have corner case and specific behavior. Finally the size of the norm (I have not read it fully) is so small that I’m pretty confident that it is not an exhaustif description.
Now I guess it will be better to implement a unique module but each provider will need to be carefully tested before being added. So we will be able to share most of the code but I’m pretty sure there will be some edge case for each providers.
So we will need PA that provides a sandbox environment on which we can plug the CI. And preferably one that does not require contact via form etc. to create such sandbox environment.
), electronic invoicing will come into force in France in September 2026. The generic term “electronic invoicing” covers two obligations