Factur-X rejetée : les 9 erreurs trouvées en déposant de vraies factures sur une plateforme agréée
Le 18 septembre 2026, il nous a fallu quatre dépôts sur le bac à sable d'une plateforme agréée : neuf règles EN 16931 et françaises que notre validateur ne voyait pas. Règle, symptôme, correction.
La rédaction OdocPilot · 2026-09-25
Factur-X rejetée : les 9 erreurs trouvées en déposant de vraies factures sur une plateforme agréée
Une facture Factur-X est rejetée quand elle enfreint une règle de gestion de la norme EN 16931 ou une règle française « BR-FR », même si son XML passe le contrôle de structure (XSD). Le 18 septembre 2026, il nous a fallu quatre dépôts sur le bac à sable d'une plateforme agréée pour qu'une facture produite par OdocPilot soit acceptée : notre propre validateur ne voyait pas neuf non-conformités. Voici, pour chacune, la règle, le symptôme et la correction.
Ce que nous avons testé le 18 septembre 2026
Le test portait sur une seule facture, F-2026-0001, générée par OdocPilot au profil EN 16931 de Factur-X, puis déposée sur le bac à sable d'une plateforme agréée. Nous ne la nommons pas ; la liste officielle des plateformes est publiée par impots.gouv.fr. La chaîne complète a été parcourue : génération, dépôt, validation officielle (statut 200, facture déposée), acheminement vers la plateforme de réception (statuts 201 puis 202), et accusé remonté dans l'application.
Quatre dépôts ont été nécessaires. Les trois premiers ont été rejetés avec une liste d'anomalies précises. Rien de tout cela n'était visible dans notre validateur maison, qui contrôlait la structure XML et quelques totaux.
Précision utile : un rejet par la plateforme n'est pas un refus par le client. Le guide pratique de démarrage de la DGFiP (juillet 2026, question 11) décrit le rejet comme une difficulté de transmission ou de contrôle (erreur de format, donnée obligatoire absente ou incohérente) à corriger puis redéposer ; le refus est un statut posé par l'acheteur, pour des motifs limités (question 12).
!Factur-X rejetée : les 9 erreurs trouvées en déposant de vraies factures sur une plateforme agréée Photo : RDNE Stock project — Pexels
Pourquoi un fichier « valide » peut être rejeté
Trois niveaux de contrôle s'empilent, et beaucoup d'outils ne testent que le premier.
- Le schéma XSD vérifie que le XML est bien formé et que les balises sont au bon endroit. C'est le minimum.
- Les règles de gestion EN 16931 (les « BR-xx ») vérifient le sens : chaque ligne a une quantité, les totaux se recoupent, un vendeur au taux normal a un identifiant fiscal. Elles sont publiées sous forme de schematron par la Commission européenne (dépôt ConnectingEurope).
- Les règles françaises « BR-FR » ajoutent ce que la réforme exige : adresses de routage, SIREN, mentions légales codées, cadre de facturation. Elles découlent des normes AFNOR XP Z12-012 à XP Z12-014, référencées par l'administration, et sont implémentées dans le schematron du FNFE-MPE (dépôt France_RFE, version 1.4.0.04 du 4 septembre 2026).
Nos neuf erreurs : deux sur les adresses de routage, cinq au niveau EN 16931, deux au niveau français (dont une triple). Aucune n'était une erreur de structure. Un fichier « valide » pour un XSD peut donc être rejeté sans appel ; seule la validation de la plateforme fait foi.
Erreurs 1 et 2 — BT-34 et BT-49 : les adresses électroniques du vendeur et de l'acheteur
Ce que la règle exige. Dans EN 16931, l'adresse électronique du vendeur (BT-34) et celle de l'acheteur (BT-49) sont facultatives, mais si elles sont présentes, elles doivent porter un identifiant de schéma (règles BR-62 et BR-63). En France, elles deviennent obligatoires : le schematron FNFE-MPE contient BR-FR-12 (« Le BT-49 est obligatoire ») et BR-FR-13 (« Le BT-34 est obligatoire »), et BR-FR-21 impose, pour une facture entre entreprises, que le BT-49 commence par le SIREN de l'acheteur avec le schéma « 0225 ». Ce code 0225 est enregistré dans la liste ISO 6523 sous le nom « FRCTC ELECTRONIC ADDRESS » (liste ICD publiée par Peppol).
Le symptôme. Notre XML ne contenait ni BT-34 ni BT-49. Le PDF affichait bien les deux SIREN, mais la plateforme n'a rien pu router.
La correction. Ajouter, dans le bloc vendeur et dans le bloc acheteur, un élément URIUniversalCommunication/URIID avec schemeID="0225" et le SIREN comme valeur. C'est cette adresse, et non l'e-mail, qui permet à la plateforme de trouver celle du client dans l'annuaire.
Erreurs 3 à 6 — BR-22, BR-23, BR-26, BR-27 : chaque ligne doit être complète
Ce que la règle exige. Le schematron européen est sans ambiguïté : chaque ligne de facture doit avoir une quantité facturée, BT-129 (BR-22), un code d'unité de mesure, BT-130 (BR-23), un prix unitaire net, BT-146 (BR-26), et ce prix ne doit pas être négatif (BR-27) (texte des règles). Ce n'est pas une invention de la norme : l'article L441-9 du Code de commerce exige déjà la quantité, la dénomination précise et le prix unitaire hors TVA de chaque produit ou service.
Le symptôme. Sur les lignes « au forfait », notre générateur écrivait un montant sans quantité ni unité, et sans prix unitaire séparé. Lisible pour un humain, invalide pour la machine. Une remise saisie comme prix négatif déclenchait BR-27.
La correction. Toujours écrire une quantité (1 pour un forfait), une unité (C62 pour « unité », HUR pour « heure ») et un prix unitaire égal au montant. Porter les remises dans le bloc dédié aux réductions, jamais dans le prix.
Erreur 7 — BR-S-02 : l'identifiant TVA du vendeur dès qu'une ligne est au taux normal
Ce que la règle exige. Une facture qui contient une ligne au taux normal (catégorie « S ») doit contenir l'identifiant TVA du vendeur (BT-31), son identifiant d'enregistrement fiscal (BT-32) et/ou l'identifiant TVA de son représentant fiscal (BT-63) (règle BR-S-02).
Le symptôme. Le numéro de TVA intracommunautaire figurait dans le pied de page du PDF, mais pas dans le champ structuré du XML. Pour la plateforme, il n'existait pas.
La correction. Renseigner l'identifiant fiscal du vendeur (SpecifiedTaxRegistration/ID avec schemeID="VA"). En franchise en base de TVA, ne codez pas vos lignes en catégorie « S » à 0 % : utilisez la catégorie d'exonération avec sa raison, sinon BR-S-02 réclamera un numéro de TVA que vous n'avez pas.
Erreur 8 — BR-FR-05 (×3) : les mentions françaises codées PMD, PMT et AAB
C'est l'erreur la plus « française » et la moins documentée. L'article L441-9 du Code de commerce impose sur chaque facture entre professionnels trois mentions : le taux des pénalités de retard, le montant de l'indemnité forfaitaire pour frais de recouvrement, et les conditions d'escompte ou leur absence. L'indemnité est fixée à 40 € par l'article D441-5 ; le taux des pénalités ne peut être inférieur à trois fois le taux d'intérêt légal (article L441-10).
Ce que la règle exige. Dans la facture électronique, ces mentions ne sont pas du texte libre : elles doivent figurer dans les notes de la facture (BG-1) avec un code sujet précis. Le schematron FNFE-MPE l'exprime en trois assertions BR-FR-05 : « La mention relative aux frais de recouvrement (code PMT) est absente », « La mention relative aux pénalités de retard (code PMD) est absente », « La mention relative à l'escompte ou à son absence (code AAB) est absente. Elle est obligatoire dans les notes (BG-1) » (règle BR-FR-05). Chaque code ne doit apparaître qu'une seule fois (BR-FR-06, même fichier).
Le symptôme. Nos trois mentions étaient imprimées en bas du PDF et regroupées dans une seule note XML sans code sujet. Résultat : trois anomalies BR-FR-05 d'un coup.
La correction. Trois notes distinctes, chacune avec son code sujet : PMD pour les pénalités de retard (par exemple « Pénalités de retard : trois fois le taux d'intérêt légal »), PMT pour l'indemnité forfaitaire (« Indemnité forfaitaire pour frais de recouvrement : 40 € »), AAB pour l'escompte (« Pas d'escompte pour paiement anticipé »). Le contenu doit être non vide : un code seul ne suffit pas.
!Factur-X rejetée : les 9 erreurs trouvées en déposant de vraies factures sur une plateforme agréée — illustration Photo : Atlantic Ambience — Pexels
Erreur 9 — BR-FR-08 : le cadre de facturation (BT-23)
Ce que la règle exige. Le champ BT-23, « type de processus métier », doit contenir un code de cadre de facturation autorisé. Le message est explicite : « La valeur du mode de facturation (ram:ID) est absente ou n'est pas autorisée » (règle BR-FR-08). La liste acceptée, dans le même fichier : B1, S1, M1, B2, S2, M2, S3, B4, S4, M4, S5, S6, B7, S7, B8, S8, M8, B9, S9, M9.
Le symptôme. Notre BT-23 était vide. Nous n'avions trouvé cette liste dans aucune documentation publique consultée avant le test : c'est le message d'erreur de la plateforme qui nous l'a donnée. Elle figure dans la norme AFNOR XP Z12-012, téléchargeable gratuitement sur la boutique AFNOR, et dans le schematron FNFE-MPE.
La correction. Renseigner B1 pour le cas de base d'une vente de biens, et adapter le code à la nature réelle de l'opération. Ce cadre fait écho à la nouvelle mention obligatoire « nature de l'opération » (biens, services, ou les deux) ajoutée par le décret n° 2022-1299 : une facture de services codée en cas « biens » est incohérente, même si elle passe.
Récapitulatif des 9 erreurs
| # | Règle | Ce qu'elle exige | Notre erreur | Correction |
|---|---|---|---|---|
| 1 | BR-FR-13 | Adresse électronique du vendeur (BT-34) | Absente | URIID schéma 0225 = SIREN |
| 2 | BR-FR-12 / BR-FR-21 | Adresse électronique de l'acheteur (BT-49), schéma 0225 | Absente | URIID schéma 0225 = SIREN client |
| 3 | BR-22 | Quantité sur chaque ligne (BT-129) | Vide sur les forfaits | Quantité = 1 |
| 4 | BR-23 | Unité de mesure (BT-130) | Vide | C62 ou HUR |
| 5 | BR-26 | Prix unitaire net (BT-146) | Non renseigné | Prix = montant de la ligne |
| 6 | BR-27 | Prix unitaire ≥ 0 | Remise en prix négatif | Bloc réductions dédié |
| 7 | BR-S-02 | Identifiant TVA du vendeur si taux normal | Seulement dans le PDF | SpecifiedTaxRegistration schéma VA |
| 8 | BR-FR-05 ×3 | Notes PMD, PMT, AAB | Une note sans code | Trois notes codées, non vides |
| 9 | BR-FR-08 | Cadre de facturation (BT-23) | Vide | B1 (ou le code adapté) |
Comment tester avant le 1er septembre 2027
Le calendrier ne bouge pas : depuis le 1er septembre 2026, toute entreprise assujettie à la TVA établie en France doit pouvoir recevoir des factures électroniques, et l'obligation d'émettre s'étend aux PME, TPE et micro-entreprises le 1er septembre 2027 (service-public.gouv.fr). Le détail par situation est dans notre guide des obligations 2026-2027.
Notre méthode, telle que nous l'avons appliquée à nous-mêmes :
- Testez une vraie facture, pas un échantillon : une prestation au forfait, une remise, deux taux de TVA. Ce sont ces cas qui cassent.
- Passez le fichier au vérificateur de facture, gratuit et sans compte. Il contrôle la structure, les mentions obligatoires et les totaux ; il ne remplace pas la plateforme, mais il évite les erreurs les plus courantes avant le dépôt.
- Déposez sur le bac à sable de votre plateforme agréée, choisie dans la liste officielle. Si vous passez par un logiciel, demandez à l'éditeur la preuve d'un dépôt accepté : selon la FAQ de la DGFiP, un logiciel n'est une « solution compatible » que s'il est connecté à au moins une plateforme agréée (question 2.3).
- Corrigez le générateur, pas la facture. Une erreur BR-FR-05 corrigée à la main réapparaîtra sur la facture suivante.
- Conservez les traces. Le guide pratique de la DGFiP cite « les tests réalisés ou programmés » parmi les éléments qui prouvent une trajectoire sérieuse de mise en conformité (question 27).
Pour le format lui-même, lisez notre guide Factur-X ; pour le rôle des plateformes, le guide des plateformes agréées. Pour produire un fichier de test, le générateur Factur-X est gratuit et sans compte.
Où en est OdocPilot : le logiciel prépare vos factures au format Factur-X ; le raccordement à une plateforme agréée a été testé de bout en bout en bac à sable le 18 septembre 2026, avec les neuf corrections décrites ici, et son ouverture aux clients est en cours.
FAQ
Pourquoi ma Factur-X est-elle rejetée alors que mon outil la dit valide ?
Parce que « valide » n'a pas le même sens partout. La plupart des outils vérifient le schéma XSD, parfois quelques totaux. La plateforme applique en plus les règles EN 16931 et les règles françaises BR-FR (schematron FNFE-MPE). Nos neuf anomalies passaient le XSD sans un avertissement.
Que signifie l'erreur BR-FR-05 ?
Il manque une des trois mentions légales françaises codées dans les notes de la facture : PMD (pénalités de retard), PMT (indemnité forfaitaire de recouvrement de 40 €) ou AAB (escompte ou absence d'escompte). Ces mentions sont imposées par l'article L441-9 du Code de commerce. Il faut trois notes distinctes, chacune avec son code et un texte non vide.
Qu'est-ce que le schéma 0225 dans BT-49 ?
C'est l'identifiant « FRCTC ELECTRONIC ADDRESS » de la liste ISO 6523, qui désigne l'adresse électronique de routage française (liste ICD Peppol). Concrètement, BT-49 = SIREN du client avec schemeID="0225". Sans lui, la plateforme ne peut pas trouver la plateforme de réception de votre client dans l'annuaire.
Un rejet de la plateforme est-il une sanction ?
Non. Le rejet est un incident technique à corriger, distinct du refus par l'acheteur (guide pratique DGFiP, questions 11 et 12). Les amendes de l'article 1737 du CGI visent le défaut d'émission électronique (50 € par facture, plafonnés à 15 000 € par an), pas une facture rejetée puis redéposée.
Un PDF envoyé par e-mail est-il une facture électronique ?
Non. La FAQ de la DGFiP le rappelle : un PDF simple envoyé par voie électronique n'est pas une facture électronique au sens du dispositif (FAQ DGFiP, question 3.1). Il faut un des formats du socle (Factur-X, UBL ou CII) transmis par une plateforme agréée.
Testez votre propre fichier avec le vérificateur de facture gratuit avant de le déposer sur votre plateforme.
Mis à jour le 25 septembre 2026.
— La rédaction OdocPilot