— 30 mars 2026 · 13 min de lecture

France e-invoicing 2026 : le calendrier, vraiment.

Le calendrier français de la facturation électronique a été réécrit plusieurs fois en trois ans. La version de mars 2026, celle qui s'applique, tient en trois dates : septembre 2026 pour la réception, septembre 2027 pour l'émission des grands groupes et ETI, septembre 2028 pour les PME et TPE. L'éditeur qui prépare son outillage doit construire à partir de ces dates : tout le reste est commentaire.

Ce qui a changé depuis l'annonce initiale

Le projet français de facturation électronique B2B est piloté par la Direction générale des finances publiques (DGFiP), avec l'Agence pour l'informatique financière de l'État (AIFE) comme opérateur technique. La trajectoire initiale prévoyait un démarrage en juillet 2024, repoussé une première fois à septembre 2026 pour la réception, puis stabilisé par la loi de finances pour 2024 et confirmé par le décret du 25 juin 2024. Le calendrier actuel résulte de deux ans de négociation entre la DGFiP, les plateformes candidates au statut de PDP, les organisations professionnelles et les éditeurs de logiciels.

Trois points sont aujourd'hui stables et ne sont plus en débat. D'abord, le réseau français est obligatoire : il s'agit d'un mandat législatif, pas d'un encouragement. Ensuite, le périmètre est B2B domestique : les flux intracommunautaires et internationaux restent gouvernés par les règles européennes existantes et, à terme, par la directive ViDA (VAT in the Digital Age) lorsqu'elle entrera en application. Enfin, l'architecture retenue est dite en Y : les factures transitent par des plateformes privées agréées (PDP) ou par une plateforme publique gratuite (PPF, le portail public de facturation), avec une remontée systématique des données fiscales au « Public ».

Les trois dates à graver

La séparation entre réception et émission est essentielle. À partir de septembre 2026, toutes les entreprises françaises — y compris la TPE qui n'émet aucune facture en propre — doivent être capables de recevoir une facture électronique. C'est la rupture la plus immédiate du calendrier : elle touche instantanément 4 millions d'entreprises, et elle conditionne mécaniquement l'usage chez tous les grands comptes émetteurs qui basculent à la même date.

L'émission échelonnée, elle, sert à étaler la charge d'intégration côté éditeurs et côté partenaires SCM. Une entreprise de taille intermédiaire qui doit basculer en septembre 2027 a typiquement entre cinq cents et plusieurs milliers de clients à connecter en émission — un projet de douze à dix-huit mois. La période de transition 2026-2028 verra coexister, dans le même fichier comptable, des factures papier émises et des factures électroniques reçues. Cette coexistence est légalement valide ; elle sera juste fastidieuse à archiver.

PDP, PPF, l'architecture en Y

Le réseau français repose sur trois types d'acteurs, dont l'éditeur de logiciel doit comprendre l'articulation pour ne pas se tromper de cible technique.

• Le PPF — Portail public de facturation, opéré par l'AIFE pour le compte de la DGFiP. Service public, gratuit, mais minimaliste : il accepte le dépôt manuel ou par API d'un fichier au format imposé, contrôle, transmet, et fait remonter les données fiscales. Le PPF est conçu comme un filet de sécurité pour les entreprises qui ne souhaitent pas s'appuyer sur une plateforme privée. Il ne propose ni mapping, ni archivage à valeur probante, ni connecteur ERP, ni interopérabilité avec d'autres réseaux européens.
• Les PDP — Plateformes de dématérialisation partenaires, opérateurs privés qui ont obtenu un agrément de la DGFiP au terme d'un dossier technique et d'un audit de sécurité. Au 1^er trimestre 2026, environ une centaine de plateformes sont déjà immatriculées (DGFiP publie la liste sur impots.gouv.fr). Quelques acteurs structurants : Cegedim, Iopole, Generix, Tenor, DocuWare, Esker, Yooz, Pagero, Sage, Cegid… mais aussi des éditeurs SCM internationaux et plusieurs access points PEPPOL.
• Les OD — Opérateurs de dématérialisation, intermédiaires non agréés qui s'appuient sur une PDP pour acheminer les factures. C'est l'option courante pour un éditeur de comptabilité qui ne souhaite pas porter lui-même l'agrément PDP : il s'adosse à une PDP existante en marque blanche.

La logique en Y signifie que toute facture, qu'elle transite par une PDP ou par le PPF, finit par déposer ses données fiscales (montants HT, TVA, parties identifiées par SIREN) dans le système central de la DGFiP. Le PPF, dans ce schéma, n'est plus la «  plaque tournante » initialement imaginée en 2022 : il est devenu une plateforme parmi d'autres, intégrée au réseau, avec un rôle de garant minimal et de portail de consultation pour la DGFiP.

Les trois formats acceptés (Factur-X, UBL, CII)

L'architecture française accepte trois formats de facture électronique, conformes à la norme EN 16931 dont les principes sont détaillés sur la page PEPPOL ediverse.

• Factur-X — format hybride PDF/A-3 + XML CII (Cross Industry Invoice). Le PDF contient la représentation visuelle conforme aux usages comptables français ; le XML embarqué porte la sémantique EN 16931. Maintenu côté France par le FNFE-MPE (Forum National de la Facture Électronique), Factur-X est aussi le format ZUGFeRD côté allemand. La spécification 1.0 est gratuite et publiée par le FNFE.
• UBL 2.1 — format XML pur, identique à celui transporté sur le réseau PEPPOL pour BIS Billing 3.0. C'est le format privilégié pour les flux 100 % machine-to-machine, sans génération de PDF.
• CII (UN/CEFACT Cross Industry Invoice) — format XML hérité du UN/CEFACT, syntaxe officielle de Factur-X mais utilisable seul, sans le PDF enveloppant.

