Comment vérifier une facture Factur-X ou ZUGFeRD

Vérifier une facture prend quelques secondes. Une facture rejetée coûte un cycle de paiement — le document revient, quelqu’un cherche ce qui n’allait pas, on corrige, on réémet, et le compteur repart de zéro. Ce déséquilibre est tout l’argument en faveur d’un contrôle de chaque fichier avant l’envoi, et de chaque facture reçue avant qu’elle n’entre en comptabilité.

Cette page décrit la marche à suivre : quel fichier déposer, comment un rapport est construit, comment on lit un vrai rapport ligne par ligne et que faire lorsqu’une anomalie est signalée. Ce qui se passe à l’intérieur de chaque contrôle est décrit dans Comment fonctionne la vérification.

Qu’avez-vous exactement entre les mains ?

Trois choses différentes s’appellent « facture électronique », et seules deux d’entre elles se vérifient.

• Un PDF hybride — un fichier Factur-X ou ZUGFeRD : une page PDF d’apparence tout à fait ordinaire, avec un XML de facture incorporé. Déposez le PDF ; le XML en est extrait automatiquement.
• Un fichier XML seul — une XRechnung ou un document CII/UBL sans PDF autour. Déposez-le tel quel. Il n’y a pas de conteneur à contrôler, le rapport commence donc à la couche du schéma.
• Un PDF ordinaire — une facture imprimée ou scannée, sans aucune donnée structurée. Il n’y a rien à vérifier : c’est l’image d’une facture. En faire une véritable facture électronique est un autre travail, décrit dans Convertir une facture PDF.

Si vous ne savez pas laquelle des trois vous tenez : déposez-la. Si le validateur ne trouve aucun XML incorporé, il le dit immédiatement — et cette réponse est utile aussi. Le geste le plus rapide sans outil consiste à regarder les pièces jointes : un lecteur qui affiche les fichiers joints listera, sur une facture hybride, un XML nommé factur-x.xml ou zugferd-invoice.xml. Si rien n’apparaît, il n’y a rien dedans.

Étape 1 — déposer le fichier

Rien à préparer. Ne décompressez rien, n’extrayez pas le XML à la main, ne renommez pas le fichier. Déposez le document exactement tel qu’il a été produit ou tel qu’il est arrivé — un fichier déballé puis remballé n’est plus celui que voit le destinataire, et les contrôles de conteneur portent précisément sur cet emballage.

Trois choses qui coûtent du temps quand on les ignore :

• Une archive ZIP n’est pas une facture. Ce qui se vérifie, c’est le fichier qu’elle contient, pas l’archive. Extrayez, puis déposez le document.
• Le fichier de la boîte aux lettres, pas celui de l’imprimante. Réenregistrer une facture reçue, l’« optimiser » ou la faire passer par un outil PDF revient à contrôler ensuite un autre document — avec un conteneur écrit en chemin par quelqu’un d’autre.
• La taille. Sur notre page publique la limite est de 5 Mo par fichier. Une facture nettement au-dessus contient presque toujours des scans ou des images en résolution d’impression — et cela mérite une question en soi.

Étape 2 — lire le rapport dans l’ordre

Les résultats reviennent en trois couches et se lisent de haut en bas, car un échec sur une couche antérieure rend les suivantes peu fiables. Si le conteneur PDF/A-3 est défectueux, il n’y a peut-être aucun XML exploitable à examiner, et la section des règles de gestion décrit alors un fichier que personne ne pourra lire de toute façon.

1. Conteneur — s’agit-il d’un fichier PDF/A-3 valide, avec le XML attaché comme la norme l’exige ? Sans objet lors du dépôt d’un XML seul.
2. Schéma — le XML est-il bien formé et chaque élément correspond-il à son XSD ? Cette couche est stricte sur la forme et totalement aveugle au sens. Elle signale une date au mauvais format, pas une date dans la mauvaise année.
3. Règles de gestion — les montants tombent-ils juste, la ventilation de TVA est-elle cohérente, le vendeur est-il identifiable ? C’est de là que viennent la plupart des rejets réels, et c’est là que la lecture attentive paie.

Anatomie d’un message

Chaque ligne d’un rapport de contrôle comporte quatre parties. Qui les distingue n’a besoin d’aucun second avis pour la plupart des constats.

