· Nolwen Brosson · Blog · 11 min read
Facture électronique : ce que la réforme change dans votre ERP ou votre logiciel métier
Depuis le 1er septembre 2026, toutes les entreprises assujetties à la TVA en France doivent pouvoir recevoir des factures électroniques. Les grandes entreprises et les ETI doivent aussi les émettre. Les PME, TPE et micro-entreprises ont jusqu’au 1er septembre 2027 pour faire de même.
La plupart des guides s’arrêtent à « choisissez une plateforme agréée ». C’est nécessaire, mais ce n’est pas là que se trouve le travail. Le travail est dans votre système d’information : l’ERP, l’outil de facturation maison ou l’application métier qui crée vos factures aujourd’hui. C’est lui qui doit produire des données structurées, suivre des statuts et dialoguer avec une API. Cet article explique ce que la loi impose techniquement, et ce que ça change dans votre code.
La réponse courte
Une facture électronique au sens de la réforme n’est pas un PDF envoyé par email. C’est un fichier structuré (Factur-X, UBL ou CII), conforme à la norme européenne EN 16931, qui passe obligatoirement par une plateforme agréée par la DGFiP. Pour votre logiciel, cela fait quatre chantiers :
- produire la facture dans un des trois formats autorisés, avec quatre nouvelles mentions obligatoires, dont le SIREN du client ;
- l’envoyer à votre plateforme agréée, idéalement par API ;
- suivre le cycle de vie de chaque facture (déposée, rejetée, refusée, encaissée) et réagir à chaque statut ;
- transmettre les données que la facture électronique ne couvre pas (ventes aux particuliers, international, paiements) via l’e-reporting.
Si vous utilisez un logiciel du marché, l’éditeur fait l’essentiel. Si vous avez un ERP ou un outil développé sur mesure, c’est à vous, ou à votre prestataire, de le faire.
Ce que dit la loi sur la facturation électronique
Le calendrier
| Entreprise | Réception | Émission et e-reporting |
|---|---|---|
| Grandes entreprises et ETI | 1er septembre 2026 | 1er septembre 2026 |
| PME, TPE et micro-entreprises | 1er septembre 2026 | 1er septembre 2027 |
La réforme concerne les échanges entre entreprises assujetties à la TVA établies en France (le « B2B domestique »). Les ventes aux particuliers et les opérations avec l’étranger restent hors du circuit de la facture électronique, mais leurs données doivent être déclarées à l’administration : c’est l’e-reporting.
Les sanctions
La loi de finances pour 2026 a relevé les amendes : 50 € par facture qui n’est pas émise sous forme électronique et 500 € par transmission d’e-reporting manquante, chacune plafonnée à 15 000 € par an. Une mention obligatoire absente ou erronée coûte 15 €. Ne pas avoir désigné de plateforme agréée expose à 500 € après mise en demeure, puis 1 000 € tous les trois mois.
En pratique, l’amende pèse moins que le blocage : une facture rejetée par la plateforme n’arrive pas chez votre client, donc elle n’est pas payée.
Comment circule une facture électronique
Le schéma retenu par l’État est dit « en Y ». Votre logiciel ne parle jamais directement à l’administration.
- Votre ERP produit la facture et la dépose sur votre plateforme agréée (PA).
- Votre PA contrôle le fichier, cherche la plateforme de votre client dans l’annuaire central, puis lui transmet la facture.
- La PA de votre client la met à disposition de son logiciel.
- En parallèle, les PA envoient un extrait des données et les statuts obligatoires au concentrateur de données de la DGFiP, qui s’en sert notamment pour préremplir les déclarations de TVA.
Le Portail public de facturation (PPF) devait au départ permettre d’émettre et de recevoir gratuitement. L’État y a renoncé en octobre 2024 : le PPF ne garde que deux rôles, l’annuaire et le concentrateur de données. Toutes les factures passent donc par des plateformes privées, dont plus d’une centaine sont aujourd’hui immatriculées. Entre elles, une partie des échanges transite par le réseau européen Peppol.
Conséquence pour votre architecture : vous n’intégrez qu’une seule plateforme, la vôtre. C’est elle qui gère le routage, l’annuaire et la relation avec l’administration.
Les formats de facture électronique : Factur-X, UBL ou CII
Trois formats sont autorisés. Tous expriment le même modèle de données, celui de la norme EN 16931 : mêmes champs, mêmes codes TVA, mêmes règles de calcul. Ils ne diffèrent que par la syntaxe.
| Format | Ce que c’est | Quand le choisir |
|---|---|---|
| Factur-X | Un PDF/A-3 lisible par un humain, avec un fichier XML (syntaxe CII) embarqué | Votre ERP génère déjà des PDF : c’est le chemin le plus court |
| UBL 2.1 | XML pur, très utilisé sur le réseau Peppol | Intégration API, clients ou filiales en Europe |
| CII | XML pur (UN/CEFACT), même syntaxe que le XML de Factur-X | Intégration API, ou flux Factur-X dont on veut retirer le PDF |
Les règles françaises sont précisées par trois normes AFNOR publiées sur le site des impôts : XP Z12-012 pour les formats, profils et statuts, XP Z12-013 pour les API, XP Z12-014 pour les cas d’usage B2B. La XP Z12-012 prévoit deux profils : EN 16931 pour la grande majorité des factures, et un profil étendu (EXTENDED-CTC-FR) pour les cas plus riches.
Notre conseil : ne construisez pas le XML à la main dans vos templates. Commencez par un objet facture propre dans votre modèle de données, sérialisez-le, puis validez le fichier avant l’envoi. En Python, la bibliothèque open source factur-x d’Akretion permet par exemple d’assembler le PDF et le XML et de vérifier le XML. Les plateformes contrôlent chaque fichier avec des règles de validation (Schematron) : une erreur de structure se traduit directement par un rejet.
Les nouvelles données à stocker dans votre ERP
La réforme ajoute quatre mentions aux mentions classiques (numéro, date, taux de TVA, etc.) :
- le SIREN du client ;
- l’adresse de livraison, si elle diffère de l’adresse de facturation ;
- la catégorie de l’opération : livraison de biens, prestation de services, ou les deux ;
- l’option pour le paiement de la TVA d’après les débits, si vous l’avez choisie.
Côté code, c’est souvent le chantier le plus sous-estimé. Le SIREN du client devient une donnée bloquante : sans lui, la plateforme ne trouve pas le destinataire dans l’annuaire et rejette la facture. Il faut ajouter le champ, le rendre obligatoire pour les clients professionnels, contrôler sa validité (un SIREN fait 9 chiffres et se vérifie avec l’algorithme de Luhn) et reprendre l’historique de la base clients. L’API Sirene de l’Insee permet de compléter et de vérifier les fiches en masse.
La catégorie d’opération, elle, se déduit des lignes de la facture. Il faut donc qualifier chaque article de votre catalogue (bien ou service), et pas seulement le client : un même client peut vous acheter du matériel et un contrat de maintenance.
Les statuts de la facture électronique : une machine à états
Dans beaucoup d’outils, une facture est un document figé : créée, envoyée, payée. Avec la réforme, elle porte des statuts normalisés qui circulent entre les plateformes. Quatre sont obligatoires et remontent à l’administration :
| Statut | Ce qu’il signifie | Ce que votre logiciel doit faire |
|---|---|---|
| Déposée | La facture est arrivée sur votre plateforme | Stocker l’identifiant attribué par la plateforme et passer la facture en « envoyée » |
| Rejetée | La plateforme l’a bloquée pour un motif technique : format, mention manquante, destinataire introuvable | Afficher le motif, corriger, redéposer. Ne pas la considérer comme émise entre-temps |
| Refusée | Votre client la conteste après réception | Lire le motif, puis corriger ou émettre un avoir |
| Encaissée | Le paiement est reçu (obligatoire pour les prestations de services) | Transmettre la date et le montant encaissé à la plateforme |
Les plateformes gèrent d’autres statuts (prise en charge, approuvée, en litige, etc.), utiles mais facultatifs.
« Encaissée » est le piège classique. C’est à vous, fournisseur, de le déclarer. Votre ERP doit donc connaître la date réelle des paiements, souvent issue du rapprochement bancaire, et la remonter à la plateforme. Un outil qui marque une facture « payée » à la main, sans date fiable, ne peut pas le faire correctement.
Techniquement, cela demande un champ de statut avec des transitions définies, l’identifiant de la facture côté plateforme, un historique horodaté, et un mécanisme pour recevoir les changements : webhook si la plateforme en propose, sinon interrogation régulière de son API.
Brancher votre ERP sur une plateforme agréée : trois options
1. Le portail de la plateforme
Vous exportez vos factures et les déposez à la main sur le portail web de la plateforme. Acceptable pour quelques factures par mois, pas au-delà : la double saisie revient, et les statuts restent en dehors de votre outil.
2. Le connecteur de votre éditeur
Si votre ERP est un logiciel du marché, l’éditeur propose en général un connecteur vers une ou plusieurs plateformes partenaires. Vérifiez qu’il gère les statuts dans les deux sens et l’e-reporting, pas seulement l’envoi des factures.
3. L’intégration par API
C’est l’option pour un ERP ou un outil développé sur mesure. La norme XP Z12-013 définit deux interfaces standard : la consultation de l’annuaire, et l’échange des factures et des statuts. La grande majorité des plateformes ont annoncé qu’elles l’implémenteraient. Si vous codez contre cette norme plutôt que contre l’API propriétaire d’une plateforme, vous pourrez changer de plateforme sans tout réécrire.
Ce qu’on vérifie systématiquement dans ce type d’intégration :
- l’authentification (souvent OAuth2) et le renouvellement des jetons ;
- l’idempotence : une facture renvoyée après un timeout ne doit pas être déposée deux fois ;
- les reprises automatiques en cas d’erreur réseau, avec une file d’attente plutôt qu’un appel synchrone au moment où l’utilisateur clique sur « Envoyer » ;
- les journaux : chaque dépôt, chaque statut et chaque erreur, horodatés ;
- l’environnement de test de la plateforme, pour valider les cas réels (avoirs, acomptes, factures à plusieurs taux de TVA) avant la mise en production.
C’est le même type de travail que lorsqu’on connecte un CRM à un outil de facturation ou qu’on ouvre un ERP à un agent IA pour générer des devis : la difficulté n’est pas l’appel d’API, c’est la qualité des données et la gestion des cas d’erreur.
ERP sur mesure ou outil maison : ce qui casse le plus souvent
- Les PDF générés en dur. Beaucoup d’outils internes construisent la facture directement dans un template PDF. Il faut séparer les données de leur présentation, sinon chaque évolution réglementaire devient un chantier.
- Les avoirs. Ce sont aussi des factures électroniques, et ils doivent faire référence à la facture d’origine.
- Les acomptes et les soldes. Chaque document doit rester cohérent avec les précédents, ce que les outils maison gèrent souvent par des bricolages.
- Les clients mal qualifiés. Particulier ou professionnel, France ou étranger : c’est cette information qui décide si une vente part en facture électronique ou en e-reporting. Une mauvaise valeur, et la vente part dans le mauvais circuit.
- Les sociétés multiples. Si vous facturez depuis plusieurs entités, chacune a son SIREN, sa plateforme et ses paramètres.
- Les factures fournisseurs. Vos fournisseurs soumis à l’obligation vous envoient déjà des fichiers structurés. Les intégrer directement dans votre outil évite la ressaisie et permet de rapprocher automatiquement facture et bon de commande.
Par où commencer quand on est une PME
Il reste moins de dix mois avant l’obligation d’émission. C’est court si votre outil de facturation a été développé en interne. L’ordre qu’on recommande :
- Choisir sa plateforme agréée (c’est déjà obligatoire pour la réception) et vérifier qu’elle expose une API conforme à la XP Z12-013, avec un environnement de test.
- Auditer les données : SIREN des clients, nature des articles, adresses de livraison, régime de TVA.
- Séparer les données et le rendu dans le module de facturation, puis générer un premier fichier Factur-X ou UBL et le valider.
- Brancher l’API de la plateforme en environnement de test, avec les statuts et l’e-reporting.
- Basculer progressivement, en commençant par un petit groupe de clients.
Si votre facturation repose sur un ERP ou un outil développé sur mesure, c’est exactement le type de chantier que nous menons chez Fenxi : reprise du modèle de données, génération des formats, intégration de la plateforme agréée et des statuts. Notre offre de développement d’application sur mesure couvre ces travaux, de l’outil interne à l’ERP complet. Pour vous faire une idée des budgets, voyez combien coûte une application sur mesure pour une PME. Et si votre facturation tient aujourd’hui dans des tableurs, c’est peut-être le moment de passer à une vraie application métier.
Conclusion
La loi sur la facturation électronique est présentée comme une obligation comptable. Pour une entreprise qui a son propre outil, c’est surtout un projet logiciel : des données à fiabiliser, un format à produire, une API à intégrer et des statuts à suivre. Bien mené, il apporte aussi quelque chose en retour : des factures fournisseurs qui arrivent structurées, des encaissements mieux suivis, moins de ressaisie.
Pour suivre les évolutions des normes, le site de la FNFE-MPE, qui pilote les travaux de normalisation avec la DGFiP, est la référence. Et si vous voulez faire le point sur votre propre outil, l’équipe Fenxi Studio conçoit et fait évoluer des applications métier pour les PME et ETI. Pour découvrir l’agence et nos autres expertises, direction fenxi.fr.
