Facturation électronique : le calendrier était la partie facile
Le calendrier de la facturation électronique a été abondamment commenté. Ce qui casse quand on implémente réellement la norme, beaucoup moins. Quatre constats tirés du code.
Les cinq lignes signalées ci-dessous sont des intertitres : sélectionne-les une par une dans l'éditeur et applique "Choisir l'en-tête". Le reste est du paragraphe ordinaire.
Depuis le 1er septembre, toute entreprise assujettie à la TVA doit être capable de recevoir une facture électronique. Les grandes entreprises et les ETI doivent aussi en émettre. Les PME et les micro-entreprises suivront au 1er septembre 2027.
Ce calendrier a été abondamment commenté. Il est pourtant la partie la plus simple du sujet : trois dates, deux obligations. Ce qui l'a moins été, c'est ce qui casse quand on implémente réellement la norme. J'ai passé plusieurs mois à produire du Factur-X conforme. Voici quatre choses que je n'ai lues nulle part avant de les découvrir dans le code.
Un XML valide n'est pas une facture conforme
C'est le piège le plus coûteux, parce qu'il ne fait aucun bruit.
Vous générez votre fichier. Votre validateur XML l'accepte. Vos totaux tombent juste, HT, TVA et TTC se recoupent au centime. Tout indique que le travail est fait. Il ne l'est pas.
La conformité ne se juge pas à la bonne formation du XML, mais aux règles du profil, vérifiées par une validation Schematron. Ces règles portent sur la cohérence sémantique : quelles informations sont obligatoires ensemble, lesquelles s'excluent, comment un montant doit se déduire d'un autre. Un fichier peut franchir tous les contrôles syntaxiques et être rejeté pour une règle métier qu'aucun message d'erreur ne vous signalait.
Le symptôme typique : "ça marche chez moi". Tant que personne ne valide au profil, tout le monde croit avoir terminé.
Le format décide de ce que vous avez le droit d'exprimer
Une facture papier accepte tout ce que vous y écrivez. Une facture électronique, non.
Prenez une remise de 10 % sur une ligne. Pratique commerciale banale. Dans le profil BASIC retenu en France, les champs qui porteraient le pourcentage et sa base de calcul au niveau de la ligne sont interdits. La norme ne les prévoit pas à cet endroit. Il reste à inscrire le taux dans un champ de texte libre, lisible par un humain, inexploitable par une machine.
Ce n'est pas un défaut de l'outil, c'est la norme qui en décide. Et cela renverse une habitude : le format n'est pas un conteneur dans lequel vous versez votre facture, c'est une grammaire à laquelle votre facture doit se plier. Certaines pratiques commerciales parfaitement légales n'ont pas de place structurée. Il faut le savoir avant de promettre à un client que tout sera repris à l'identique.
Produire le format n'est pas transmettre la facture
C'est la confusion la plus répandue, et celle qui coûtera le plus cher aux petites structures.
Deux métiers distincts se cachent derrière le mot "conforme". Le premier consiste à produire un fichier Factur-X valide. Le second consiste à l'acheminer, via une plateforme agréée, jusqu'à la plateforme de votre client et jusqu'à l'administration.
Un logiciel peut exceller au premier et ne rien transmettre du tout. Une plateforme agréée, à l'inverse, transporte ce qu'on lui remet, conforme ou non. Les deux sont nécessaires, et presque aucune communication commerciale ne les distingue.
La question à poser à un éditeur n'est donc pas "êtes-vous conforme". Elle est : lequel des deux faites-vous, et qui fait l'autre.
La facture devient immuable, et le logiciel doit suivre
Une facture émise ne se modifie pas et ne se supprime pas. Une erreur se corrige par un avoir, qui laisse les deux pièces lisibles. Tout comptable le sait depuis toujours.
Ce qui change, c'est que ce principe cesse d'être une règle que l'on respecte pour devenir une contrainte que la machine impose. Beaucoup d'outils de facturation permettent aujourd'hui de rouvrir une facture partie chez le client, d'en corriger le montant, voire de la supprimer. Cela devient intenable.
La conséquence technique est plus profonde qu'il n'y paraît. Si une facture émise ne peut plus disparaître, alors la numérotation ne doit jamais comporter de trou. Supprimer un brouillon impose de faire reculer le compteur. Et une facture annulée par un avoir ne doit jamais pouvoir redevenir payée, sous peine de rentrer une seconde fois dans le chiffre d'affaires. Ce sont des invariants à tenir en base de données, pas des conventions d'équipe.
Ce qu'il faut en retenir
Pour un indépendant, septembre 2027 paraît lointain. Mais l'obligation de réception est déjà en vigueur, pour tout le monde, y compris en franchise en base de TVA. Vos fournisseurs basculent, et leurs factures ne vous parviendront plus par simple courriel.
Trois questions suffisent à évaluer un outil, et aucune ne porte sur le calendrier.
Vos fichiers sont-ils validés au Schematron du profil, et pouvez-vous me montrer un rapport ? Si la réponse parle de XML valide, ce n'est pas la même chose.
Produisez-vous le format, transportez-vous les factures, ou les deux ? S'il ne fait que le premier, demandez par quelle plateforme agréée passe le transport.
Que se passe-t-il quand je veux corriger une facture déjà envoyée ? Si l'outil vous laisse la modifier, il vous prépare un problème.
La réforme ne demande pas d'être prêt à une date. Elle demande que vos factures deviennent des documents que des machines peuvent lire et que personne ne peut réécrire. C'est un changement de nature, pas d'échéance.