L’emplacement est un XPath — un itinéraire dans l’arbre du XML. Vous n’avez pas besoin de savoir le lire. Reconnaître le dernier élément et rechercher le code de règle suffit : les familles de règles et les erreurs qui surviennent réellement sont réunies dans Règles de gestion de l’EN 16931, une section par code.

Erreur, avertissement, remarque — ce que vaut chaque rang

Le rang d’un message n’est pas affaire de goût : il figure dans la règle elle-même. Trois niveaux existent :

• Fatal. Le fichier n’est pas exploitable à cet endroit — conteneur cassé, XML illisible. Poursuivre le contrôle n’a plus de sens.
• Erreur. Une règle contraignante est violée. Le document est invalide, et un destinataire qui contrôle automatiquement le renverra.
• Remarque. Quelque chose est inhabituel mais permis. Très souvent, elle provient d’une déclinaison nationale qui n’a pas à s’appliquer à votre document.

L’inverse vaut aussi : un destinataire a le droit d’être plus strict que la norme. Certaines administrations et grandes entreprises rejettent des documents qui passent toutes les règles, parce qu’un numéro de commande manque ou qu’un autre profil était attendu. Ce n’est pas une erreur de contrôle, mais une exigence hors norme — et cela se demande plutôt que cela ne se devine.

Un vrai rapport, ligne par ligne

Le plus rapide pour apprendre à lire est un cas chiffré. La facture : trois lignes, deux taux de TVA, une remise au niveau du document.

Jusqu’ici tout est juste. L’erreur se niche dans la ventilation de TVA : le logiciel de facturation a bien déduit la remise du total HT, mais pas de la base imposable du taux à 20 %. Le fichier contient donc :

Le rapport ressemble alors à ceci :

• Conteneur : conforme. PDF/A-3 valide, XML attaché avec la relation attendue, métadonnées XMP présentes.
• Schéma : conforme. Chaque élément à sa place, chaque nombre au bon format.
• Règles de gestion : deux erreurs, une remarque.

Erreur 1 — BR-S-08 : pour chaque taux, la base imposable doit être égale à la somme des montants HT des lignes de ce taux, diminuée des remises qui s’y rattachent. 1 140,00 + 240,00 − 96,00 = 1 284,00 ; le fichier indique 1 380,00. Emplacement : la ligne à 20 % de la ventilation.

Erreur 2 — BR-CO-15 : le total TTC doit être le total HT augmenté du total de TVA. 1 400,00 + 282,38 = 1 682,38 ; le fichier indique 1 663,18. Emplacement : le total général dans l’en-tête du document.

Remarque — BR-DE-21 : l’identifiant de BT-24 n’est pas celui de XRechnung. C’est normal, il s’agit d’une facture ZUGFeRD.

Et voici pourquoi on lit un rapport au lieu de le traiter ligne à ligne : deux erreurs, une seule cause. La remise a été enregistrée sans catégorie de TVA. Qui prend le second constat isolément et saisit 1 682,38 à la main dans le total n’a pas rendu le fichier juste : il a déplacé la contradiction — la page visible affichera 1 663,18 et les données 1 682,38, et c’est la partie structurée qui fait foi.

La réparation tient en un clic dans le logiciel de facturation : attribuer à la remise la catégorie « taux normal 20 % ». Le programme recalcule alors 1 284,00 → 256,80 → 263,18 → 1 663,18, et la seconde erreur disparaît avec la première.

Les constats qui reviennent sans cesse

Les messages ci-dessous expliquent la majeure partie des rejets en pratique. Chaque ligne mène à la section détaillée du code.

Étape 3 — corriger la cause, pas le fichier

Chaque constat nomme un code de règle et pointe un endroit du XML. L’endroit dit où ; le code dit pourquoi. Corrigez ensuite les données sous-jacentes dans le système qui a produit la facture : le numéro de TVA absent du profil d’entreprise, le pas d’arrondi du logiciel, la ligne jamais saisie. Puis régénérez le document depuis ce système.

Modifier le XML directement est tentant et presque toujours faux, pour trois raisons :

