Réforme de la facturation électronique 2026/2027 : Factur-X en .NET
À partir du 1er septembre 2026, les entreprises assujetties à la TVA en France doivent pouvoir recevoir des factures électroniques entre elles. Ce guide résume le calendrier, le rôle des plateformes agréées et les formats autorisés – et ce que cela signifie concrètement pour les éditeurs de logiciels et les développeurs d’ERP en .NET.
Calendrier 2026/2027
La réforme distingue deux obligations : recevoir des factures électroniques et émettre des factures électroniques (accompagnée de la transmission de données, le e-reporting, pour les opérations qui ne relèvent pas de l’e-invoicing, par exemple les ventes aux particuliers ou à l’international). Selon le calendrier publié par l’administration :
| Date | Réception | Émission et e-reporting |
|---|---|---|
| 1er septembre 2026 | Toutes les entreprises assujetties à la TVA | Grandes entreprises (GE) et entreprises de taille intermédiaire (ETI) |
| 1er septembre 2027 | – | Petites et moyennes entreprises (PME) et micro-entreprises |
La catégorie d’entreprise (GE, ETI, PME, micro-entreprise) se détermine selon les critères statistiques officiels (effectif, chiffre d’affaires, total de bilan). Pour un cas concret – groupe, entreprise étrangère, franchise en base de TVA – reportez-vous aux pages de l’administration ou à votre conseil.
Qui est concerné ?
- E-invoicing : les factures entre entreprises assujetties à la TVA établies en France (B2B domestique).
- E-reporting : les données de transaction et de paiement des opérations qui ne passent pas par l’e-invoicing, notamment B2C et international.
- Hors périmètre de cette réforme : les factures adressées au secteur public (B2G), qui passent déjà par Chorus Pro.
Pour les éditeurs, l’essentiel est simple : à partir de septembre 2026, presque tous les clients français de votre logiciel recevront des factures électroniques, et une large part devra en émettre au plus tard en septembre 2027.
Le rôle des plateformes agréées (PA)
Les factures électroniques ne s’échangent pas directement par e-mail : elles transitent par des plateformes agréées (PA), anciennement appelées plateformes de dématérialisation partenaires (PDP). Ces opérateurs sont immatriculés par l’administration fiscale ; la liste officielle est publiée sur impots.gouv.fr.
- Chaque entreprise choisit au moins une PA pour recevoir ses factures et s’inscrit dans l’annuaire central, qui indique à quelle plateforme adresser les factures.
- La PA contrôle les factures, les achemine vers la plateforme du destinataire et transmet les données requises à l’administration.
- Le portail public de facturation (PPF) gère l’annuaire et la concentration des données ; depuis la révision de 2024, il ne propose plus lui-même l’émission et la réception gratuites de factures.
Pour un logiciel de gestion, cela signifie : l’échange passe par une interface avec une ou plusieurs PA (API, SFTP, connecteurs), et la facture produite doit respecter les formats et règles qu’elles acceptent.
Les formats socles : Factur-X, UBL et CII
Toutes les plateformes doivent accepter au minimum trois formats, tous fondés sur la norme européenne EN 16931 :
| Format | Type | Particularité |
|---|---|---|
| Factur-X | Hybride (PDF/A-3 + XML CII) | Lisible par l’humain et par la machine ; technique identique au ZUGFeRD allemand |
| UBL | XML pur | Très répandu dans le réseau Peppol |
| CII (UN/CEFACT) | XML pur | Même modèle de données que le XML embarqué dans Factur-X |
Pour Factur-X, seuls les profils qui portent une facture complète conviennent – en pratique EN 16931 (anciennement COMFORT) ou EXTENDED. Les profils MINIMUM et BASIC WL ne contiennent pas toutes les données d’une facture. La réforme introduit en outre de nouvelles mentions (par exemple le numéro SIREN du client ou la nature des opérations) ; leur liste exacte et leur codification sont précisées dans les spécifications externes publiées par l’administration.
Ce que cela implique pour les éditeurs et développeurs ERP .NET
- Produire des données structurées. Le PDF « joli » ne suffit plus : votre logiciel doit générer un XML conforme EN 16931 (CII ou UBL), idéalement embarqué dans un PDF/A-3 pour Factur-X.
- Valider avant l’envoi. Une facture rejetée par la plateforme coûte du temps au support. Une validation en amont selon les règles Schematron officielles détecte les erreurs (montants, codes TVA, mentions manquantes) avant la transmission.
- Lire les factures reçues. À partir de septembre 2026, vos clients reçoivent des Factur-X : extraire le XML et reprendre les données directement en comptabilité évite la ressaisie.
- Raccorder une ou plusieurs PA. Le choix de la plateforme reste celui de l’entreprise ; votre logiciel doit donc pouvoir livrer des fichiers standard plutôt que dépendre d’un format propriétaire.
- Suivre l’évolution des règles. Factur-X, ses règles de validation et les spécifications françaises évoluent ; prévoyez des mises à jour régulières.
Comment Facturexa vous aide en .NET
Les bibliothèques Facturexa couvrent la partie format de la chaîne – hors ligne, dans votre propre application .NET 10, .NET 8 ou .NET Framework 4.8. L’échange avec une plateforme agréée reste du ressort de votre logiciel ou de la PA choisie.
Pour démarrer : la documentation montre l’intégration via NuGet en quelques lignes, et l’essai de 30 jours sans engagement permet de tester avec vos propres factures. Les tarifs sont détaillés sur la page Licence & tarifs.
Facturexa n’est pas une plateforme agréée et ne transmet aucune facture à l’administration : le moteur fonctionne entièrement en local et vos données de facturation ne quittent pas votre application.
Sources officielles
Le calendrier, la liste des plateformes agréées et les spécifications externes sont publiés et mis à jour par l’administration. Référez-vous en priorité à :
- impots.gouv.fr – espace professionnel (rubrique facturation électronique, liste des plateformes agréées)
- economie.gouv.fr – Tout savoir sur la facturation électronique
- FNFE-MPE – spécification Factur-X