Reception Is the Deadline. Issuing Is the Part That's Phased.
Almost every conversation I have about the French mandate is about sending invoices. That's the half with a transition period.
The half without one is receiving.
From 1 September 2026, every business in France must be able to receive an electronic invoice. No size threshold, no phase in, no exemption for small companies. On the same date, large and intermediate companies must also issue them. Small, medium and micro businesses get until 1 September 2027 to issue.
So if you're a small business in France, you have a year to sort out sending and about three weeks to sort out receiving.
That asymmetry catches people out for a structural reason: you don't control when reception starts mattering. Your supplier does. The day one of your suppliers switches to electronic invoicing, you're receiving electronic invoices, whether or not you planned for it that week.
The timeline was confirmed rather than assumed. A deferral was proposed and rejected in the National Assembly, and the DGFiP has published its readiness guide. This is happening.
What Actually Lands in Your Inbox
Here's the part that surprises people, and it's good news.
A Factur-X invoice is a PDF. It opens in whatever you already use to open PDFs. It looks like an invoice, because it is one: a human readable page with the seller, the buyer, the line items and the totals laid out the way invoices have always been laid out.
Tucked inside the file is a second thing: structured XML carrying the same information in a form software can read without guessing.
That hybrid design is deliberate, and it's why France chose Factur-X over a pure XML format. One file serves both readers. Your accounts payable clerk sees an invoice. Their software sees data.
Which means the honest answer to "what do we have to change on 2 September" is, for a lot of small businesses, not much. If your process today is to open the PDF, read it and type the numbers into your accounting system, that process still works. The invoice is still a PDF.
What stops working is rejecting it. As of 1 September, an electronic invoice is the normal invoice. Emailing your supplier back to ask for a "proper" one is no longer a request they can act on.
Germany Already Did This, and It Went Quietly
Worth knowing if you sell into both markets, and worth knowing as a sanity check on how bad this is going to be.
Germany crossed the same line on 1 January 2025: every German business has had to be able to receive an EN 16931 electronic invoice since then. Issuing follows later, 1 January 2027 for companies over 800,000 euro turnover and 1 January 2028 for everyone else.
Eighteen months on, the reception half turned out to be the easy half. Being able to receive a file is mostly a decision rather than a project. The invoices arrived, people opened them, and the sky stayed up.
The formats did not converge, though. Germany has XRechnung, which is XML on its own with no PDF, and ZUGFeRD, which is the same specification as Factur-X with a different name on it. France leads with Factur-X. All of them sit on the European standard EN 16931 underneath.
So if you invoice in both countries you're not picking one format. You're handling a family. The good news is the family shares a core, and an invoice that's genuinely valid EN 16931 is most of the way to all of them.
The Word "Genuinely" Is Doing Real Work There
A CIUS is a national narrowing of EN 16931. XRechnung is one. PEPPOL BIS is another. Each adds rules on top of the European standard and removes some options it allows.
The practical consequence: a file can pass EN 16931 and still be rejected by a German buyer, because XRechnung asks for things EN 16931 leaves optional. If your validation tool only reports EN 16931, it isn't answering the question your German customer is asking.
This is the single most common way a company believes it's compliant and isn't.
Three Things Worth Checking Before September
If you're issuing invoices, and especially if your software vendor has told you you're covered, these are cheap to verify and expensive to get wrong.
1. Is the container really PDF/A-3? Factur-X requires it. PDF/A-3 is an archival format with specific rules about embedded files, and exporting a normal PDF from your usual tool does not produce one. A file can look perfect and fail on this alone. Note that PDF/A-3a, 3b and 3u are all conformant, so don't let anyone tell you that you need one specific flavour.
2. Does the XML actually validate? "It has XML in it" and "it passes EN 16931" are different claims, and only the second one matters. The European standard publishes its rules as machine readable Schematron, so this is a question with a definite answer rather than an opinion.
3. Do the page and the XML agree? This is the requirement no validator checks and the one auditors care about. Factur-X requires the human readable page to show what the structured data says. Same totals, same dates, same parties. A file where they disagree opens fine, validates fine, and is a compliance problem.
Check One Yourself, Without Sending It Anywhere
We built a free Factur-X validator partly because we needed one ourselves and partly because the existing ones all wanted us to upload the invoice.
Think about what's on an invoice: your customer's name, what you charged them, your unit prices, your discount and your payment terms. Finance teams would never email that to a vendor they've never bought from, then drop it into a web form without a second thought, because a web form doesn't feel like sending it anywhere.
So the EN 16931 rules in ours run in your browser. The official CEN Schematron is compiled and shipped to the page, your file is read by the tab you're already sitting in, and nothing is posted. You can verify that claim yourself: open devtools, watch the network tab, drop the file in.
The deeper checks for ISO PDF/A-3 conformance and the German and PEPPOL rule sets genuinely need a server, so those are a separate button that says so, opt in per file.
Every finding comes with a plain language explanation of what to change, for all 223 rules in the standard rather than the common ones. That part is its own post, because the error messages the standard ships with are written for the people who wrote it.
If you'd rather see what a valid one looks like from the inside, the validator will show you the embedded XML, the profile it declares and how the container is put together. Most people issuing invoices in September have never opened one.