Sommaire
D’où viennent ces rejets
En septembre 2026, nous avons soumis des factures générées depuis WooCommerce au validateur public de SUPER PDP, une Plateforme Agréée immatriculée. Ce validateur enchaîne trois contrôles, dans cet ordre :
- Le schéma XSD du CII (structure XML).
- Le schematron EN 16931 de la norme européenne (cohérence des montants, présence des champs obligatoires).
- Le schematron français « BR-FR Flux 2 » de la DGFiP (mentions et codes propres à la réforme).
Une facture qui échoue à l’un des trois est refusée. Les règles françaises sont signalées comme « warning » dans le rapport, mais la plateforme considère le fichier invalide dès qu’une seule est violée. C’est la source de la plupart des surprises : le fichier passait les validateurs habituels de Factur-X et échoue à l’étape 3.
Notre précédent article sur les erreurs Factur-X courantes traitait des défauts du PDF et du XML. Celui-ci se concentre sur les règles de transmission.
1. « Aucun validateur trouvé pour ce format de fichier » : le profil Basic
Le message le plus déroutant. Il signifie que le fichier déclare un profil Factur-X que la réforme n’accepte pas. La France n’admet que deux profils Factur-X : EN 16931 (parfois appelé Comfort) et Extended. Les profils Minimum, Basic WL et Basic sont hors périmètre.
Comment vérifier : le XML contient l’identifiant de profil dans la balise GuidelineSpecifiedDocumentContextParameter. Il doit valoir urn:cen.eu:en16931:2017. S’il se termine par :basic, le fichier sera refusé partout.
Correction : générer au profil EN 16931. Dans GoFactoX, c’est le format par défaut depuis la version 1.5.0 ; les versions précédentes produisaient du Basic par défaut, ce qui explique pourquoi certains marchands ont vu leurs fichiers refusés à la première tentative de dépôt.
2. Le SIRET au mauvais schéma d’identifiant
Les identifiants d’entreprise sont qualifiés par un code de la liste ISO 6523. Deux codes se ressemblent et sont souvent confondus :
| Code | Signifie | Longueur attendue |
|---|---|---|
| 0002 | SIREN (répertoire SIRENE) | 9 chiffres |
| 0009 | SIRET | 14 chiffres |
Écrire un SIRET de 14 chiffres avec le schéma 0002 est une erreur fréquente des générateurs. Le fichier passe le schéma XSD, mais l’annuaire ne reconnaît pas l’entreprise et les contrôles de cohérence échouent.
Correction : SIRET avec 0009 dans l’identifiant global (BT-29 pour le vendeur, BT-46 pour l’acheteur), SIREN avec 0002 dans l’identifiant légal (BT-30 et BT-47).
3. SIREN du vendeur ou du client absent
La réforme rend le SIREN du client obligatoire sur toute facture B2B domestique. Dans le XML, il se place dans l’identifiant d’enregistrement légal de l’acheteur (BT-47, balise SpecifiedLegalOrganization), pas dans le champ d’identifiant libre. Le SIREN du vendeur (BT-30) est également attendu sur chaque facture, indépendamment de la présence d’un numéro RCS.
Symptôme typique : le plugin collecte le SIREN au checkout et l’imprime sur le PDF, mais ne l’écrit pas dans le XML. La facture est lisible, incomplète pour la plateforme, et surtout impossible à router : c’est le SIREN qui sert de clé dans l’annuaire.
Correction : vérifier la présence de <ram:SpecifiedLegalOrganization><ram:ID schemeID="0002"> chez le vendeur et chez l’acheteur.
4. « receiver address does not exist in peppol directory » : les adresses électroniques
Les champs BT-34 (adresse électronique du vendeur) et BT-49 (adresse électronique de l’acheteur) servent à router la facture. Beaucoup de générateurs y mettent une adresse e-mail, avec le schéma EM. C’est valide au sens de la norme européenne, mais pour une facture B2B française la plateforme cherche une adresse au schéma 0225, dont la valeur est le SIREN (ou un SIREN suffixé si l’entreprise a créé plusieurs adresses).
Le comportement d’une PA face à une adresse e-mail est révélateur : SUPER PDP considère qu’une facture dont l’acheteur est adressé par e-mail est une facture B2C, la classe en e-reporting et ne l’achemine à personne. Votre client professionnel ne la recevra jamais, sans message d’erreur.
Correction : pour un client professionnel français, BT-49 = 0225 + SIREN. Pour un particulier, l’e-mail (EM) est correct, complété par une note codée BAR avec la valeur B2C. Pour le vendeur, BT-34 = 0225 + votre SIREN.
5. « BR-FR-08/BT-23 : la valeur du mode de facturation est absente ou n’est pas autorisée »
Le cadre de facturation (BT-23) est obligatoire. Les codes autorisés pour le B2B sont composés d’une lettre et d’un chiffre : B pour les biens, S pour les services, M pour mixte ; 1 pour une facture standard, 2 pour une facture déjà payée, puis d’autres cas (autofacturation, acompte…). Les valeurs acceptées sont B1, S1, M1, B2, S2, M2, S3, B4, S4, M4, S5, S6, B7, S7, B8, S8, M8, B9, S9, M9.
Le piège : les codes A1, A2, A9 et A12 sont ceux de Chorus Pro, valables uniquement pour une facture adressée à une administration publique. Un plugin qui met A1 par défaut, comme le faisaient plusieurs outils orientés B2G, produit des factures B2B refusées.
Correction : dériver le code de la catégorie de l’opération. Une boutique qui vend des biens émet en B1 ; si la commande est déjà payée à l’émission, B2 est possible, à condition de renseigner le montant déjà payé (BT-113) et un montant restant dû de zéro.
6. « BR-FR-05/BT-22 : la mention relative aux pénalités de retard est absente »
Trois mentions légales françaises doivent figurer sous forme de notes codées dans le XML, avec le code sujet indiqué :
| Code sujet | Mention |
|---|---|
| PMD | Pénalités de retard (taux ou référence au taux BCE majoré de 10 points) |
| PMT | Indemnité forfaitaire pour frais de recouvrement de 40 € |
| AAB | Conditions d’escompte, ou mention de l’absence d’escompte |
Les imprimer sur le PDF ne suffit pas : la plateforme lit le XML. Chaque mention manquante produit une ligne de rejet distincte (« code PMT absent », « code PMD absent », « code AAB absent »).
Correction : trois balises IncludedNote avec SubjectCode PMD, PMT et AAB, portant le texte des mentions. Le détail des formulations est dans notre checklist des mentions légales.
7. « BR-E-10 : une ventilation de TVA exonérée doit avoir un motif d’exonération »
Dès qu’une facture ne porte pas de TVA, la ventilation de TVA en catégorie E doit indiquer un motif, en texte ou en code. Deux cas fréquents en e-commerce :
- Le vendeur en franchise en base (article 293 B du CGI). Motif : la mention de l’article 293 B, avec le code VATEX-FR-FRANCHISE.
- Un avoir « geste commercial » sans TVA, ou une ligne à taux zéro.
Ce rejet s’accompagne souvent de BR-E-08 (montant de base de la ventilation exonérée différent de la somme des lignes exonérées) quand les lignes et la ventilation ne sont pas alignées.
Correction : un motif d’exonération sur chaque ventilation de catégorie E, et une base égale à la somme des lignes concernées.
8. « BR-16 : une facture doit avoir au moins une ligne » : les avoirs sans ligne
Un remboursement partiel d’un montant libre dans WooCommerce (par exemple un geste commercial de 10 €) ne porte aucune ligne de produit. Un générateur naïf produit un avoir Factur-X avec un total et zéro ligne, ce qui viole BR-16 et déclenche en cascade BR-CO-10 (somme des lignes différente du total) et l’erreur de schéma « IncludedSupplyChainTradeLineItem must occur at least 1 times ».
Correction : créer une ligne unique portant le montant remboursé et le motif, avec la TVA enregistrée sur le remboursement. C’est ce que fait GoFactoX depuis la version 1.5.0 pour les remboursements sans ligne (les avoirs sont dans l’offre Pro). Le sujet est détaillé dans Avoirs Factur-X et remboursements WooCommerce.
9. Les rejets côté compte, pas côté fichier
Trois messages ne viennent pas du fichier mais du compte PA :
- « L’entreprise liée à cette session ne correspond pas au vendeur de la facture. » Le SIREN du vendeur dans le XML n’est pas celui de l’entreprise vérifiée sur la plateforme. Vérifiez le SIRET dans les réglages du plugin.
- « Le régime de TVA est invalide. » Le régime de TVA n’a pas été renseigné dans les paramètres de l’entreprise chez la PA. Indispensable pour l’e-reporting, donc pour toute facture B2C.
- « La facture est déjà existante. » Le même numéro de facture a déjà été déposé. Une facture transmise ne se corrige pas par un nouveau dépôt : il faut un avoir puis une nouvelle facture.
Comment tester avant de déposer en production
Deux outils gratuits, sans compte :
- Le validateur public de SUPER PDP, qui applique exactement les trois niveaux de contrôle décrits plus haut et renvoie les messages ci-dessus. Dans GoFactoX, le bouton « Valider le dernier document » l’appelle directement depuis les réglages de l’offre Pro, une fois le connecteur SUPER PDP choisi.
- Le validateur du FNFE-MPE, utile pour le PDF/A-3 et la structure Factur-X, mais qui n’applique pas les règles françaises de transmission.
Puis un bac à sable de PA, gratuit chez SUPER PDP, pour tester le dépôt réel et le suivi des statuts, comme décrit dans notre tutoriel de transmission.
Questions fréquentes
Une facture rejetée par la PA a-t-elle une valeur légale ?
Le rejet technique ne rend pas la créance nulle, mais la facture n’a pas été « émise » au sens de la réforme tant qu’elle n’a pas été transmise. Pendant la phase de tolérance de 2026, vous pouvez la corriger et la redéposer ; en régime de croisière, un rejet répété expose aux amendes prévues par l’article 1737 du CGI.
Mon prestataire dit que mes factures sont « valides Factur-X ». Pourquoi sont-elles refusées ?
Parce que « valide Factur-X » désigne la conformité au format franco-allemand, pas aux règles de la réforme française. Les règles BR-FR (cadre de facturation, mentions codées, SIREN client, adresses 0225) s’ajoutent au format. Demandez un rapport de validation qui inclut le schematron « Flux 2 ».
Les factures à des particuliers sont-elles soumises aux mêmes règles ?
Presque. Le SIREN client et l’adresse 0225 ne s’appliquent pas à un particulier ; l’adresse e-mail et la note B2C prennent le relais. Le profil EN 16931, le cadre de facturation, les mentions codées et le motif d’exonération restent exigés.
Comment savoir quel profil Factur-X mon plugin produit ?
Extrayez le fichier XML du PDF (il est joint sous le nom factur-x.xml) et cherchez la balise GuidelineSpecifiedDocumentContextParameter. Ou passez le PDF dans le validateur public : le rapport indique le « conformance level » détecté.
Sources
- AFNOR, norme XP Z12-012 (règles de gestion françaises de la facture électronique)
- DGFiP, spécifications externes de la facturation électronique, schematron BR-FR Flux 2
- FNFE-MPE, spécification Factur-X 1.0.7 et validateur
- SUPER PDP, validateur public et documentation : superpdp.tech