Follow-up to the e-invoicing reform
Sommaire
Walid : hello and welcome to Projets Libres, LinuxFr.org’s podcast, which talks about free software, open data and digital commons. I’m Walid Nouh and today, I’m very happy, I have three guests with me with whom we’re going to do a follow-up episode on electronic invoicing. If you want to know more about the subject, I invite you to go listen to episode number 1 of season 4. In which we discussed the subject of e-invoicing and its implications on the Dolibarr community and on the OCA community, the Odoo Community Association.
And so today, I’m delighted, with me, I have three guests: Philippe Scoffoni, who is president of the PDP Libre association, we’ll tell you more about it later, and member of the Dolibarr community, Maxime Kohlass, who is founder of ATM Consulting and president of the Dolibarr Association. And Alexis Delattre, who is an Odoo developer at Akretion and a member of the OCA, the Odoo Community Association.
Presentation of the guests
Welcome to all three of you. I’m delighted to be able to do a follow-up episode with you, on where we are on this magnificent subject. For the usual presentation of the guests, we’re going to make it very simple for Alexis and Philippe, if you want to know much more, I invite you to go and listen to the first episode. I’m just going to let them have the floor for two minutes so that they can introduce themselves a little more succinctly. And Maxime, listen, you, it’s the first time you’ve been on the podcast, so welcome and I’ll let you start by introducing yourself. Who are you and how did you find out, when did you discover Dolibarr?
Maxime: Thank you very much for the invitation. I’m Maxime Kohlass. I have been the creator of ATM Consulting since 2012, based in Valencia. We are an integrator of the Dolibarr solution. We have been making Dolibarr exclusively for all this time. We are a team of 25 people and we work throughout France. I discovered Dolibarr, I would say, around 2010, in my first professional experience, where I was already associated with a former colleague at the time, we were a service provider for Veolia’s IT department.
We had to invoice for our services. I discovered Dolibarr at that time, I saw that it was nice. And so, two years later, when I wanted to create my company, the choice of Dolibarr was quickly made to integrate this open source solution.
Walid: ok, and you knew free software before Dolibarr?
Maxime: Yes, because in this first job as a service provider at Veolia, we had a big project revolving around CRM. I had just finished my studies at the time. And so, in order to be able to do a bit of proof of concept in this CRM project, we based ourselves at the time on SugarCRM, which is an open source software that we tested a little bit in all directions, to see what the capabilities of the software were and to see if it met Veolia’s needs at the time. Well, the management chose to go with another proprietary tool, but at least the entire POC was done on open source.
Walid: ok, thank you. Philippe, do you want to introduce yourself quickly?
Philippe: yes, hello, thank you for this new invitation. Philippe, today, I’m here with my hat as president of an association, PDP Libre. We may take a little more time later to talk about it. I am also an integrator of Dolibarr via my company OpenDSI, since 2012, today.
Walid : All right. And Maxime, on your side?
Alexis: I started open source with the VideoLAN project, whose most famous component is VLC Media Player. When I was a student. And then I’ve been working on Odoo since 2008, first for my company, and then, in 2010, I became an Odoo integrator, with, a few years later, the creation of Akretion. And in the Odoo Community Association, I have always been active on the modules that touch on accounting in the broad sense, i.e. accounting, banking, electronic invoicing, customs, and, therefore, naturally, on the reform of electronic invoicing.
In my achievements, a bit on the subject of the reform of electronic invoicing, I was even the first to implement the Factur-X standard in a management software. This was back when the Factur-X standard was still in beta. And then, another of our achievements was that with one of my clients, we were the first to submit a Factur-X invoice on Chorus Pro. That was in 2018. And that’s it, at the time, we were really at the beginning of the Factur-X standard. And then, then, there was the reform. And so, I am active on the development of Odoo modules for the reform of electronic invoicing.
Regulatory changes
Walid : ok. We are not going to redo the entire history of electronic invoicing, where it goes, etc. All this, I really invite you to go and listen to the first episode. Today we’re going to focus on what has changed since this first episode, since now, you are all in the implementation phase. So, the first thing I would like is for us to explain, have there been any regulatory changes in the last few months on this subject and has it impacted you in any way?
Walid: Alexis, do you want to start, maybe?
Alexis: So, the main changes are in the 2026 Finance Bill Bill, where, for me, there were two important things in this Finance Bill. The first important thing is that it was the last window of opportunity to possibly change the calendar. Because, as it is written into the law, if they want to change the timetable, they have to go through the law. And so potentially by the finance bill, that was it.
In the end, the fact that they did not touch the timetable in this finance bill was confirmation that the reform would start on September 1, 2026. They still have the possibility by decree to postpone the date by 3 months by simple decree. So that was finally a confirmation that did not affect the calendar.
The second important thing in the 2026 budget bill: they had decided to abandon the public invoicing portal, the public portal managed by Bercy [French Ministry of Finance], which was to allow companies that did not want to pay a private service provider to be able to deposit, receive, send and receive their invoices free of charge. The tax authorities had decided to stop this project, probably because it was a software shipwreck in terms of development. That’s what happened. Even if they had a little trouble admitting it.
In the law, this free public portal was still mentioned. So, it was still necessary to remove the legal texts that referred to this free portal because they had not done so in the 2025 PLF. They effectively removed everything related to the free solution provided by the state. Then, there is another important thing of the PLF 2026, which is that at the time when there was the public invoicing portal, a company that did nothing was automatically assigned, by default, to the public invoicing portal to receive its invoices.
Now that there is no longer a public portal, a company that makes no choice and that lets the deadline pass, we cannot send it an invoice because it is not present in the directory with an associated approved platform. And so they introduced fines for companies that do not choose an approved platform before September 1, 2026. First there is a three-month formal notice.
And then, after these three months of formal notice, a first fine of 500 euros. And then, if, three months later, you still haven’t chosen an approved platform, a fine that has risen to 1000 euros. So fines to force companies to make a choice of approved platform. Normally, we are supposed to choose it before September 1, 2026. And that’s all companies, regardless of their size, to be able to receive invoices.
Walid : ok. So, in the end, nothing that directly impacts you in the choices or in the direction you have taken?
Alexis: No, if not nothing else. For me, I don’t think of other things, but it was still something important, because in this period of political instability, we were not immune to a reversal of the situation. In the end, there was no reversal of the situation on the reform of electronic invoicing. There has been a reversal on the history of the certification of cash register software, only on a very different subject, where there has been a 180-degree turn by the legislator, but not on the reform of electronic invoicing, just finally the confirmation of the calendar. And then stuff about fines, etc. To adapt to the abandonment of the public gate.
Walid: Maxime, Philippe, do you have anything to add to that?
Maxime: no, no, it’s very complete. No, yes, thank you, Alexis.
Walid : ok. You had added, I think it was Alexis, questions related to purchases in stores or restaurants and which need an invoice.
Alexis: a professional who makes a purchase in a store for his business: if it’s a very small amount, a receipt may be enough. But when it is a slightly significant amount, normally, you must have a proper invoice to justify the charge and also justify the deductible VAT.
In what are called the use cases of the reform, for example, in the case of a meal in a restaurant taken in a professional context, so, for example, I invite a customer to a restaurant or something like that, they specify that below 150 euros, excluding tax, there is a tolerance for just having a simple receipt, But they specify that beyond 150 euros excluding tax, you are supposed to have a proper invoice, and therefore, that the restaurant owner issues an electronic invoice to the company.
And for that, they need to know the billing address. That is to say, they must know the directory line they have to invoice us. We must have at least one directory line that is based on the SIREN.
But companies can choose to have several directory lines in order to do, for example, a routing of invoices between different departments or it is their internal organization afterwards. And so, during one of the conferences that addressed these subjects, professional expenses, there was a person from the DGFIP who said in this conference that there will be the possibility of showing a QR code, which the professional can show to shopkeepers or restaurateurs.
A QR code so that the restaurant owner can easily scan their QR code to obtain the billing address to which they should address the invoice. So I found it interesting. It was the first time I had heard of anything concrete. How you could easily transmit the billing address quickly and easily when you are physically in store.
However, I have thoroughly pored over all the different documents of the AFNOR standards, the documents on the tax website, etc. I hadn’t heard of this QR code. So, suddenly, I went fishing, to get information. And then I learn that actually, yes, they mentioned it during the conference, but in reality, it hasn’t been normalized until now. I talked about it with the president of the National Forum for Electronic Invoicing, Cyrille Sautereau, whom I am lucky enough to know. I talked about it with someone from GS1, it’s the organization that standardized barcodes in mass distribution that I’m lucky enough to know too.
So, I talked about it to make sure that there was really nothing on the table today. And so, they all confirmed to me that yes, it was discussed at the conference, but that in fact, no, it wasn’t specified yet, precisely.
I said to myself anyway, this is really crazy. We need to make progress on this subject in concrete terms. I did the exercise of proposing a standard by saying here I am, I’m proposing something, come and give your opinion, what do you think of the standard. I know a little about barcodes, generally speaking, 2D barcodes, barcodes, 1D, I have several clients in the medical world and in the medical world it’s quite common. Two-dimensional barcodes which, in the same barcode, encode several pieces of information: the article code, the batch number, the expiry date, all in a single barcode.
So, here, it’s the same, we want a single barcode to include both the company’s billing address and perhaps other optional information, for example the employee’s number to know who has bought or things like that. Information that could, later, be found in the invoice that the company receives, for example.
So I wrote a standard that I invented myself. Well, it’s very simple, because a 2D barcode is never just a string of characters that is represented under a graph. So, the question is, what do we put in the string to encode the different information and transport the different information? The only one that is mandatory is the directory line of the company on which she wants to receive her invoice.
And so, there you have it, I tried to launch something in the hope that it would be taken up by the National Forum for Electronic Invoicing or one of the AFNOR groups. I don’t know if it will succeed in moving the lines, but I brought my little stone to the edifice, just to get a little concrete and say, there you go, come on, I’m proposing something, say what you think, propose better, etc.
But I was finally a little disappointed to see that in the end, this concrete subject of how, in store, I can transmit my billing address had not really been properly handled. And in fact, when we talk to people from the National Forum on Electronic Invoicing, the scenario that seems to be being discussed today is not so much the fact of transmitting your billing address, but rather saying that on the receipt, or even on the display at the checkout, there would be a QR code.
That after the checkout, with your phone, you would come and scan this QR code. It would take us to a web portal for commerce. And this QR code, it would link with the receipt. So, basically, you would find your receipt on this web portal. And there, you could indicate the address, the SIREN of your company, select your directory line on which you want to receive the invoice.
And finally, on this web platform, you would transform your receipt into an electronic invoice, which will then be issued. But it will be a process that would take place after the checkout, with a QR code that would have been scanned on the receipt, etc. Well, it’s something that would take place a posteriori. Well, why not? I mean, there are different solutions, but I found that it also has its disadvantages, this solution. It’s not the perfect solution, either. I tried to move the lines a little. We’ll see if I manage to move the lines or not. We’ll see.
Progress of the implementation on Dolibarr
Walid: So now, let’s get into the hard stuff a bit, in episode 1. We explained that at the level of Dolibarr and at the OCA level, there was work to be done to implement this process of electronic invoicing. We talked about financing, how it was going to be done, etc. Now, I’d like to know, since it’s September, so it’s coming soon, where are you at on this implementation process? At the level of Dolibarr, Maxime and Philippe, where do we stand on this? Maybe Maxime, do you want to start?
Maxime: With pleasure. Today, we are in the middle of testing the connector that we are developing with EsaLink. We have a whole working group that meets every two weeks to do these tests, send invoices to each other, receive invoices and put it back and forth. We still have a lot of things to refine, but for me they are more of a functional business process. A small question that we ask ourselves, to say to ourselves, do I have the right to modify an invoice that I received from a supplier, in my Dolibarr?
Do I have to change things on it? Whereas the data was well coded as input when it was received from the platform. We are no longer in this kind of questioning and adjustment.
Walid: Can you explain who EsaLink is, please?
Maxime: Yes, of course. EsaLink is an approved platform that we are working with to connect Dolibarr to EsaLink. It will not be the only one that will be connectable. There are others that will follow. But we chose EsaLink with several integrators because they have supported us from the beginning. They showed us their seriousness and their desire to work with us. They have provided us with a whole bunch of technical resources that allow us to have a connector that is in the test phase, but which is almost finished.
We still have a few technical choices to make, but today, we can issue and receive invoices in both directions in a Dolibarr in a few clicks. It’s as simple as emailing an invoice today.
Walid: So, in concrete terms, how does it work? I invoice a customer, automatically, this invoice is sent thank you. To the EsaLink platform, to then be routed to its customer’s billing system.
Maxime: Exactly, that’s right. After that, everything lies in the automatic, precisely. This is one of the questions we are asking. Are we really automating the sending? Like today, a user is used to clicking on “Send by email”, tomorrow, he clicks on “Send to the platform”. Do we force the submission to be validated? Are we also developing a feature that allows you to send invoices in bulk on the platform? I also have a lot of users who have automatic invoice generation at night: recurring invoices that are completely automated.
So, these will have to be filed automatically. We are not going to ask users to manually take these self-generated invoices and submit them by hand. It’s these business choices that I was talking about, which are a bit functional, that we still have to make and the little automatisms. And the whole part of the work on the connector, the flow exchanges and the flow processing, the update of the flows, this one, it’s being fine-tuned, it’s nearing completion.
Walid: And how does it work? When Dolibarr is the receptacle of someone else’s invoice, what happens at that moment, from the moment the invoice is issued? It arrives via the platform on Dolibarr. What happens in this case?
Maxime: In this case, the invoice arrives today as it is, it arrives in the system as what we call, in Dolibarr, a draft supplier invoice. There is a manual action on the part of a user that allows you to say do I accept or refuse the invoice, in order to be able to send the status update on the platform. And at the time of refusal, if this is the case, there is a reason for refusal that must be selected, which is one of the 12 available reasons defined in the standard today.
Walid: Was it a complicated job to do, that took a long time? How much time did you spend working on this module?
Maxime: You complete what I’m saying, Philippe. It wasn’t easy, indeed, because we’re a community with a lot of players, a lot of integrators, a lot of developers right and left. We each have our respective activities. And the community work today, around Dolibarr, is very empirical, I want to say. Each proposes improvements. Today, there is no project management with specifications, specifications, recipes, everything well formalized, etc., as one could do in a company, let’s say.
To organize the community and even this working group, it was a good job that was initiated by Philippe, precisely, at the beginning, with his teams. But the main project manager of the Dolibarr community today, has taken charge of the development of the connector’s core. He did the heavy lifting and now he’s settled on it. He let the working group take over, start the tests and then complete and correct what needed to be corrected.
Walid: First of all, the first question is do you think you will be ready for September 2026? And if so, in this version 1 of the connector, are you implementing everything that is necessary, all the features of what is meant by electronic invoicing reform, such as those planned to be implemented in September 2026?
Maxime: I would say yes, we will be ready, of course, for September 2026. We are already in working order. And then, on the functional coverage side of the reform, there will be a lack of cases, that’s for sure. Today we have dealt with the most common cases among our users. But very clearly, I think, I’m saying this, I don’t even know if there isn’t already someone who has worked on it, but I’m thinking of the case of the situation invoice, for example, for the construction sector, for the moment, it’s not finalized.
We have a few cases like this, which are not yet fully processed, but I have no doubt that it will happen in the process.
Philippe: Today, the module clearly does not cover the 42 uses kindly described in the reform. It’s going to be done a little bit as we go along. The objective is to have something that meets the basis of the reform. This is already the case. Now, we know that there will be a lot of particular stuff, all the use cases to be implemented. There are several factorings, the factor, etc. It’s part of the work that still needs to be done. In any case, between now and September, there will certainly not be everything. There will be the main use cases that we may have cleared. It’s still a long way to go.
Walid: Is there a… I don’t know what we call it, not a waiting period, but is there a period of…?
Maxime: tolerance?
Walid: Yes, tolerance. I don’t know, was it a few months ago, the first few months, so that everyone could get ready to work, etc.? How does it work?
Philippe: The project is so ambitious, I think that the State will be, in quotation marks, reasonable. I think that as soon as we demonstrate that we have registered on the directory, that we send things that are well done, badly done. I think that at the start, the State will already be satisfied if people do it, if they are registered in the directory, if the ETIs, the large companies really send their invoices. They are not very present from what I have understood at the moment about the tests of electronic invoicing.
There you go, I think the State will be happy. I think that 2026-2027 will remain a big transition period with, hopefully, tolerance from the State on the mistakes, problems and others that will not have failed to arise.
Alexis: What should also be remembered is that for SMEs, we are talking about SMEs, it is still a two-stage reform. The step of September 1, 2026 is that you must choose your approved platform to receive the invoices. But the obligation to issue invoices for SMEs is from 1 September 2027. Now, we have two new obligations, on September 1, 2027, the obligation to issue invoices in B2B and the obligation to e-report.
E-reporting is everything related to the transmission of information on invoicing, what is called in B2C, to individuals, so everything that is receipts or invoices for individuals who are not subject to VAT.
And then, in e-reporting, there is much more than that. There are also:
- the reporting of export invoicing invoices, whether intra-Community or extra-Community.
- invoices for intra-community acquisitions, when I buy tax-free in the European Union and there is a mechanism called the reverse charge of VAT
- We need to report information about these intra-Community acquisitions
- information must be reported on extra-Community acquisitions of services
- it is necessary to report the information on the receipts of these customer invoices if they are under the VAT regime on receipt.
So, in fact, e-reporting is a big chunk. It’s a bit like what I call the hidden side of the iceberg. And that’s the not funny thing, e-reporting. And that, for SMEs, only starts from September 1, 2027.
For large companies and mid-caps, on the other hand, everything starts on September 1, 2026, both the receipt of invoices and the issuance of invoices and e-reporting. For them, normally, everything starts in September of this year. One small thing to keep in mind is that between the two deadlines, there is the presidential election. Normally, it’s not supposed to affect that kind of thing, but you still have to keep that in mind. After that, we can speculate on what may happen.
I can give you my personal opinion: I think that if it starts well in September 2026 and it doesn’t make too many waves and there are no big problems that would arise, I think it won’t be a subject of the presidential campaign. And that it remains a technical subject between the tax authorities and companies, and that it will not interfere in the public debate.
But if there were waves, problems, things that would make the headlines of certain newspapers, maybe at some point, there would be candidates who would take up the subject by saying “what is this administrative madness of e-reporting?” Because there are still a number of people who are opposed to e-reporting. By saying that e-reporting is very cumbersome, etc. They are quite right, moreover, to do so.
And as a result, after having, we don’t know what can happen in a presidential campaign and what can lead to it afterwards. So there you have it. I hope that the reform will start, that there won’t be any big problems that will make the headlines, but we’ll see.
Maxime: I would just add, to come back to the subject, of tolerance, of starting. This is because the obligation is for companies to be able to receive from September. The fact that there is a connector that facilitates the integration of the invoice into the software, the company’s ERP, that’s as it stands, it doesn’t give a damn. As soon as the company has declared itself in the directory and is able to retrieve its invoices on any platform, whether the platform is connected by an automated flow with the ERP, that’s none of its business, it’s something that will facilitate the management of the company itself.
Alexis: Yes, that is to say, when we talk about the case of SMEs, in the end, having a connector between your accounting software and your approved platform that you have chosen, in reception, is almost a luxury. That is to say, it is obviously the comfort of having the invoice that is imported automatically, etc., it saves time, it is precious. We’re all here to save our users time. But in the end, someone who has an old version, which has not been updated and who cannot install this module, will finally go to the web portal of his approved platform and retrieve the invoices he has received.
Which, in the end, already saves time because today, when you do your accounting, you connect to the EDF portal to retrieve your electricity bill, you connect to the Orange, SFR or Bouygues or Free portal, or I don’t know what to get your Internet access bill, you connect to the portal of your electronic toll collection for your business trips. So, in the end, you spend your life logging in on a lot of different portals.
And then, if everything works, as planned, we will finally have a unified portal on our approved platform, we receive all these invoices. So, first of all, that’s a time saver in terms of reception. And so, if it doesn’t go back to automatic, that’s already a time saver in itself. After that, where it changes, the deal is for SMEs from September 2027, in issuance.
If you don’t have a connector or a module that allows you to link your management software, your invoicing software to your approved platform, that means for each of the invoices you issue, you have to deposit it by hand on your approved platform and potentially that it goes through a character recognition system, we know that character recognition is never 100% reliable, even if with AI, it makes a lot of progress.
And then, afterwards, you have to check that she has recognized everything, etc. So, for once, there is a real waste of time compared to today. Today, we send it by email or something like that.
In fact, I think that for SMEs, in order not to lose efficiency, it is really to say to themselves by September 2027, to have an update of their management software, their invoicing software, so that when I send customer invoices to my customers, I can automate as much as possible the transmission to my approved platform so that it is smooth to send invoices.
Both implementations on Odoo
Walid: Precisely, you who had the floor, now, on the Odoo side, on the OCA side, where are you already?
Alexis: The first thing to understand is that there are two initiatives, the choice between two implementations. On the one hand, the publisher, the Belgian company Odoo SA, the publisher of Odoo, has embarked on a rather ambitious project to become an approved platform itself. They were already Access Point Peppol, and had been for several years. They said last year: we are going to launch ourselves to be an approved platform. They were granted conditional approval status in January 2026. And then, a few weeks ago, they obtained their final approval.
And so, they promise, including on both the Odoo Enterprise edition, and also on the Odoo Community version, to have the e-invoicing modules. And they promise them free, including on the community version, well, open source and free, through their own server and their approval as an approved platform. So that’s it, let’s say, the implementation of the editor. For the moment, they have their status as an approved platform. They have not yet demonstrated the concrete implementation in Odoo. I think they promised it for the month of May, so I think it’s going to happen. But for the moment, we haven’t seen too much of the color in a very precise way to date.
And then, in parallel with this implementation of the publisher, I promised a long time ago, I had said that I was going to implement in the form of an open source community module, the reform of electronic invoicing by implementing the AFNOR APIs, so the famous standardized APIs that allow you to connect to all the approved platforms that implement the AFNOR APIs. It is not an obligation for approved platforms to have AFNOR APIs, but in any case for approved platforms that are intended to interface with business management software, it is still most of them who have promised AFNOR-compatible APIs.
And so, I’m implementing this. So, it will be an alternative implementation to the editor. This will leave the choice to companies with Odoo to choose the implementation of the editors or the one I’m working on. And where am I on my implementation? On the e-invoicing part, on the e-invoicing part of the reform, I have implemented all the management of the directory, which is really very finalized. I implemented sending and receiving invoices with lifecycles.
Because life cycles, which is precisely to say that the invoice is approved, the invoice is in dispute, the invoice is refused, the invoice is paid. There are quite a few things that allow you to share the status of invoices between customers and suppliers. So, there, I also have the life cycles that work. It’s still a bit in beta. I still have some work to do, finalizing and refining. We know that the work of finalizing and refining is often what takes the most time.
But in any case, it works. I know how to send, receive life cycles, send, receive invoices. On the other hand, I did not start the e-reporting component of the reform, knowing that our customers are SMEs. The e-reporting obligation is 1 September 2027 and for SMEs, it is not 1 September 2026. So, for the moment, I haven’t started this e-reporting component. I don’t know, by the way, on e-reporting, on Dolibarr, if you did as I did, you started with e-invoicing and you said e-reporting, we’ll see later, or if you are already in the e-reporting project?
Philippe: same choice, same choice, same strategy, same state of progress.
Alexis: Okay, fine. Because e-reporting is the not funny and not simple part of the reform. Because in fact, on the e-invoicing aspect of the reform, we, and I think it’s the same for Dolibarr, we already had the Factur-X generation, we already had the Factur-X import and the UBL import.
So, in the end, the implementation work was mainly the management of the directory, to be able to retrieve the directory lines of companies, especially for those that have several directory lines, because there, there is a challenge to select the directory line on which the company will be billed. There was work, of course, to implement the AFNOR APIs to interface with these standardised APIs and to be able to automate both sending and receiving directly from the software.
Invoices, life cycles, and also the download of directory lines for a given entity. And then, there’s this whole life cycle part which, for me, I think for you too, Dolibarr, was also a discovery. That, for once, there wasn’t that until now. On Chorus Pro, the life cycles were not standardised XML files, as we know from the electronic invoicing reform. So, we had to learn a little bit about these lifecycle XML files, knowing a little bit about the subtleties of that.
I’m quite recent, the life cycles, I implemented it a few weeks ago. I started to have a first implementation that works only a few weeks ago and I’m in the process of finalizing the implementation of the life cycles.
Walid : And now, then, this work, it’s done, is it a separate OCA module?
Alexis : It’s a community module, indeed, that I’m developing. But this is not an official module of the publisher. There will really be a choice between, on the one hand, the implementation of the editor. For the moment, we haven’t seen too much. We know that they have the approval, they have become an approved platform, but they have not shown the user part, the modules listed on the server side.
Walid : You don’t know how to compare what they did at the moment
Alexis : I was able to give demonstrations. For the moment, I have given demonstrations. It’s true that I didn’t do them in public, I did them in private, the demonstrations of my implementation. By the way, I intend to publish a screencast of the progress of my implementation in the coming days.
We will see the recovery of directory lines, the generation of an invoice, the sending, the receipt, the life cycles to say the invoice is in dispute, the dispute is resolved, the invoice is approved, the invoice is put into payment and to see the life cycles that are exchanged. That’s my implementation, it’s based on AFNOR APIs. I test it with the test environment of SuperPDP, a competitor of Esalink. Both are approved platforms that implement AFNOR APIs. For our customers, we chose SuperPDP, but normally, as it is the AFNOR APIs, it is supposed to be compatible with all approved platforms that implement the AFNOR APIs.
Walid : To make sure I understand the subject, does this module work whether you’re on the enterprise version or on the Community version?
Alexis : yes, normally, the module will work on both editions.
Walid : It works. Will you also be ready for September 2026?
Alexis : yes, anyway, we have no choice. Now, the goal is even to be ready before, obviously, because you can’t deliver the stuff just on the day of the deadline. For me, the goal is to finalize the implementation of the life cycles on which I still have refinement.
I think that already, we will install it in production at home in June, so that we can start using it in production. We are fortunate to have the National Forum for Electronic Invoicing among our customers, and therefore among Akretion’s customers. As a result, since they have already activated their address in the directory, we will be able to send them a real invoice for real. The goal is for us to start testing on our own Odoo server.
And then, we plan to start training our users at the end of June, beginning of July and then also start backporting the module to the different versions of us. Because right now, I’m working on version 18, but it’s not just version 18. I promised to make it available on version 16 as well. And then, the odd versions, it will be if people ask me and sponsor me to port to odd versions. But I won’t do it spontaneously unless expressly requested.
Walid : On the Dolibarr side, what do you have planned for testing? Are you planning a public beta phase? How do you plan to organize yourself in the coming weeks and months?
Philippe : First of all, we’re playing between integrators on sandboxes for the moment, but I want to say, there’s not much that differs, except that we’re not on the production environment being tested, with real invoices. It allows us to replay games much more easily. So, today, we are already, I would say, in this active phase.
For my part, I think that among my colleagues too, in the very short term, try to switch all this to production as well, to embark on the directory and to say maybe in June, somewhere, we will also be able to maybe start exchanging real invoices between Dolibarr integrators. We charge things from time to time. And then maybe to get customers on board. I know that I have customers who are now asking to test on this.
Maxime : Yes, because the difficulty is that the ETIs and large companies that are obliged to broadcast from September, we are not going to call them during our test phase and say “hello Orange, hello EDF, can you send us test invoices, please, so that we check our Odoo connector?” So we will receive these for real in production from September. And it’s going to be funny. So, in the meantime, we have effectively organized ourselves among ourselves, in the community, mainly with the integrators, to be able to do these tests and send invoices to each other.
The progress of PDPLibre
Walid : ok. I’d like us to talk, in episode 1, we talked about the initiative launched by Philippe and others, which is called PDP Libre. I would like you to remind us a little bit what the objectives were, and where are you in your reflection, implementation?
Philippe : The objectives, at the time, when we were very angry, at the end of 2024, we said to ourselves, since the State is not doing it, we are going to do it. It was so ambitious though. So, the project has not been abandoned. What did that mean? This meant creating a PDP, but based on a structure with open governance, etc.
Walid : So, an approved platform.
Philippe : an approved platform, absolutely. Hence the acronym PDP Libre, which stands for participatory dematerialization project, since we are not going to change the name. Build an approved platform, but based on open source code. It’s a project that hasn’t been abandoned, it’s a long-term project. In any case, if we don’t do it this year, we can do it all in 2027, 2028 or 2029.
Today, we work mainly on volunteer time. Knowing that in the long run, if you really have to do it, there are ISO 27001 to pass, become Access Point. It’s still budgets behind that are not necessarily very neutral. Will it go all the way? I would say to date, I don’t know how to say. In any case, there is, within PDP Libre, a working group on this, on the community PDP, as we call it in our country, which has been working on the specs, which has started to throw things on a repository.
In the meantime, what we also wanted was to be a little more secure about the reform. There was someone, in this case, it was Aurélien Bisotti at the time, who took his pilgrim’s staff and went knocking on the door at the time of the 80-90 PDP. We did a bit of a filter beforehand by telling ourselves, who we are going to work with, to try to see how we could set up a group purchase, somewhere. The idea is to say to ourselves, we’re all little ones, if we go separately, potentially… so, at the time, there was not yet the Super PDP offer, I will come back to that later.
The idea was indeed to find an approved platform, to select one that corresponds to a certain number of our criteria, a company based in France, on a human scale with which we can talk, etc. And it was in this context that I met Esalink, which at the time, it is one of the few, immediately told us “banco, we open our APIs to you” and who did not ask us for 20 or 30k to access their sandbox.
Alexis : There are really people who have asked for 20 or 30k to access the sandbox.
Philippe: Oh yes,
Alexis: It’s crazy.
Philippe : Yes, that’s it. So, between those who didn’t answer, those who said yes, but no, but we’re not right away, soon, etc. We got together, and then they were quite willing and very “proactive”. We had to start developing. In any case, it allowed us to start working with them without them asking us for anything in return. Indeed, in the meantime, there is Super PDP which has appeared with its offer, as I said, a bit like Free, with the knock-down price. Despite everything, we continued in the process we had initiated.
What we wanted was also to secure the contractual relationship between PDP Libre, today, OCA, which is essentially integrators, SaaS platforms. There are not only people from Dolibarr. There are people from Dokos, SaaS platforms, community Odoo integrators, Community, too. There is a fairly wide range, in quotation marks. SaaS platforms, also proprietary, which were also interested in both the community approach, but also in the pooling of resources. Pooling a little of the risk also with regard to the reform and an actor to whom we will entrust our invoices and to whom we will entrust our customers’ invoices directly. There was a need, a little bit of security.
So, PDP Libre’s approach today is a bit of a mix of all that that has led us today, so on the PDP Libre side, to contract with Esalink on a set of contractual guarantees. We spent a lot of time negotiating, reviewing all the contractual clauses, all the commitments in terms of service level, support, response time, so that, indeed, we can already have a first offer, so, of course, which has a cost, on the other hand, behind it, we have SLAs, guarantee levels, Strong support commitments which, for many integrators and platforms, were important.
So there, we started with that. This does not mean that all members of PDP Libre will use Esalink. In fact, we’re going to be quite open, since in the end, at the end, we had the Esalink and Super PDP. Super PDP, it was more complicated to contract because there was a question of economic model, somewhere, with the floor price they charge today, it’s complicated to be able, on the PDP Libre side, to be able to finance a mutualization, but which, in the end, with these rates, doesn’t make much sense.
So, in the end, today, we are more in a situation where, somewhere, we will route both people to Esalink or Super PDP according to their needs, if we take the case that I know well from Dolibarr today, the Dolibarr connector is compatible with both Esalink and Super PDP, Both are implemented.
I think it won’t meet the same needs. I think that a Dolibarr user, who wants to be totally autonomous, as we have many and a lot today, will take the community module, install it, open his account with Super PDP, retrieve his credentials and live his life. For structures that want to be supported or integrators who want to hold a hand to their customers, Esalink may probably be a better match, because I know that, behind it, I will have access to direct line support, that they will have X hours to solve problems for me when my customer can no longer send his invoices and will yell at me on the phone.
It is a form of insurance, of risk pooling between integrator and platform. That’s a little bit of a choice. History will tell if it was a good or bad choice. In any case, for the moment, for those who have chosen this option, we are rather serene.
Walid : So, PDP Libre is an association. How many members do you have?
Philippe : 1901 law, yes.
Walid : How many members are you at the moment?
Philippe : So, it is structured with two colleges. We have created, indeed, within the framework of this mutualisation, via a contractualisation. There is a distribution college in which you can join if you want, in quotes, to take advantage of the contract that has been negotiated between Esalink and PDP Libre. There will be a contract between PDP Libre and its distributor members who will be autonomous to manage their customers, connect them to their management software, etc.
And then, there is a user college, if you want to participate in the governance, a little of the association, if you want to participate in the work around the community AP, etc., to contribute your stone, you can also join the association. But at first, the association does not really have the means to offer, to provide services or anything else. It may come, but in the short term, it’s a bit complicated.
Walid : Maxime, do you have anything more to add?
Maxime : No, I confirm a little bit everything that was said with Philippe. The objective of PDP Libre is to have an alternative. As an integrator, my customers entrust me with their ERP because I support them. They will entrust me in the same way with the integration of this electronic invoicing connector. We really have two distinct populations of use, especially at Dolibarr. Those who manage a little on their own with the community Dolibarr and therefore the modules that go with it.
Alexis : I had a question because you have the experience of interfacing with both Super PDP and Esalink using AFNOR APIs. So, the AFNOR API, normally, the promise is that it will be the same code that can exchange with both of them. Do you actually have little things to change when you switch, when you said Super PDP or Esalink, and what kind of things, what does it affect, the changes to be made when you go from one to the other?
Finally, is the promise of the AFNOR APIs finally kept or are there still small ifs in the code, if Super PDP, so this tag is mandatory? It’s a bit like this kind of thing that I could tell you after my experience, but with regard to the AFNOR API, you have experience, I don’t.
Maxime : I don’t think we will be able to answer, I don’t know about you, Philippe, right away, because, precisely, with Philippe, we focused a lot on testing and the Esalink part, based on this common connector, which is also open source [see on github]. And we weren’t the ones who directly coded the Super PDP connector part. So, no, only Philippe and I, I think we don’t get our hands dirty with the code much, but in addition, we didn’t have to do it on both in parallel. Now, from my window, the connector that was developed for Dolibarr, it’s very generic.
Yes, I have a different connection class, one for Ezalink, one for Super PDP, but behind it, the whole business flow is the same. After that, I don’t know to what extent the Esalink APIs and the Super PDP APIs are different, but for me, the AFNOR standardization part, it is between the AP and the other APs. They are the ones who provide us with the Factur-X format that we decode, and we rely on that to retrieve the data. I was thinking of interoperability when I was talking about exchanges between the platforms, but we didn’t have any difference in how the two systems worked.
Philippe : When we started development, it was a prerequisite. We relied in particular on the experience of one of the CAP-REL integrators, who had developed the Peppol module for Belgium, where there are as many access points, with almost as many APIs, etc. So, we relied on his experience.
On the connection module for Dolibarr, there is an abstraction class that is completely generic compared to the AFNOR API. And then, indeed, there is an overlay of code. I admit that indeed, I didn’t look at whether there had been a lot of codes added, gaps between the two. We should look at both classes. We should see the Super PDP class, if it is substantial or not. It’s easy, I admit that I didn’t make the intellectual effort, but I think it shouldn’t be very complicated.
Maxime : the two connectors seem pretty much identical, at least in terms of lines of code. But the Esalink and Super PDP connectors, as I said, process the APIs made available by these two platforms. Then, in both cases, as you say, there is the Factur-X format, in particular, and then mc2i, which is decoded by other abstract classes.
Walid : And you, Alexis, before we finish, what is your experience on this? Did you want to say a word about that?
Alexis : I only experiment with Super PDP’s AFNOR API. The only small difficulties I encountered, for example, are that, especially on life cycles.
Overall, I had no difficulty with the directory part. And then the sending and receiving of invoices. On life cycles, I was confronted with small problems where, for example, some fields that I had not filled in in my XML because in the specs, the XML field was marked as optional, at least for the exchange between the company and its AP. Because the field, potentially, it can be, in some cases, mandatory, in some cases, between the PA and the tax authorities. And they had said that the field was mandatory. I hadn’t informed him, it was a mistake.
And then, as the error message was not always very explicit about exactly which tag was blocking, they gave me a little help to tell me that this tag, indeed, is mandatory for us. In fact, it wasn’t in the AFNOR API itself, it’s in the XML files, what are the mandatory tags? What are the optional tags? There are some that set the bar a little higher, optional guidelines that, in fact, are mandatory. Otherwise, you get a mistake when you try to send the XML file.
I had two little things like that. It wasn’t very difficult to correct. Otherwise, I found that this AFNOR API was rather well designed. In any case, I was pleasantly surprised by the AFNOR API. And it’s true that in the world, Peppol, there are no API standards between the company and its Peppol access point. And finally, we in France, there was this initiative of the AFNOR API. I think it’s really worth highlighting because when the public portal was abandoned, we said to ourselves: “we’re going to have to implement the APIs of different approved platforms”. There was this initiative by API AFNOR, which was really good news.
Walid : We’re coming to the end. Before I part, I would like to leave each of you, if you like, with a final word, to pass them on. A message before we say goodbye to the listeners of the podcast, who use a Dolibarr ERP or an Odoo ERP with the OCA module. Maxime, do you want to start?
Maxime : a few last words, I would say that we will have to plan a podcast episode 3 in the middle of the summer to be able to say precisely to what extent we are in the starting blocks. And take the temperature that will break through the ceilings. I’m pretty confident about the future, in terms of our ability, in any case, to meet customer needs and to be able, as I said earlier, to refine and improve everything so that, I’m going to like your formula, Alexis, to say that our job is to save time for our users.
That’s what we’re going to be there for. I’m very confident that September will be a good test phase with a bit of limited flows. And that we will ramp up throughout the beginning of 2027.
Walid: Philippe?
Philippe : I’m indeed almost looking forward to September 2026, or terror, it depends. It depends on the morning, if I slept well or not. You were talking earlier, Alexis, about the life cycle, about these little pieces of information that pass through one AP, but not another. I’m also waiting to see when things will be exchanged between the APs, that the APs will say: “yes, but I won’t”, because at the level of controls, documents, compliance and others.
For asking the question, some people told me: “yes, we based ourselves on the diagrams, which are a bit like the control guidelines. Others, we have done our own checks again. Yes, ok. We’ll see what happens. There you go. So, I’m still waiting to see how the machine will run.
But there you go, we will be on reasonable volumes. It won’t be big volumes right away if all the mid-caps and GE do their job well in the show. A few million bills will be circulating. Reduced to the scale of a company, it will not be, if we are only on the receiving end, probably large volumes either. So it will allow us to see a little bit how the thing goes. And then, for customers who have not very complicated cases, I would suggest that they send their invoices, even if they are not required, which is also possible.
Walid : ok. Alexis, your last word.
Alexis : Yes, we’re obviously expecting quite intense months, until the start. And even after, because we know that the start-up phase is where we’re going to have the real cases in real life and we’re going to have to make more adjustments and updates.
What I see a little bit with this reform is that companies that could have been on fairly old versions and that were not sensitive enough to the need not to lock themselves into the past on old versions of Odoo, where I think it’s the same problem on… All the software, to say: “No, I don’t want to update, I want to stay on my version, it works well, it costs time, so money to do these updates.”
There, indeed, when we have subjects like this, where we need to have these new modules for the reform of electronic invoicing, we, the developers, make them available on recent versions, so not the very latest, but also N-1, N-2, etc., but not the versions of 5 or 10 years ago, It’s not reasonable for us to spend so much time.
And so, suddenly, finally, to see that, as on many other subjects, you have to be careful to have a management software that you can update, without it being too cumbersome, too complicated. And that’s also a reminder. We are already seeing it this year and we will see it, I think, again next year. Companies that will say to themselves: “me, my old proprietary management software that is no longer maintained, that is no longer a thing…” I’ll have to renew it. Quickly, I need a Dolibarr or an Odoo urgently. »
So, I don’t know if integrators will have the bandwidth to accept these new prospects, these new customers, because we’re obviously all going to be very busy. We can already see it in our country, but I think it will continue. We must also not wake up too late before the second deadline of September 2027 for companies that need to change their management software because they do not pass the deadline, they are not able to generate invoices in one of the formats of the reform.
Maxime : or to equip yourself at all.
Walid : Or to actually equip yourself with a new software. I think that indeed, having talked to integrators, people tell you: “sorry, but we’re full”. So, there you go, it’s a bit late, we had to get started before. Listen, thank you to all three. Maybe there will even be an episode 3, indeed.
Alexis : Maybe around October, when we’ll have passed the first weeks of start-up. We will start to get a bit of feedback. It could be interesting, in October, to do a little debriefing of the start.
Maxime : She’ll have to have the date right away.
Walid : yes, that’s it. Let’s make an appointment in a few months to talk about it again. Okay, listen, thank you all three for coming. It was cool. I did it a little out of the blue, this episode, but I thought it was really worth it.
A little message before parting for the listeners. If you’re listening to this podcast from your podcast app and you have questions about terms that have been used in general on the podcast, I invite you to go to the transcript, because the transcription is complete, with lots of links, lots of additional information, potentially screenshots, etc. So, these are additional resources at your disposal, if you want to dig deeper into the information, these are things that have been asked of me recently. So, there you have it, I’m taking this opportunity to pass on this message.
And there you have it, as usual, run this episode, get informed, ask questions on the social networks of the people here and their companies, if you have any questions. This episode, I had the idea because I saw someone on social networks who said: “oh dear Dolibarr, electronic invoicing, it’s not going to work”. I thought it was time to… Explain to you where we were and that if, yes, it was going to work. So there you have it. So, listen, see you soon for an episode 3. Then, here we are, we’ll talk again in a few months. Thank you.
Maxime : With pleasure. Thank you, Walid.
Philippe : Thank you.
Episode production
- Remote recording on May 13, 2026
- Basis: Walid Nouh
- Editing: Walid Nouh
- Transcript: Walid Nouh
This interview has been automatically translated from the original language into English.
Use of AI
You can consult our AI charter.
- Transcription: whisper-medium via mufidiwiwhi locally
- Transcription improvement: gemma4-26b locally via internal tool
- Automatic translation into English: Microsoft Translator with WPML WordPress plugin
- English translation of social media posts: locally with Jan and Mistral-Small-3.2-24B-Instruct
License
This podcast is released under the CC BY-SA 4.0 license or later