Les trois formats sont sémantiquement équivalents au sens d'EN 16931 — ils portent les mêmes business terms (BT-1 à BT-200+) et passent les mêmes business rules. La différence est syntaxique : UBL et CII sont deux dialectes XML pour exprimer le même contenu. Une PDP doit donc accepter et émettre les trois, et savoir convertir sémantiquement entre eux — d'où l'importance, pour l'éditeur, de raisonner d'abord en EN 16931, et seulement ensuite en format.

Ce que l'éditeur doit planifier dès maintenant

Pour un éditeur de logiciel (comptable, facturation, ERP) dont les utilisateurs sont majoritairement français, le plan technique tient en six chantiers. Aucun n'est trivial, et leur enchaînement conditionne la capacité à livrer dans le calendrier.

1. Décider PDP ou OD : porter l'agrément PDP en propre est un projet réglementaire de douze à dix-huit mois, avec un coût récurrent significatif (audit annuel, ISO 27001 ou équivalent, mises à jour de cahier des charges). Beaucoup d'éditeurs choisissent l'option OD en s'adossant à une PDP existante : c'est plus rapide mais cela introduit une dépendance commerciale forte.
2. Implémenter Factur-X 1.0 : producteur côté émission, lecteur côté réception. Un Factur-X est un PDF/A-3 portant un XML CII attaché : il faut maîtriser à la fois la génération PDF/A-3 et la sérialisation CII conforme à EN 16931.
3. Implémenter UBL 2.1 Invoice + CreditNote : pour l'interopérabilité PEPPOL et pour les clients qui exigent UBL pur. Le mapping entre la facture interne et l'XML UBL est la pièce la plus délicate : les bibliothèques génériques mappent souvent mal les cardinalités EN 16931 et il faut écrire le sérialiseur à la main.
4. Brancher la validation Schematron : PEPPOL BIS Billing 3.0 publie des fichiers Schematron pour les règles TC434 et les règles PEPPOL. Le profil français y ajoute les règles BR-FR. La validation Schematron tourne typiquement avec Saxon (Java) ou Schxslt (XSLT 2.0) ; en production, mieux vaut une instance dédiée pour ne pas embarquer Saxon dans chaque déploiement.
5. Prévoir l'archivage légal : la durée de conservation des factures en France est de dix ans (Code de commerce). L'archivage doit garantir intégrité, traçabilité, et restitution lisible. Beaucoup de PDP proposent l'archivage à valeur probante en option ; sinon, il faut le contractualiser avec un tiers archiveur certifié.
6. Préparer la consultation DGFiP : les données fiscales remontées au PPF sont consultables par l'entreprise via un portail. L'éditeur peut soit refléter ces données dans son interface, soit s'en remettre au portail public. Le premier choix améliore l'expérience utilisateur mais demande de gérer une intégration API supplémentaire.

Ce qui bloque encore en mars 2026

Plusieurs zones d'ombre subsistent à six mois de l'échéance de réception. La spécification des flux de cycle de vie (statuts « refusée », « suspendue », « réglée ») n'est stabilisée que depuis fin 2025, et plusieurs PDP attendent encore les derniers correctifs de la spécification AIFE pour finaliser leurs développements. La consultation des partenaires SCM montre que les connecteurs ERP sont prêts en standard pour SAP S/4 et pour les principaux ERP français, mais souvent à l'état de bêta pour les ERP plus rares. Enfin, l'articulation avec ViDA — la directive européenne adoptée en mars 2025 — reste à clarifier : ViDA impose un reporting en temps réel des opérations intracommunautaires à compter de 2028, et la France devra ajuster son dispositif domestique pour s'aligner.

Pour les éditeurs qui suivent le dossier depuis 2022, l'impression dominante est que la France a réussi à éviter le scénario italien de 2019 — où la mise en service du SdI avait été chaotique — au prix d'un calendrier plus lent. L'industrialisation progressive, en trois marches, donne aux acteurs le temps de roder leurs chaînes. Le revers est que tout retard supplémentaire désormais coûte cher politiquement : il n'y aura pas de quatrième report.

La fenêtre 2026 et le travail à faire

Pour un éditeur français qui n'a pas encore engagé son projet e-invoicing, mars 2026 est la dernière fenêtre raisonnable pour commencer. Le calendrier réception du 1^er septembre 2026 oblige tous les clients à pouvoir lire une facture électronique — donc, à minima, l'éditeur doit livrer un lecteur Factur-X et UBL dans son produit, et un connecteur vers au moins une PDP, avant la rentrée. La partie émission peut suivre dans les douze à vingt-quatre mois selon le segment client.

Le travail conceptuel — comprendre EN 16931, lire les Schematron PEPPOL, raisonner en business terms — est, paradoxalement, le plus rentable à faire en premier. Les formats changeront marginalement ; les business terms BT-1 à BT-200+ ne changeront plus. Pour le lecteur qui souhaite approfondir la sémantique européenne, la page PEPPOL chez ediverse et l'article précédent du blog sur EN 16931 donnent le socle ; ce billet-ci se concentre sur la composante française. Les deux lectures se complètent.