Facture Factur-X valide mais rejetée : les trois pièges que les validateurs classiques ne voient pas
Votre facture passe les validateurs officiels et se fait quand même rejeter ? Conteneur PDF, divergences PDF/XML, identifiants faux : les 3 angles morts expliqués.
C'est le paradoxe qui remonte du terrain depuis le printemps : des factures qui passent les validateurs officiels sans une seule erreur, et qui se font pourtant refuser en aval, par une plateforme, un client ou un système comptable. Ce n'est pas un bug, c'est un angle mort. Un validateur XML regarde le XML. Or une facture Factur-X est plus que son XML, et la conformité formelle est plus étroite que la conformité réelle. Trois pièges expliquent l'essentiel des rejets "inexplicables".
Rappel : les quatre couches d'une facture électronique conforme
La structure d'abord : le XML doit respecter le schéma XSD de sa syntaxe, UBL ou CII. Les règles métier ensuite : la norme EN 16931 impose environ deux cents contrôles, les fameux BR-05, BR-CO-16 et compagnie, vérifiés par des schematrons officiels. Les règles françaises en troisième : le Flux 2 ajoute ses exigences propres, mentions obligatoires et identifiants. Et pour un Factur-X, une quatrième couche que presque personne ne contrôle : le conteneur PDF lui-même.
La plupart des validateurs s'arrêtent à la deuxième ou à la troisième couche. Les rejets, eux, se nichent souvent dans la quatrième, ou carrément en dehors des couches.
Piège n° 1 : le conteneur PDF mal construit
Le XML est irréprochable, mais il est mal embarqué. Les cas classiques : la pièce jointe ne s'appelle pas factur-x.xml, la relation AFRelationship est absente ou incorrecte, les métadonnées XMP ne déclarent pas le PDF/A-3, ou annoncent un profil différent de celui que porte le XML. Une plateforme stricte refuse alors le fichier entier, et le validateur XML n'a rien vu venir puisque le XML, lui, est bon.
C'est le scénario le plus frustrant du moment, celui qui se résume en une phrase entendue partout : le XML est bon mais la plateforme refuse le PDF. Un validateur complet doit contrôler cette couche de façon déclarative, nom de la pièce jointe, AFRelationship, métadonnées XMP, cohérence entre le niveau déclaré et le profil détecté, en plus des trois autres. Pour les dossiers litigieux, un audit PDF/A complet, type veraPDF, reste l'étape d'après; dans la grande majorité des cas, le contrôle déclaratif suffit à localiser le problème.
Piège n° 2 : le PDF et le XML racontent deux histoires
Un Factur-X est un document à deux lecteurs. L'humain lit le PDF, le système lit le XML, et rien ne garantit techniquement qu'ils disent la même chose. Un acompte déduit sur le visuel mais absent des données, un total arrondi différemment, une date d'échéance corrigée d'un seul côté : la facture est valide au sens des schematrons et fausse au sens du client, qui paiera le mauvais montant ou ouvrira un litige.
La spécification exige la cohérence entre les deux représentations, mais aucun contrôle de forme ne peut arbitrer seul un désaccord de fond. Le bon réflexe est en amont : générer le PDF et le XML depuis la même source de données, jamais en deux étapes séparées, puis vérifier par sondage que les totaux affichés correspondent aux champs structurés. Une divergence détectée chez vous coûte une correction; détectée chez le client, elle coûte un délai de paiement.
Piège n° 3 : des identifiants corrects en syntaxe, faux en réalité
Un SIRET à quatorze chiffres passe tous les contrôles de format. S'il est erroné, radié, ou s'il ne correspond pas à l'inscription de votre client dans l'annuaire central, la facture partira au mauvais endroit ou ne partira pas du tout. Les rejets d'annuaire sont la cause la plus bête et l'une des plus fréquentes de blocage : la donnée est plausible, elle est simplement fausse. Aucun schematron ne sait qu'un établissement a fermé le mois dernier.
Avant tout envoi récurrent, vérifiez que le SIRET du destinataire est actif et que sa présence à l'annuaire correspond bien à l'entité que vous facturez. Notre article sur le contrôle SIREN et SIRET détaille la méthode.
Comment verrouiller avant l'envoi
L'ordre de bataille raisonnable tient en trois gestes. Validez la forme sur les quatre couches en une passe : passez le fichier dans un validateur qui contrôle la structure, la norme EN 16931, les règles françaises et le conteneur PDF, avec des erreurs explicites. Contrôlez ensuite les identifiants contre la réalité : SIRET actif, client présent à l'annuaire. Enfin, pour vos gabarits de facturation, vérifiez une bonne fois que le PDF et le XML sortent de la même source de données. Ces trois gestes couvrent l'immense majorité des "pourquoi ma facture est rejetée alors qu'elle est valide".
Questions fréquentes
Mon fichier passe le validateur officiel, pourquoi est-il quand même rejeté ?
Cherchez dans l'ordre : le conteneur PDF (nom de pièce jointe, XMP, AFRelationship), une divergence entre le visuel et les données, puis les identifiants et l'annuaire. Les trois échappent à un contrôle purement XML.
Le validateur contrôle-t-il la conformité PDF/A-3 complète ?
Il contrôle les déclarations du conteneur : PDF/A-3 annoncé dans les métadonnées, pièce jointe, relation, cohérence de profil. Un audit PDF/A octet par octet est un niveau supplémentaire, utile pour les cas litigieux.
Qui est responsable si le PDF et le XML divergent ?
L'émetteur. Le circuit traite les données structurées tandis que votre client lit le visuel : toute divergence finit en litige de règlement, et c'est votre facture qui attend.
À quelle fréquence tester ses fichiers ?
À chaque changement de gabarit, d'outil ou de version de logiciel, puis par sondage sur les flux récurrents. Un test prend quelques secondes, un rejet prend des semaines.
Contrôler chaque facture à la main ne tient pas à l'échelle
Qelvyn conçoit les outils internes que les cabinets comptables et les entreprises utilisent pour valider automatiquement leurs factures Factur-X avant émission ou réception. Si votre contrôle de conformité a dépassé ce qu'un tableur peut gérer, décrivez-nous votre situation et nous vous dirons franchement si un système est rentable.