French e-invoicing

This site is independent and is not affiliated with the DGFiP, FNFE-MPE or any tax administration. eDocument Tools performs local technical validation for the supported French electronic invoice formats. UBL and CII documents can be checked against the pinned France_RFE 1.4.0.04 rule packages, covering the EN16931 and EXTENDED-CTC-FR targets for UBL and the same two for CII D22B. Supported Factur-X profiles — BASIC WL, EN16931 and EXTENDED — can be inspected and validated against their corresponding French rule packages.

Validation runs locally in your browser and does not constitute acceptance, certification or submission by the DGFiP, a PDP, Chorus Pro or any other authority. PDF/A-3 conformance is not checked.

What the reform requires, technically

The French reform makes structured electronic invoicing mandatory for domestic business-to-business transactions, and adds an obligation to report transaction and payment data to the tax administration. For an implementer, that translates into three technical obligations: emit invoices in an accepted structured syntax, exchange them through an accredited platform rather than by email, and satisfy the French business rules layered on top of the European ones.

Dates and platform accreditation details have moved more than once and are a matter for the official sources rather than a tooling site — check the DGFiP publications and the current external specifications for those. What has stayed stable is the format architecture below.

The current timeline — who receives and who issues, from when — is summarised with its official sources in our 2026–2027 timeline guide, dated and re-checked whenever it changes.

The three accepted syntaxes

• UN/CEFACT CII — the Cross Industry Invoice, in XML. The syntax most closely associated with the French reform, and the one carried inside Factur-X.
• UBL — OASIS Universal Business Language, the other EN 16931 syntax and the one Peppol uses.
• Factur-X — a PDF/A-3 file with CII XML embedded inside it. Technically not a fourth format: the machine-readable half is CII.

All three express the EN 16931 semantic model. The French requirements are additional business rules on that model, not a separate format, which is why a document can be valid EN 16931 and still fail French conformance.

Why Factur-X matters here

Factur-X is the pragmatic on-ramp. A supplier who has always emailed PDF invoices can keep producing something a human recognises while the receiving system reads the embedded XML. That lowers the adoption cost enormously compared with a pure-XML mandate, and it is why so much French tooling is built around it.

The practical consequence for implementers is that "handling Factur-X" is two problems: PDF attachment extraction, and CII invoice processing. The second is the larger one, and it is the same problem as handling plain CII.

Layers of rules

Validating a French invoice means running several rule sets, in order, and knowing which one produced a failure:

• XML Schema for the syntax and its UN/CEFACT or OASIS release.
• EN 16931 business rules — the European core.
• French rules — additional constraints published as versioned validation artefacts, including the BR-FR-* family and the French CTC extension.
• Factur-X profile rules where the document is a Factur-X file.

These packages are versioned, and versions matter: rules are added and corrected between fix levels. A validator that silently pulls "the latest rules" gives you a different answer on different days for the same file. This site pins artefact versions explicitly and reports which version produced each finding — today that is France_RFE 1.4.0.04, committed to the project with a SHA-256 checksum for every file and served from this origin, never fetched from upstream at run time.

The release trap

French CII artefacts target a specific UN/CEFACT release. It is tempting to have a tool "detect" that release from a document and pick artefacts accordingly. That does not work: every UN/CEFACT release publishes the Cross Industry Invoice under the same namespace URI, so the release is simply not present in the instance.

Choosing artefacts therefore has to come from the specification you are implementing against, declared explicitly — never inferred from the file. Inferring it is how a validator ends up reporting confident results against the wrong rule package.

What these tools do today

The CII viewer opens a Cross Industry Invoice — including XML extracted from a Factur-X PDF — and shows the parties, lines, VAT breakdown, totals and payment details, plus the guideline identifier the document declares. That is usually enough to answer "what is my system actually producing?", which is the question that dominates early implementation.

The UBL validator runs the OASIS XML Schema and then the official EN 16931 business rules for the UBL 2.1 syntax, and reports a verdict per layer. That is the European core, without the French additions.

The France e-invoice validator is the one that answers the French question. It executes the official FNFE-MPE France_RFE 1.4.0.04 stylesheets against a document you choose a contract for:

• UBL 2.1 — EN16931 and EXTENDED-CTC-FR, each followed by the BR-FR-* national rules and their advisory companion.
• CII D22B — the same two profile families, with the release coming from the target you select rather than from the file.
• Factur-X — BASIC WL, EN16931 and EXTENDED, run against the invoice extracted from the PDF.

Every finding carries the artefact version that produced it, and each layer reports separately — a layer that did not run says so rather than inheriting the previous layer's success.

What none of this is: an acceptance. A clean result means the document satisfies the pinned rule packages named on the report. It is not a statement by the DGFiP, a PDP or Chorus Pro, this site submits nothing anywhere, and PDF/A-3 conformance is not checked — establishing that needs a conformance checker such as veraPDF against several hundred structural requirements.

Where to get the authoritative documents

The external specifications and the French validation artefacts are published by the DGFiP and by FNFE-MPE. Because fix levels change, take the current version from the official repositories at the time you implement rather than from a secondary source — including this one.