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.
Even if the reasons you mentioned are technically correct, I think the following points should also be taken into account:
The change in PA is provided for in the finance law
It is possible to use several PAs (for example, one for sending and another for receiving)
The PA is more than just an entry point for sending and receiving invoices; it must also transmit information to the tax authorities and therefore enable the management of the invoice lifecycle.
The very short deadline for having something functional
For all these reasons, I think Tryton should instead implement the AFNOR standard and allow, through additional modules (official or otherwise), customization for PAs that do not fully comply with the standard or that have interpreted its shortcomings differently.
Given the very tight deadlines, I wonder whether it is necessary to wait for the AFNOR API for SuperPDP to become available, or whether we should start working with the PAs that have implemented this API (with its shortcomings and inaccuracies), even if we do not have access to their sandbox as you would like. I can provide documentation and access to the Esalink API, and I am continuing to review the referenced PAs to find others that could provide me with this information.
For me it is not a requirement. The requirement is to have a PA with a testable/sandbox API that can be integrated in the CI.
As maintainer I can not accept in standard modules that can be tested.
And by experience testing external API only with Mock is not a enough to ensure the correctness of the implementation.
For me Easlink is not the kind of provider with whom we can work. We have rejected many Belgian Peppol AP for the same reason because they do not provide a clear/open API, sandbox environment etc.
I personally see them as businesses that take the opportunities of the new legal requirements to attract new customers for their main business. And thus often the attracting service is not as interesting as it seems.
), electronic invoicing will come into force in France in September 2026. The generic term “electronic invoicing” covers two obligations