• La page et les données divergent. Dans un fichier hybride, la page visible et les données incorporées doivent dire la même chose. Un XML retouché à la main ne correspond plus à la page d’à côté.
• L’erreur revient. La cause siège dans les données de base ou dans un paramètre. Réparer le fichier répare un cas isolé et émet la facture suivante avec le même défaut.
• Le fichier casse. Modifier le XML à l’intérieur d’un PDF hybride et le conteneur ne tient plus — la pièce jointe fait partie du fichier, ce n’est pas un document posé à côté.

Étape 4 — revérifier, puis envoyer

Repassez le fichier corrigé. Les corrections déplacent les problèmes plus souvent qu’on ne le croit : une ligne ajoutée change le total HT, celui-ci change la ventilation de TVA, laquelle peut déclencher une autre règle de calcul. Un fichier est terminé quand le rapport est propre sur les trois couches — pas quand la première erreur a disparu.

La fréquence dépend de l’ancienneté du passage au format :

• Chaque facture les premières semaines. Les erreurs du début siègent dans les données de base et se répètent jusqu’à ce que quelqu’un les voie.
• Ensuite, à chaque changement. Nouveau modèle, nouveau taux, nouveau délai de paiement, mise à jour du logiciel, nouveau client avec ses propres exigences — une vérification à chaque fois.
• Toujours pour les fichiers venus d’ailleurs. Ce que vous recevez, vous ne l’avez pas produit, et rien ne vous alerte avant que la comptabilité ne trébuche.

Liste de contrôle avant l’envoi

À parcourir une fois pour vos premiers documents, puis à nouveau dès que quelque chose change dans votre facturation. Un validateur répond à l’essentiel ; le reste demande un œil humain.

• Le fichier s’ouvre dans n’importe quel lecteur comme un PDF normal et la page est lisible.
• Le profil correspond à ce que le destinataire a demandé — certains en imposent un.
• Les montants HT des lignes donnent le total HT, et HT plus taxe donne le TTC.
• Les numéros de TVA du vendeur et de l’acheteur sont présents et portent un préfixe pays.
• La date de facture et la date d’échéance sont renseignées.
• Les unités de mesure sont des codes normalisés, pas du texte libre comme « pce » ou « heures ».
• Toute catégorie de TVA qui exige un motif — exonération, autoliquidation, exportation — en porte un.
• Les chiffres de la page visible coïncident avec ceux du XML.
• Le rapport ne montre aucun constat fatal sur aucune couche.
• Si un numéro de commande ou de référence a été demandé, il y figure. Les acheteurs publics allemands exigent un Leitweg-ID ; sans lui, la facture revient.

Vérifier les factures reçues

Les documents entrants posent des questions un peu différentes, car vous ne contrôlez pas ici votre propre travail.

• Le XML correspond-il à la page ? C’est le contrôle le plus souvent oublié et le constat le plus coûteux. Dans un fichier hybride, ce sont les données incorporées qui sont comptabilisées, et elles peuvent différer de ce qu’affiche le PDF. Là où les deux divergent, il faut trancher avec le fournisseur avant que le document n’entre en comptabilité — la partie structurée fait foi.
• Est-elle seulement valide ? Un fichier fournisseur qui échoue déjà au contrôle du conteneur ne s’intégrera proprement nulle part — et le dire au premier jour coûte moins cher qu’après la campagne de paiement.
• Les données de taxe sont-elles plausibles ? Numéro de TVA, catégorie et taux — ou un motif indiqué là où aucune taxe n’est calculée.
• Est-ce un doublon ? Les données structurées rendent les doubles saisies bien plus faciles à repérer que le papier scanné ne l’a jamais permis. Le couple numéro de facture + numéro de TVA du vendeur identifie un document de façon unique.
• Qu’archivez-vous ? Ce qui doit être conservé, c’est la partie structurée, inchangée. En Allemagne, huit ans au titre du § 14b UStG ; en France, les règles de conservation sont propres au pays. Détails dans Conservation et GoBD.

Ce qu’un rapport propre ne prouve pas

La vérification est une preuve de conformité, pas un audit, et être précis sur ses limites évite des discussions plus tard.

