What does the French mandate require of my invoicing software?
Produce a compliant structured invoice, route it through a certified platform rather than sending it yourself, and know whether you are inside the reform's perimeter at all.
France’s B2B reform is not only a format change. It changes what your software must produce, how the document reaches your customer, and what happens when it is refused. Taking them in that order.
| Date | What changes |
|---|---|
| 1 September 2026 | All businesses must be able to receive; large enterprises and mid-caps (ETI) must issue and e-report. |
| 1 September 2027 | Small and medium enterprises (PME) and micro-enterprises (TPE) must issue and e-report. |
The 1 September 2026 and 2027 calendar was reconfirmed in April 2025; a further delay was rejected. Dates can still move by decree, so re-confirm against DGFiP before relying on them.
Last verified against DGFiP / AIFE and the European Commission eInvoicing country page on 24 August 2026. Official source.
First: are you even in the perimeter?
The reform’s scope is drawn by establishment in France, not by nationality, VAT registration or invoice currency. That splits French traffic three ways, and only one is regulated:
| Flow | Regulated? | How it travels |
|---|---|---|
| French-established seller to French-established buyer | Yes | Must go through a certified platform (Plateforme Agréée, PA) |
| Seller not established in France, to a French buyer | No | Ordinary Peppol BIS Billing 3.0 |
| French-established seller to a foreign buyer | No | Ordinary Peppol |
Because establishment is the test, a foreign company with a French branch is inside the perimeter, and a company holding a French VAT number with no French establishment is outside it. Businesses with no French establishment are excluded from French e-invoicing rather than given a later date, though they may still owe e-reporting where they are liable for French VAT.
Getting this wrong in either direction is expensive: building for the regulated path when you are outside it, or sending a domestic invoice over plain Peppol and remaining outside the reform while believing you complied.
Second: what the software must produce
A compliant French invoice is an EN 16931 document. Factur-X is the usual choice, the hybrid PDF that carries CII XML inside a readable PDF, and plain CII or UBL are also EN 16931 syntaxes.
On top of that sits the French CTC overlay, a set of BR-FR-CTC-* rules published by FNFE-MPE on behalf of the administration, plus a further overlay for the EXTENDED profile. What matters for an implementer is that these rules do not run just because the invoice is French. They run when the document triggers them: an explicit opt-in on the request, the EXTENDED-CTC-FR profile identifier, or a cadre de facturation code from a closed list carried in the document.
That is the quiet failure mode. A French invoice with no cadre de facturation and no CTC profile is judged against the European core rules alone, comes back valid, and was never asked a single French question. Beliq refuses to send such a document rather than pretending to have a verdict on it.
The French-specific content matters too: SIREN and SIRET identifiers on both parties, French VAT category handling, the process codes, and line-level legal identifiers. These are recognised by the builder and reported by the validator with their own rule IDs.
Third: routing, which is not yours to do
A regulated French invoice reaches its buyer through a Plateforme Agréée. That is a registered, certified role, and your invoicing software is not one unless it has gone through that registration itself. Beliq is not a Plateforme Agréée: it builds and validates the document, and a certified platform transmits it. Managed delivery through a partner platform is in build, targeting Q4 2026 and subject to certification.
Also out of scope, and worth knowing so you can plan for them: the administration’s recipient directory, the acknowledgement envelope exchanged between platforms, and the e-reporting flows.
The invoice-number trap
This is the detail that makes pre-validation non-optional in France. A French invoice number is unique on the number, the supplier SIREN and the invoice year. If a platform rejects an invoice, that number is spent: the corrected invoice must be issued under a new number, not resent under the old one. A rejection is not a retry.
So the order of operations matters. Validate against the French rules before the document goes anywhere, and treat a blocking finding as a stop rather than a warning, even where the rule pack itself grades it as a warning. A platform refuses a document carrying any of those rules whatever severity the pack assigns, which is why Beliq surfaces the blocking rule IDs as a separate answer from the ordinary verdict.