Facturation électronique en France

Ce site est indépendant et n’est affilié ni à la DGFiP, ni à la FNFE-MPE, ni à aucune administration fiscale. eDocument Tools permet la validation technique locale des formats français de facturation électronique pris en charge. Les documents UBL et CII peuvent être contrôlés avec les jeux de règles France_RFE 1.4.0.04 épinglés, pour les cibles EN16931 et EXTENDED-CTC-FR en UBL et les deux mêmes en CII D22B. Les profils Factur-X pris en charge — BASIC WL, EN16931 et EXTENDED — peuvent également être inspectés et validés avec les règles françaises correspondantes.

La validation est effectuée localement dans votre navigateur et ne constitue ni une acceptation, ni une certification, ni une transmission par la DGFiP, une PDP, Chorus Pro ou une autre autorité. La conformité PDF/A-3 n’est pas vérifiée.

Ce que la réforme exige, techniquement

La réforme française rend la facturation électronique structurée obligatoire pour les transactions interentreprises domestiques, et ajoute une obligation de transmission des données de transaction et de paiement à l’administration fiscale. Pour qui met en œuvre, cela se traduit par trois obligations techniques : émettre les factures dans une syntaxe structurée acceptée, les échanger via une plateforme accréditée plutôt que par courriel, et satisfaire les règles de gestion françaises qui se superposent aux règles européennes.

Les échéances et les modalités d’accréditation des plateformes ont évolué plus d’une fois et relèvent des sources officielles plutôt que d’un site d’outillage : consultez les publications de la DGFiP et les spécifications externes en vigueur. Ce qui est resté stable, c’est l’architecture de formats décrite ci-dessous.

Le calendrier actuel — qui reçoit et qui émet, à partir de quand — est résumé avec ses sources officielles dans notre guide du calendrier 2026–2027, daté et revérifié à chaque changement.

Les trois syntaxes acceptées

• UN/CEFACT CII — la Cross Industry Invoice, en XML. C’est la syntaxe la plus étroitement associée à la réforme française, et celle qui est transportée dans Factur-X.
• UBL — l’Universal Business Language de l’OASIS, l’autre syntaxe EN 16931 et celle qu’utilise Peppol.
• Factur-X — un fichier PDF/A-3 contenant du XML CII incorporé. Techniquement, ce n’est pas un quatrième format : la moitié lisible par la machine est du CII.

Les trois expriment le modèle sémantique EN 16931. Les exigences françaises sont des règles de gestion supplémentaires sur ce modèle, et non un format distinct : c’est pourquoi un document peut être un EN 16931 valide et échouer néanmoins à la conformité française.

Pourquoi Factur-X compte ici

Factur-X est la voie d’entrée pragmatique. Un fournisseur qui a toujours envoyé ses factures en PDF par courriel peut continuer à produire quelque chose qu’une personne reconnaît, pendant que le système récepteur lit le XML incorporé. Cela réduit énormément le coût d’adoption par rapport à une obligation de XML pur, et explique qu’une grande partie de l’outillage français soit construite autour de ce format.

Conséquence pratique : « gérer Factur-X » recouvre deux problèmes distincts, l’extraction de la pièce jointe PDF et le traitement de la facture CII. Le second est le plus important, et c’est exactement le même problème que de traiter du CII simple.

Les couches de règles

Valider une facture française suppose d’exécuter plusieurs jeux de règles, dans l’ordre, et de savoir lequel a produit une anomalie :

• Le schéma XML de la syntaxe et de sa version UN/CEFACT ou OASIS.
• Les règles de gestion EN 16931 — le noyau européen.
• Les règles françaises — des contraintes supplémentaires publiées sous forme d’artefacts de validation versionnés, dont la famille BR-FR-* et l’extension CTC française.
• Les règles de profil Factur-X lorsque le document est un fichier Factur-X.

Ces paquets sont versionnés, et la version compte : des règles sont ajoutées et corrigées d’un correctif à l’autre. Un validateur qui récupère silencieusement « les dernières règles » vous donnera une réponse différente d’un jour à l’autre pour le même fichier. Ce site fige explicitement la version des artefacts et indique quelle version a produit chaque anomalie — aujourd’hui France_RFE 1.4.0.04, versionné dans le projet avec une empreinte SHA-256 par fichier et servi depuis ce domaine, jamais téléchargé en amont à l’exécution.

Le piège de la version

Les artefacts CII français visent une version UN/CEFACT précise. Il est tentant de faire « détecter » cette version par un outil à partir du document, puis de choisir les artefacts en conséquence. Cela ne fonctionne pas : toutes les versions UN/CEFACT publient la Cross Industry Invoice sous la même URI d’espace de noms, de sorte que la version n’est tout simplement pas présente dans l’instance.

Le choix des artefacts doit donc découler de la spécification que vous mettez en œuvre, déclarée explicitement — jamais d’une déduction faite sur le fichier. C’est ainsi qu’un validateur finit par rendre des résultats affirmatifs face au mauvais paquet de règles.

Ce que ces outils font aujourd’hui

Le visualiseur CII ouvre une Cross Industry Invoice — y compris un XML extrait d’un PDF Factur-X — et affiche les parties, les lignes, la ventilation de TVA, les totaux et les modalités de paiement, ainsi que l’identifiant de guide déclaré par le document. C’est généralement suffisant pour répondre à la question « qu’est-ce que mon système produit réellement ? », qui domine les débuts d’une mise en œuvre.

Le validateur UBL exécute le schéma XML de l’OASIS puis les règles de gestion EN 16931 officielles pour la syntaxe UBL 2.1, et rend un verdict par couche. C’est le socle européen, sans les ajouts français.

C’est le validateur France qui répond à la question française. Il exécute les feuilles de style officielles FNFE-MPE France_RFE 1.4.0.04 face à un document pour lequel vous choisissez un contrat :

• UBL 2.1 — EN16931 et EXTENDED-CTC-FR, suivies dans chaque cas des règles nationales BR-FR-* et de leur pendant consultatif.
• CII D22B — les deux mêmes familles de profils, la version provenant de la cible que vous sélectionnez et non du fichier.
• Factur-X — BASIC WL, EN16931 et EXTENDED, exécutés sur la facture extraite du PDF.

Chaque anomalie porte la version de l’artefact qui l’a produite, et chaque couche rend compte séparément : une couche qui n’a pas été exécutée le dit, au lieu d’hériter du succès de la précédente.

Ce que tout cela n’est pas : une acceptation. Un résultat sans anomalie signifie que le document satisfait les jeux de règles épinglés nommés sur le rapport. Ce n’est pas une décision de la DGFiP, d’une PDP ou de Chorus Pro, ce site ne transmet rien à personne, et la conformité PDF/A-3 n’est pas vérifiée — l’établir suppose un validateur de conformité tel que veraPDF, face à plusieurs centaines d’exigences structurelles.

Où trouver les documents faisant foi

Les spécifications externes et les artefacts de validation français sont publiés par la DGFiP et par la FNFE-MPE. Les niveaux de correctif évoluant, prenez la version en vigueur dans les dépôts officiels au moment où vous mettez en œuvre, plutôt que dans une source secondaire — y compris celle-ci.