September 2026 is everywhere. In public campaigns, in tax authority emails, in conversations with accountants. The date has entered the scenery, which is not a bad thing: at least this time, nobody should discover the reform the night before with a surprised face and three spreadsheets open.
The problem is not that nobody talks about September 2026. The problem is what people put behind that date. Many still hear it as “the start of e-invoicing”, or as the deadline for large companies that must start issuing. For a small business, the concrete effect is more immediate: from 1 September 2026, your suppliers may send you real electronic invoices, and you must be able to receive them.
Receiving comes before issuing, and it’s exactly the part you don’t control.
What changed in the system
For two years, the announced design relied on the PPF — the public invoicing portal — as a platform invoices could transit through. The system has since been narrowed: the PPF is no longer the public transit platform companies were expecting, but the infrastructure for the central directory and for reporting data back to the tax authority. Its job is to know who receives what, through which platform, and to concentrate the tax data needed by the DGFiP.
Concretely, that means three things:
- B2B invoice transit now goes through certified platforms (the former PDPs), registered by the tax authority. No simple public option where everyone deposits and retrieves invoices.
- Chorus Pro remains the reference platform for B2G — invoicing the public sector doesn’t change channel.
- Penalties have been strengthened: the per-invoice fine goes from €15 to €50 per invoice, e-reporting from €250 to €500 per transmission (with annual caps).
In the official list at the time of publication, examples include familiar names such as Pennylane, Qonto, Sage, Cegid, Tiime, Indy, Yooz or Esker. This is not a recommendation list. It’s mostly a useful reminder that reception won’t go through a magic public form, but through an intermediary you actually choose.
The operational calendar remains easy to remember: mandatory reception for everyone on 1 September 2026, issuance for large companies and mid-caps on the same date, issuance for SMEs and micro-businesses a year later.
Why reception is the trap
When people talk about September 2026, the natural reflex is to ask: “do I have to issue?” If you’re an SME or a micro-business, the answer is often no, not yet. That’s where the misunderstanding starts.
When you issue, you hold the schedule. You pick your platform, you migrate when you’re ready, you test on your own flows.
Receiving is the opposite: your supplier decides for you. From 1 September 2026, the moment one of your large or mid-cap suppliers switches to electronic issuance — and they’re required to by that date — you must be able to ingest their invoice. You choose neither the timing, nor the format, nor the platform on the other side. You’re on the receiving end, literally.
And “being able to receive” isn’t having an inbox. An electronic invoice, in the sense of the reform, is not a PDF attachment. It’s one of these baseline formats:
- a pure structured XML (UBL or CII),
- or a Factur-X: a human-readable PDF/A-3 with the same CII XML embedded inside for the machine.
Receiving properly therefore means connecting to a certified platform, pulling the flow, parsing the XML, validating it, then reconciling it against your purchase orders and your bookkeeping. It’s an integration project, not a setting to toggle. And it’s exactly the kind of work you underestimate until you’ve done it.
The format isn’t the problem
I wrote two open-source gems around this — einvoicing for the core (generating and reading Factur-X, validation, CII profiles) and einvoicing-connect for the plumbing (Chorus Pro, certified platforms, e-reporting). After running them on real flows, one thing became obvious: the format is the easy part.
Producing a compliant Factur-X is mechanical. A PDF/A-3, a CII XML attached with the right filename and the right profile, a handful of validation rules. A library does this very well:
invoice = Einvoicing::Invoice.new(profile: :en16931)
invoice.add_line(description: "Service", quantity: 1, unit_price: 950_00)
facturx = invoice.to_facturx(pdf: rendered_pdf) # PDF/A-3 + embedded CII XML
The real work is elsewhere: in the business reconciliation. An incoming invoice has to be linked to the right supplier, the right purchase order, the right VAT, and you have to handle credit notes, partial invoices, cent-level discrepancies, identifiers that never match on the first try. The XML hands you clean data; it doesn’t tell you what to do with it inside your accounting. That’s where 90% of the effort goes, and it’s the part no platform will do for you.
The right question to ask now
The reform is not “2026 for large companies, 2027 for small ones”. It’s 2026 for everyone on reception, then 2027 for part of the market on issuance.
So the useful question is not only “when do I have to issue?” It’s: “on 1 September 2026, can I receive a structured electronic invoice and integrate it without re-keying it by hand?” If the answer is no, this isn’t next year’s problem. It’s this summer’s.
Picking a certified platform, wiring up reception, testing the parsing on a few real supplier invoices: that’s a calm few-weeks job if you start now — and a painful one if you wait for the first supplier to switch without warning.
Preparing reception before it hurts
A business application, an ERP held together around spreadsheets, an accounting workflow that still works because someone re-keys everything by hand: e-invoicing will quickly reveal the places where the system mostly runs on human patience.
This is the kind of work I handle at SXN Labs: clarify the real need, choose the right level of automation, wire up reception, and make sure invoices land in the right place without adding yet another overbuilt system. If your e-invoicing reception is about to become a painful project, drop me a line.