Une réforme fiscale… qui est aussi une transformation des systèmes logiciels
La réforme ne demande pas aux entreprises de changer de format de facture. Elle demande aux éditeurs de logiciels de repenser leur architecture. C’est un changement d’échelle que beaucoup sous-estiment encore.
Dorian Keiflin – CEO IOPOLE
La réforme française de la facturation électronique est souvent présentée comme une obligation comptable et fiscale pour les entreprises. Cette lecture est incomplète.
Septembre 2026 : la bombe à retardement cachée dans les logiciels de gestion français
En parallèle, un chantier bien plus structurant est en cours : la transformation des architectures logicielles. ERP, logiciels de facturation, SaaS métiers : tous doivent repenser en profondeur leur fonctionnement.
En septembre 2026, plus de 4 millions d’entreprises assujetties à la TVA devront recevoir des factures électroniques. 72 % se disent prêtes. En réalité, seules 20 % émettent aujourd’hui leurs factures dans un format structuré conforme (Factur-X, CII, UBL). Derrière chacune de ces entreprises, un logiciel de gestion, de facturation, de caisse ou un ERP doit être adapté : 112 plateformes agréées sont immatriculées (au 26 mars 2026 : cf liste officielle de la DGFiP), mais ce sont des centaines d’éditeurs et des millions de configurations logicielles qui doivent suivre. L’enjeu pour l’État : refermer un manque à gagner de TVA estimé entre 20 et 25 milliards d’euros par an (estimation INSEE reprise par le Sénat).
Dans ce nouveau cadre, la facture n’est plus un simple document commercial. Elle devient un objet réglementé, suivi en temps réel dans une infrastructure fiscale interconnectée.
La Belgique a rendu la e-facturation obligatoire le 1er janvier. En 15 jours, le système a révélé des failles côté logiciels. La France entre dans le même dispositif en septembre. Les éditeurs sont-ils prêts ?
Comment fonctionne réellement la réforme ? (vue simplifiée du système)
La réforme repose sur une architecture structurée, visant à encadrer et fiabiliser les échanges de données.
Les entreprises émettent leurs factures et données via leurs logiciels, transmis à des Plateformes Agréées (PA) qui assurent les contrôles de conformité. Ces plateformes échangent avec le Portail Public de Facturation (PPF), chargé de centraliser les informations. Un annuaire permet d’identifier les entreprises et de router correctement les flux.
L’ensemble constitue un système cohérent dans lequel chaque donnée doit être qualifiée, contrôlée et transmise selon des règles précises, avec une forte exigence de fiabilité.
Deux types de flux coexistent dans ce système :
- Le e-invoicing : échange de factures électroniques entre entreprises françaises
- Le e-reporting : transmission de données de transaction et de paiement hors de ce périmètre
E-invoicing vs e-reporting : la distinction clé souvent mal comprise
La réforme repose sur une distinction structurante entre deux mécanismes complémentaires mais fondamentalement différents.
Le e-invoicing, les éditeurs commencent à le comprendre : c’est un document, un format, un flux. Le e-reporting, c’est une autre logique. On parle de données de transaction, de paiement, de périodes fiscales distinctes. C’est là que la complexité technique explose, et c’est le sujet le moins préparé aujourd’hui.
Dorian Keiflin – CEO IOPOLE
Le e-invoicing concerne l’échange de factures électroniques entre entreprises dans le cadre domestique. Il repose sur des formats structurés (Factur-X, UBL, CII) et s’inscrit dans une logique documentaire : la facture est l’objet central.
À l’inverse, le e-reporting ne repose pas sur des documents, mais sur des données. Il consiste à transmettre des informations de transaction et de paiement à l’administration fiscale, de manière périodique.
Cette distinction est essentielle :
- le e-invoicing repose sur des flux de factures,
- le e-reporting repose sur des flux de données fiscales.
C’est précisément cette différence de logique qui complexifie fortement les systèmes à mettre en place.
Le e-reporting : l’obligation que la plupart des entreprises n’ont pas encore vue venir
Parmi les composantes de la réforme, le e-reporting reste aujourd’hui l’un des sujets les moins bien compris, alors même qu’il est structurant.
Il impose aux entreprises de transmettre à l’administration fiscale toutes les données qui ne passent pas par la facturation électronique classique. Cela inclut notamment les ventes B2C, les transactions internationales ou encore certaines données de paiement.
L’objectif est clair : permettre à l’administration de disposer d’une vision exhaustive des flux économiques et des bases de TVA, au-delà du seul périmètre des factures électroniques.
Pour les éditeurs de logiciels, cela signifie gérer des données plus variées, issues de sources multiples, avec des logiques de traitement différentes.
Ce que couvre le e-reporting
Le périmètre du e-reporting se structure autour de trois grandes catégories d’opérations.
D’abord, les opérations B2C, c’est-à-dire les ventes à des particuliers ou à des entités non assujetties à la TVA. Ces données ne sont pas transmises de manière unitaire, mais agrégées, généralement à la journée.
Ensuite, les opérations B2B internationales, qui concernent les transactions entre entreprises dès lors qu’elles sortent du périmètre domestique. Contrairement au B2C, elles sont traitées de manière unitaire, facture par facture.
Enfin, les données de paiement, qui viennent compléter les informations de transaction. Elles peuvent être soumises à des règles spécifiques, notamment en cas de TVA à l’encaissement, et sont souvent déconnectées dans le temps des transactions auxquelles elles se rattachent.
Le point critique : transaction ≠ paiement
L’un des principaux points de complexité du e-reporting réside dans la dissociation entre transaction et paiement.
Ces deux événements ne coïncident pas toujours. Une vente peut être réalisée à une date donnée, son paiement intervenir plus tard, en plusieurs fois ou via différents canaux : acomptes, règlements fractionnés, parcours omnicanaux mêlant e-commerce et point de vente physique.
Résultat : une transaction et son paiement peuvent relever de périodes fiscales différentes.
Les logiciels doivent donc gérer ces deux dimensions séparément, ce qui constitue un changement architectural majeur par rapport aux logiques traditionnelles.
Pourquoi la réforme change l’architecture des logiciels
La complexité ne vient pas du XML… mais de la logique métier.
Les logiciels doivent désormais gérer simultanément : la vérification d’identité (KYC), la qualification fiscale des opérations, la distinction entre transaction, facture et paiement, les règles de TVA par période, et l’interopérabilité avec les plateformes agréées.
Dans ce contexte, la conformité ne peut plus être traitée comme une simple fonctionnalité. Elle devient une couche technique structurante, intégrée au cœur même des systèmes.
Les principaux risques techniques (et sources de rejet)
Le Portail Public de Facturation applique des contrôles rigoureux sur les flux transmis. Ces contrôles portent notamment sur la cohérence des données, leur unicité, leur rattachement à la bonne période et leur conformité structurelle.
Dans la pratique, de nombreuses erreurs proviennent d’une mauvaise compréhension des règles métier. Une qualification fiscale incorrecte, une confusion entre transaction et paiement, une agrégation réalisée trop tôt ou encore une absence de traçabilité peuvent entraîner des rejets.
Ces rejets impliquent des corrections, des renvois de flux et une complexité opérationnelle accrue, parfois difficile à gérer à grande échelle. C’est ce qui s’est confirmé avec le déploiement à grande échelle en Belgique en janvier dernier (source : Bilan Go-Live Belgique) .
Ce que le déploiement belge a déjà démontré
La Belgique a rendu la facturation électronique obligatoire le 1er janvier 2026, via le réseau Peppol. Quinze jours après le lancement, les premières tensions étaient visibles.
Le bilan est instructif : sur près d’un million d’entreprises inscrites, 5 catégories de problèmes ont émergé massivement :
- factures techniquement transmises mais illisibles par les logiciels comptables
- identifiants Peppol incorrectsc
- hamps UBL non pris en charge
- clients rattachés au mauvais point d’accès
- et adoption déclarative sans usage réel.
Le constat est net : le réseau a tenu. Ce sont les logiciels métiers et points d’accès qui ont créé les difficultés.
C’est précisément le scénario que la France doit anticiper. La date de septembre 2026 approche avec les mêmes risques structurels : une infrastructure réglementaire solide, des logiciels insuffisamment préparés à la logique métier.
Calendrier de la réforme
- 1er septembre 2026 : toutes les entreprises doivent pouvoir recevoir des factures électroniques. Les grandes entreprises et ETI doivent également émettre et transmettre leurs données de e-reporting.
- 1er septembre 2027 : généralisation à l’ensemble des entreprises.
Ce que la réforme révèle : la conformité devient une infrastructure
Au-delà de son objectif fiscal, la réforme met en évidence une évolution plus large du rôle de la conformité dans les systèmes numériques.
Celle-ci tend à devenir une véritable infrastructure logicielle, comparable à des briques essentielles comme le paiement ou la vérification des identités. Elle repose sur des API, des standards et des processus automatisés, intégrés au cœur des architectures.
Cela implique de nouvelles exigences pour les éditeurs : expertise technique spécifique, veille réglementaire continue et capacité à faire évoluer rapidement leurs systèmes.
La conformité fiscale est en train de devenir une brique d’infrastructure au même titre que le paiement ou l’identité numérique. Les éditeurs qui l’intègrent comme une couche technique durable, et pas comme un patch réglementaire, prendront une avance considérable.
Dorian Keiflin – CEO IOPOLE
Ce n’est plus une fonctionnalité. C’est une brique d’infrastructure.
Une réforme française, une trajectoire européenne
La réforme française ne constitue pas un cas isolé. Elle s’inscrit dans un mouvement de fond à l’échelle de l’Union européenne, formalisé le 11 mars 2025 avec l’adoption définitive du paquet ViDA (VAT in the Digital Age) par l’ECOFIN.
ViDA repose sur trois piliers :
- la dématérialisation des échanges et le reporting fiscal en temps réel
- de nouvelles obligations TVA pour les plateformes numériques
- et la simplification de l’enregistrement TVA à l’échelle européenne.
Le pilier le plus structurant entre en vigueur le 1er juillet 2030 : e-invoicing obligatoire et Digital Reporting Requirements (DRR) pour toutes les transactions B2B intra-communautaires.
Le signal fort pour les éditeurs : les États membres dont les systèmes de reporting domestique ont été lancés après le 1er janvier 2024 devront s’aligner sur le standard ViDA. Les systèmes antérieurs, dont le dispositif français, ont jusqu’au 1er janvier 2035 pour converger.
Autrement dit : la France a construit son propre système avant que l’Europe ne fixe le standard commun.
Le piège pour un éditeur, c’est de penser que la France est la ligne d’arrivée. Ses clients vendent à l’international, reçoivent des factures de fournisseurs étrangers, opèrent sur des marchés où les règles changent en permanence. ViDA, Peppol, les mandats nationaux qui se multiplient : personne ne peut anticiper seul tous ces scénarios. C’est un métier à part entière, et les éditeurs qui essaient de tout internaliser prennent un risque technique et un risque de time-to-market.
Martin ROMERIO - CMO IOPOLE
C’est une fenêtre, pas une exemption. Les éditeurs qui s’y conforment aujourd’hui devront anticiper une deuxième migration d’ici 2035.
Ce mouvement n’est pas isolé. L’Italie a été pionnière avec son système SdI. La Pologne (KSeF), la Roumanie, la Belgique et l’Allemagne ont toutes engagé leurs propres mandats. ViDA a vocation à harmoniser ces systèmes divergents pour les transactions transfrontalières d’ici 2030, via un standard commun : EN 16931, et un réseau d’interopérabilité déjà opérationnel : Peppol.
L’enjeu pour les éditeurs est donc double : être conformes à la réforme française en 2026-2027, et ne pas construire des architectures qui devront être entièrement reprises en 2035.
La réforme française n’est pas une contrainte locale. C’est le premier maillon d’une infrastructure fiscale européenne en construction.
Ce que la réforme change pour les logiciels
Les impacts ne sont pas uniformes. Chaque catégorie d’éditeur fait face à des défis spécifiques.
Les solutions de caisse traitent des volumes massifs de transactions B2C : l’agrégation quotidienne devient une contrainte opérationnelle centrale, avec des règles de période strictes.
Les plateformes e-commerce doivent gérer des parcours omnicanaux où une même commande peut impliquer plusieurs paiements, plusieurs canaux et plusieurs périodes fiscales. La dissociation transaction/paiement y est structurelle.
Les logiciels de services soumis à la TVA à l’encaissement font face à une logique temporelle inverse : le fait générateur TVA est le paiement, pas la vente. Ce qui implique un suivi des encaissements facture par facture, potentiellement sur des mois.
Les solutions internationales doivent composer avec des règles fiscales multiples, des devises différentes, et un e-reporting unitaire pour chaque transaction transfrontalière.
Dans tous les cas, la complexité n’est pas optionnelle. Elle est intégrée au cœur du produit, ou elle devient une dette technique.
À retenir
- La réforme ne dématérialise pas la facture : elle transforme l’architecture des logiciels
- Le e-reporting est aussi structurant que le e-invoicing, et bien moins compris
- Transaction et paiement sont deux événements distincts, qui peuvent relever de périodes fiscales différentes
- La conformité devient une infrastructure logicielle, pas une fonctionnalité
- La réforme française est le premier maillon d’un système européen qui converge vers 2030-2035
La facturation électronique ne transforme pas seulement les obligations des entreprises.
Elle redéfinit la manière dont les logiciels sont conçus, interconnectés et pilotés.
Les éditeurs qui traitent cette complexité comme une infrastructure durable, et non comme une contrainte à court terme, prendront une longueur d’avance significative, en France d’abord, en Europe ensuite.
ANNEXE 1 : Le flux 10 (e-reporting) : structure simplifiée
Le e-reporting repose sur un format d’échange spécifique, appelé “flux 10”, qui structure les données en quatre blocs distincts.
Les blocs 10.1 et 10.2 concernent respectivement les factures internationales et leurs paiements, selon une logique unitaire. Chaque facture ou encaissement est transmis individuellement.
Les blocs 10.3 et 10.4 couvrent quant à eux les transactions et paiements B2C, selon une logique agrégée. Les données sont regroupées par période, généralement à la journée.
| Bloc | Contenu | Logique |
| 10.1 | Factures internationales | Unitaire |
| 10.2 | Paiements internationaux | Unitaire |
| 10.3 | Transactions B2C | Agrégée |
| 10.4 | Paiements B2C | Agrégée |
Cette structuration reflète une logique simple mais fondamentale :
- les flux internationaux sont détaillés,
- les flux B2C sont consolidés.
ANNEXE 2 : Approche recommandée (consensus technique)
Face à cette complexité, une approche fait consensus : partir de la donnée unitaire pour construire l’agrégation réglementaire.
Concrètement, cela consiste à collecter les données à un niveau fin, à les qualifier fiscalement, à les rattacher à la bonne période, puis à les agréger au moment opportun pour produire les flux attendus.
Cette méthode permet de garantir une meilleure traçabilité, de faciliter les corrections en cas d’erreur et de limiter les risques de rejet par les plateformes.
IOPOLE : une infrastructure technique pour les éditeurs
Dans ce contexte, des acteurs spécialisés émergent pour absorber cette complexité réglementaire.
Iopole propose une couche technique API-first en marque blanche, couvrant e-invoicing, e-reporting et interopérabilité Peppol, sans développer de brique métier concurrente aux éditeurs.
Immatriculée parmi les premières Plateformes Agréées par la DGFiP en décembre 2025, l’infrastructure repose sur un cloud souverain français certifié SecNumCloud, et anticipe déjà la convergence vers les standards européens ViDA.
A propos
C’est dans ce contexte qu’émergent de nouveaux acteurs techniques, positionnés sur cette couche de conformité. Parmi eux, Iopole propose un éclairage expert sur les enjeux techniques et réglementaires auxquels font face les éditeurs de logiciels, en apportant une lecture opérationnelle des transformations en cours.
En savoir plus
Site web : https://www.iopole.com/
LinkedIn : https://www.linkedin.com/company/iopole/