• Elle ne confirme pas l’exactitude. Un fichier peut passer toutes les règles et afficher le mauvais prix, le mauvais client ou la mauvaise date. Ce qui est contrôlé, c’est la cohérence interne, pas la vérité.
• Elle ne garantit pas l’acceptation. Un destinataire peut exiger, au-delà de la norme, ses propres numéros de commande, références ou profils.
• Elle ne remplace pas un conseil fiscal. Savoir si une facture satisfait au droit fiscal d’un pays est une autre question que la conformité à l’EN 16931.
• Elle ne dit rien du transport. Un fichier valide qui atterrit dans la mauvaise boîte, ou arrive par un canal que le destinataire ne lit pas, reste aussi impayé qu’un fichier invalide.

Questions fréquentes

Dois-je d’abord extraire le XML du PDF ?

Non. Déposez le PDF tel quel. L’extraction puis le réemballage modifient précisément la partie qu’évalue le contrôle du conteneur — vous vérifieriez un autre document que celui que reçoit votre destinataire.

Le rapport affiche des remarques mais aucune erreur. Puis-je envoyer ?

Oui. Une remarque signifie « inhabituel mais admis », et elle provient très souvent d’une déclinaison nationale qui n’a pas à s’appliquer à votre document. Lisez-la une fois, puis envoyez.

Pourquoi chacune de mes factures ZUGFeRD signale-t-elle BR-DE-21 ?

Parce que cette règle vérifie si l’identifiant de BT-24 est celui de XRechnung. Sur une facture ZUGFeRD, il ne l’est pas — et ne doit pas l’être. Le message n’est pas un défaut de votre fichier ; notre rapport le déduit déjà.

Puis-je vérifier une facture envoyée depuis longtemps ?

Oui, et cela vaut la peine dans deux cas : quand un destinataire réclame et que vous voulez savoir si le fichier est en cause, et par sondage après toute modification de modèles ou de données de base. Vérifier ne modifie pas une facture déjà partie.

Le rapport est propre et le destinataire refuse quand même. Que faire ?

L’exigence est alors hors norme. Les trois cas les plus fréquents : un numéro de commande ou de référence manquant, un profil précis attendu, ou un canal par lequel il faut déposer la facture. Demandez le motif de rejet au mot près — il nomme presque toujours le champ.

Comment vérifier une XRechnung seule ?

De la même façon : déposez le fichier XML. Il n’y a pas de conteneur, le rapport commence à la couche du schéma, et les règles allemandes BR-DE-* s’appliquent ici intégralement, Leitweg-ID compris pour les administrations.

Comment savoir contre quelle version le contrôle a tourné ?

Un rapport utilisable nomme son jeu de règles. Le nôtre contrôle contre les règles Schematron de l’EN 16931 et les règles de format de ZUGFeRD et Factur-X ; la base est Mustang 2.26.0 du 25 août 2026. La version de format en vigueur est ZUGFeRD 2.5.2 / Factur-X 1.09.2, applicable depuis le 1^er septembre 2026.

Ma facture est-elle conservée ?

Pas sur la page de vérification publique. Le fichier existe comme dépôt temporaire le temps du contrôle et il est supprimé à la fin de la requête. Qui souhaite garder un historique de ses vérifications le trouve dans le compte.

En résumé

• Déposer le fichier tel quel — ne pas le décompresser, ne pas le réenregistrer.
• Lire de haut en bas : conteneur, schéma, règles de gestion. Un échec en haut rend tout le reste incertain.
• Séparer erreurs et remarques avant de changer quoi que ce soit. BR-DE-21 figure sur toute facture ZUGFeRD.
• Plusieurs constats ont souvent une seule cause. Chercher la cause d’abord, calculer ensuite.
• Corriger dans le système source, jamais dans le XML — sinon page et données se contredisent, et ce sont les données qui font foi.
• Revérifier après chaque correction, et comparer page et XML sur les factures reçues.

Vérifier un fichier ici

Notre validateur parcourt les trois couches sur la base open source sur laquelle la profession s’est accordée — le projet Mustang — et signale chaque constat avec son code de règle, sa gravité et son emplacement. Il est gratuit et ne demande aucune inscription : vous déposez le fichier et vous obtenez le rapport. Les limites sont de 5 Mo par fichier et d’une douzaine de vérifications par heure et par expéditeur — assez pour le quotidien, assez serré pour que la page ne soit pas accaparée par des scripts. Les fichiers déposés ne sont pas conservés : le document existe comme dépôt temporaire le temps du contrôle et il est supprimé à la fin de la requête.