Ouvrez une facture hybride dans n’importe quel lecteur PDF et vous verrez un document tout à fait ordinaire : en-tête, lignes de prestation, total. Cette vue ne dit rien de la validité du fichier. Ce qui compte pour le logiciel comptable du destinataire, c’est le XML enfoui à l’intérieur — et la manière dont il est rattaché au PDF.
C’est la surprise la plus fréquente pour qui découvre le format. Un PDF imprimé puis auquel on a « joint » un fichier XML dans un éditeur ressemble à l’écran, trait pour trait, à une véritable facture Factur-X — et échoue immédiatement à la validation. C’est précisément cette différence que la validation détecte : entre « a l’air correct » et « est correct ».
Couche 1 — le fichier est-il vraiment un PDF/A-3 ?
Une facture hybride n’est pas un simple PDF avec une pièce jointe. Ce doit être un fichier PDF/A-3 valide — la variante archivistique du PDF, conçue pour rester lisible pendant des décennies — et le XML de la facture doit y être incorporé d’une manière bien précise.
À cette couche, un validateur contrôle notamment :
- La conformité PDF/A-3 — les exigences structurelles du format d’archivage lui-même.
- Les polices incorporées. PDF/A interdit de compter sur les polices installées sur la machine du lecteur : tout ce qui est nécessaire à l’affichage doit se trouver dans le fichier.
- Les profils colorimétriques, déclarés explicitement plutôt que supposés.
- Les métadonnées XMP — un bloc lisible par machine qui décrit le fichier, y compris la norme et le profil auxquels il prétend se conformer.
- La relation de la pièce jointe. Le XML incorporé doit porter la bonne relation (
AFRelationship) et le nom de fichier attendu, afin que les logiciels le reconnaissent comme des données de facture et non comme une pièce jointe quelconque.
Les outils de ce domaine s’appuient généralement sur veraPDF, le validateur PDF/A open source, pour cette couche. Un fichier qui échoue ici n’est pas une facture électronique valide, quelle que soit la qualité de son XML.
Couche 2 — le XML est-il bien formé et conforme au schéma ?
Les données incorporées utilisent la syntaxe Cross Industry Invoice (CII) de l’UN/CEFACT — le modèle de données décrit dans notre article sur la structure XML.
Cette couche analyse ce XML et le confronte à son schéma (XSD) : chaque élément là où le schéma l’attend, types de données corrects, éléments obligatoires présents, valeurs au bon format. Une date écrite 31/12/2026 là où le schéma attend 20261231 échoue ici.
La validation de schéma est stricte sur la forme et totalement aveugle au sens. Une facture peut être parfaitement conforme au schéma et afficher malgré tout un total de TVA qui ne correspond pas à ses propres lignes. C’est à cela que sert la troisième couche.
Couche 3 — les règles de gestion
La couche la plus stricte et la plus intéressante contrôle les règles de gestion Schematron : plusieurs centaines d’assertions sémantiques définies aux côtés de la EN 16931, qui vérifient si le contenu de la facture est cohérent et complet.
Ce sont les règles qui attrapent les problèmes qui font réellement rejeter une facture :
- une ventilation de TVA qui ne conduit pas au total déclaré ;
- une catégorie de TVA qui exige un motif d’exonération là où aucun n’a été donné ;
- une référence acheteur manquante sur une facture destinée à une entité publique ;
- une devise indiquée à un endroit et sous-entendue différemment à un autre.
Les règles sont regroupées par familles, et le préfixe indique d’où vient une règle :
| Préfixe | Origine | Ce qui est vérifié |
|---|---|---|
BR-* | EN 16931, noyau | présence et cardinalité des informations requises |
BR-CO-* | EN 16931, noyau | cohérence et arithmétique entre champs liés |
BR-CL-* | EN 16931, listes de codes | une valeur doit provenir d’une liste de codes autorisée |
BR-S-*, BR-Z-*, BR-E-*, BR-AE-*, BR-G-*, BR-O-*, BR-IC-* | EN 16931 | règles par catégorie de TVA — taux normal, taux zéro, exonéré, autoliquidation, exportation, hors champ, intracommunautaire |
BR-DE-* | XRechnung (CIUS allemande) | exigences allemandes supplémentaires |
PEPPOL-EN16931-R* | Peppol BIS Billing | règles supplémentaires pour l’envoi via le réseau Peppol |
Le détail de ce que les familles du noyau garantissent figure dans les règles de gestion EN 16931.
Toutes les règles ne s’appliquent pas à tous les fichiers
C’est là que les rapports de validation sont le plus souvent mal lus. Le jeu de règles applicable dépend de ce que le fichier prétend être.
Un fichier Factur-X au profil EN 16931 est mesuré à l’aune des règles du noyau EN 16931. La famille BR-DE-* appartient à XRechnung, l’adaptation nationale allemande (CIUS) de la norme — ces règles s’appliquent lorsque le document est une XRechnung, pas à toute facture. Une facture parfaitement valide peut donc afficher des remarques BR-DE-* qui ne la concernent tout simplement pas, et les traiter comme des erreurs conduit à « réparer » des fichiers qui n’ont jamais été cassés.
Il en va de même pour les profils : un fichier MINIMUM ou BASIC WL porte délibérément moins d’informations que la EN 16931 n’en exige, et n’est donc pas mesuré au jeu de règles complet. Ce que contient chaque profil est traité dans les profils Factur-X et ZUGFeRD.
Lire un message de validation
Un message comporte normalement trois éléments utiles :
- Le code de règle — par exemple
BR-CO-15. C’est le moyen le plus rapide de savoir ce qui a réellement été vérifié, et c’est ce qu’il faut chercher quand on bloque. - La sévérité — une erreur bloquante qui rend le document invalide, ou un avertissement qui signale quelque chose de discutable mais admis.
- Un emplacement, le plus souvent un XPath dans le XML, qui pointe l’élément en cause.
L’emplacement dit où, le code dit pourquoi. Corrigez la cause dans le système qui a produit la facture plutôt que de modifier le XML à la main : une facture dont le XML a été retouché ne correspond plus à la page PDF qui l’accompagne, et cette contradiction est pire que l’erreur d’origine.
Ce que la validation ne dit pas
La validation est un contrôle de conformité, pas un audit, et il vaut la peine d’être précis sur ses limites :
- Elle ne confirme pas l’exactitude. Un fichier peut passer toutes les règles et afficher malgré tout le mauvais prix, le mauvais client ou la mauvaise date. Ce qui est vérifié, c’est la cohérence interne, pas la véracité.
- Elle ne garantit pas l’acceptation. Un destinataire peut imposer ses propres exigences — un numéro de commande, une référence particulière, un profil déterminé.
- Elle ne remplace pas un conseil fiscal. Savoir si une facture satisfait au droit fiscal d’un pays est une question distincte de sa conformité à la EN 16931.
Trois numéros de version, et ce ne sont pas les mêmes
Trois versions différentes se rencontrent au sein d’un même contrôle, et les confondre coûte beaucoup de discussions inutiles :
- La version du format. La version en vigueur est Factur-X 1.09.2 / ZUGFeRD 2.5.2, publiée le 4 août 2026 et applicable à partir du 1er septembre 2026. Il s’agit d’un corrigendum à la version 2.5 de juin 2026 : cohérence, arrondis, ventilation de TVA et règles de validation ont été corrigés — principalement dans le profil EXTENDED — et les artefacts XSD et Schematron ont été rafraîchis. La version 3.0 n’existe pas ; voir les versions du format.
- La version du validateur. Mustang, le validateur open source sur lequel s’appuie l’essentiel de ce secteur, est développé dans sa propre lignée 2.x — actuellement 2.26.0, parue le 25 août 2026. Son numéro n’a rien à voir avec la version du format. Voir le projet Mustang.
- La version du jeu de règles. Les artefacts Schematron sont encore versionnés séparément — EN 16931 Schematron v1.3.16 est le jeu correspondant à la version corrigée 2.5.2.
Une précision s’impose : la norme sémantique elle-même a été révisée. Le CEN a approuvé EN 16931-1:2026 en février 2026 et l’a publiée en mai 2026, retirant l’édition de 2017. Dans la pratique, les outils n’ont pas encore suivi — Factur-X 1.09.2 et les jeux Schematron actuels reposent toujours sur la sémantique de 2017, et la prise en charge de la nouvelle révision est attendue avec la version prévue à l’automne 2026. Quiconque affirme aujourd’hui valider contre la révision 2026 mérite qu’on lui demande ce qu’il entend exactement par là.
Ce qui se passe après le clic sur « Vérifier »
Un contrôle n’est pas un coup d’œil dans un tableau, mais un passage par les couches décrites plus haut — d’où des secondes plutôt que des millisecondes. Concrètement :
- Deux étapes l’une après l’autre. D’abord le conteneur (est-ce bien un PDF/A-3 avec pièce jointe ?), puis le XML face au schéma et aux règles de gestion. Le verdict vient des deux : un PDF/A valide avec un XML fautif n’est pas une facture électronique valide.
- Une progression honnête plutôt qu’un cercle qui tourne. L’affichage dit quelle étape s’exécute — sur un gros fichier, c’est la différence entre « ça travaille » et « c’est figé ».
- Les contrôles passent par une file d’attente. Un fichier exigeant ne bloque donc pas le reste du compte, et plusieurs contrôles à la suite ne se gênent pas.
- Le résultat reste, le fichier non. Le rapport se retrouve sous « Documents » ; le fichier déposé est supprimé du serveur peu après — voir la conservation : l’archive, c’est vous qui la tenez.
Vérifier une facture reçue
La facturation électronique est obligatoire en France, et recevoir un fichier est la partie facile — savoir si ce qui est arrivé est sain est la partie utile.
Quatre points méritent un contrôle sur une facture entrante :
- Le XML correspond-il à la page ? Dans un fichier hybride, ce qui est comptabilisé, ce sont les données incorporées, et elles peuvent différer de ce qu’affiche le PDF. En cas de divergence, il faut trancher avant que le document n’entre en comptabilité.
- Passe-t-elle la validation ? Les trois couches, conteneur compris.
- Les mentions fiscales sont-elles plausibles ? Numéro de TVA, catégorie et taux — ou un motif indiqué là où aucune TVA n’est facturée.
- Est-ce un doublon ? Les données structurées rendent les doublons bien plus faciles à repérer que le papier scanné ne l’a jamais permis.
Vérifier avant d’envoyer
Le moment le moins coûteux pour trouver un problème, c’est avant le client. Une facture rejetée coûte un cycle de paiement ; un contrôle coûte quelques secondes. La marche à suivre pour vos propres documents est décrite dans comment vérifier une facture.