Connaissances · Facture électronique
Valider une facture électronique et bien lire le rapport de validation
Lorsqu’une facture électronique émise par votre logiciel est rejetée, votre équipe doit déterminer, à l’aide du rapport de validation, quel champ a déclenché le message et qui peut le corriger.
Nous montrons comment lire un rapport de validation et à quels endroits la validation a sa place dans votre logiciel.
Ce qui est contrôlé lors de la validation d'une facture électronique
Un validateur contrôle une facture électronique successivement par rapport à trois référentiels de règles et consigne chaque écart dans un rapport de validation.
Schéma XML de la syntaxe
Une facture électronique conforme à la norme EN 16931 se présente dans l’une des deux syntaxes, UBL ou UN/CEFACT CII. Toutes les spécifications d’application courantes reposent sur ces deux syntaxes, par exemple XRechnung, ZUGFeRD et Peppol BIS Billing 3.0.
Le schéma XML de la syntaxe définit quels éléments sont autorisés, dans quel ordre ils apparaissent et quel type de données ils ont.
Les erreurs de schéma n’ont pas d’identifiant de règle. L’analyseur XML les signale avec ses propres codes, par exemple cvc-complex-type.2.4.a pour un élément situé à un endroit où le schéma ne l’attend pas.
Avec ZUGFeRD, un fichier CII est intégré dans un PDF. Le validateur contrôle la partie XML. En cas d’écart avec la partie visuelle, c’est cette partie qui fait foi, selon la circulaire du ministère fédéral allemand des Finances (BMF-Schreiben) du 15 octobre 2025 relative à l’introduction de la facture électronique obligatoire.
Règles métier de la norme EN 16931
Les règles métier contrôlent les données d’une facture électronique à la recherche d’erreurs logiques, par exemple si les champs obligatoires sont remplis et si les totaux concordent. Le Comité européen de normalisation (CEN) publie ces règles sous forme de fichiers Schematron sur GitHub, respectivement pour UBL et pour CII.
Le préfixe de l’identifiant de règle vous indique le type de contrôle. Les règles BR suivies d’un nombre contrôlent les champs obligatoires et leur nombre d’occurrences, BR-CO contrôle les calculs et les dépendances entre champs, BR-CL les listes de codes et BR-DEC les décimales des montants. Des règles comme BR-S, BR-AE ou BR-IC contrôlent les données relatives à certaines catégories de TVA.
Les fichiers du CEN contiennent en outre des règles propres à la syntaxe. Les règles avec le préfixe UBL-CR émettent par exemple un avertissement lorsqu’un fichier UBL contient des éléments qui n’appartiennent pas au modèle de données de la norme EN 16931.
Règles de XRechnung et de Peppol BIS Billing 3.0
XRechnung et Peppol BIS Billing 3.0 sont des spécifications d’application de la norme EN 16931, appelées en termes techniques CIUS (Core Invoice Usage Specification). Elles rendent obligatoires des champs supplémentaires et complètent la norme EN 16931 par leurs propres règles. Une CIUS ne peut pas introduire de nouveaux champs de données.
Les règles de XRechnung commencent par BR-DE et proviennent du centre de coordination des normes informatiques (Koordinierungsstelle für IT-Standards, KoSIT). Peppol BIS Billing 3.0 ajoute des règles avec les préfixes PEPPOL-EN16931 et PEPPOL-COMMON ainsi que des règles propres à certains pays.
L’identifiant de spécification dans BT-24 détermine quelle spécification d’application s’applique au fichier. Le validateur de la KoSIT choisit le scénario de contrôle approprié sur la base de cet identifiant. Un identifiant erroné ou obsolète peut donc conduire à ce que le fichier soit contrôlé selon d’autres règles ou rejeté.
Ce qu’une validation ne contrôle pas
Un validateur ne détecte pas si le taux de TVA correspond à la prestation ou si la description de la prestation est suffisante.
Selon le ministère fédéral allemand des Finances, toutes les mentions obligatoires en matière de TVA doivent figurer dans la partie structurée de la facture électronique. Un simple renvoi à une annexe contenant la description de la prestation ne suffit pas. Un nom d’article comme « voir annexe » dans BT-153 passe néanmoins la validation, car aucune règle n’évalue le contenu de ce champ.
La KoSIT et le Forum elektronische Rechnung Deutschland (FeRD) ont publié un tableau qui associe aux mentions obligatoires selon la loi allemande sur la TVA les champs BT correspondants. À l’aide de ce tableau, vous pouvez déterminer quelles mentions obligatoires votre logiciel doit sécuriser par ses propres contrôles de plausibilité.
Structure d'un rapport de validation
Chaque entrée du rapport de validation contient en règle générale quatre informations.
Identifiant de règle
L’identifiant de règle, comme BR-CO-15 ou BR-DE-2, renvoie à la règle dans la documentation du référentiel concerné.
Niveau de gravité
Un validateur qualifie chaque message d’erreur ou d’avertissement. Dans les règles Peppol, les erreurs sont dites « fatal ». Un avertissement seul n’entraîne généralement pas de rejet. Certains validateurs émettent en outre des remarques, c’est-à-dire des recommandations pour une mise en œuvre propre, sans incidence sur le résultat. À la fin de son rapport, le validateur de la KoSIT recommande d’accepter ou de rejeter le document.
Peppol introduit souvent de nouvelles règles d’abord sous forme d’avertissement, puis les élève au rang d’erreur dans une version ultérieure. Avec la version 3.0.21, les règles PEPPOL-COMMON-R052 et PEPPOL-COMMON-R053 sont par exemple passées d’avertissements à erreurs, comme l’indiquent les notes de version de Peppol BIS Billing 3.0.
Emplacement
L’emplacement est une expression XPath qui pointe vers l’élément concerné dans le XML. Un même numéro BT se trouve à des endroits différents en UBL et en CII. Le montant de la facture TVA comprise (BT-112) figure en UBL dans l’élément cbc:TaxInclusiveAmount sous cac:LegalMonetaryTotal, et en CII dans l’élément ram:GrandTotalAmount sous ram:SpecifiedTradeSettlementHeaderMonetarySummation.
Pour les règles qui comparent plusieurs champs, l’emplacement pointe souvent vers un élément parent. Vous trouvez alors la valeur qui déclenche le message grâce au texte du message.
Texte du message
Le texte du message décrit la règle et cite le plus souvent les numéros BT concernés. Le message relatif à BR-CO-15 indique par exemple que le montant de la facture TVA comprise (BT-112) doit être égal à la somme du montant de la facture hors TVA (BT-109) et du montant de TVA (BT-110).
Depuis la version 3.0.21, les textes des règles Peppol commencent par l’identifiant de règle.
Analyser les rapports de validation dans le bon ordre
Un long rapport de validation remonte souvent à quelques causes seulement.
-
Corriger les erreurs de schéma
Tant que le fichier ne respecte pas le schéma, les résultats des règles métier sont peu significatifs, voire absents. Corrigez donc d'abord les erreurs de schéma dans l'export, puis validez à nouveau le fichier.
-
Regrouper les entrées par identifiant de règle
Une erreur de mappage peut survenir dans chaque ligne de facture. Une facture de 40 lignes génère alors 40 entrées pour la même règle, qui remontent à une seule cause. Analysez donc le rapport par identifiant de règle.
-
Identifier les erreurs consécutives
Un élément manquant peut enfreindre plusieurs règles à la fois. Si la ventilation de la TVA (BG-23) est absente, le validateur signale par exemple BR-CO-18 et, en plus, des règles de la catégorie de TVA concernée comme BR-S-01. Corrigez d'abord la cause et validez à nouveau avant de traiter individuellement les autres messages.
-
Remonter à votre modèle de données grâce au numéro BT
Le numéro BT relie le rapport de validation à votre logiciel. Tenez à jour une correspondance entre chaque numéro BT et le champ de base de données, le champ de formulaire dans votre interface et la responsabilité. La responsabilité détermine si c'est votre équipe qui corrige une erreur ou votre client, par exemple lorsque des données de base manquent.
-
Évaluer et consigner les avertissements
Décidez pour chaque avertissement si vous le corrigez ou l'acceptez sciemment, et consignez cette décision. À chaque nouvelle version, vérifiez si un avertissement accepté est élevé au rang d'erreur.
Causes d'erreur typiques par groupe de règles
Le groupe de règles indique souvent déjà à quel endroit de votre logiciel la correction doit intervenir.
Erreurs de schéma sans identifiant de règle
La cause réside dans l’ordre des éléments, l’espace de noms ou un type de données erroné dans l’export. La correction intervient dans la fonction d’export, une seule fois pour tous les clients.
BR suivi d’un nombre
La cause réside dans un champ obligatoire qui n’est pas mappé ou qui est vide dans les données de base. La correction intervient dans le mappage ou au niveau du champ obligatoire dans l’interface.
BR-CO et BR-DEC
La cause réside dans les totaux, l’arrondi, les remises et les majorations au niveau du document. La correction intervient dans la logique de calcul de la création des factures.
BR-CL
La cause réside dans un code obsolète ou propriétaire, par exemple pour les unités de mesure ou les pays. La correction intervient au niveau des listes de codes de votre logiciel.
BR-S, BR-AE, BR-IC et autres catégories
La catégorie de TVA, le taux de TVA et le motif d’exonération ne concordent pas. La correction intervient dans la logique fiscale et dans les données de base des articles.
UBL-CR
L’export contient des éléments UBL en dehors du modèle de données de la norme EN 16931. La correction intervient dans la fonction d’export.
BR-DE
Les coordonnées du vendeur, les informations de paiement ou la référence de l’acheteur manquent. La correction intervient le plus souvent au niveau des données de base de vos clients.
PEPPOL-EN16931 et PEPPOL-COMMON
L’adresse électronique manque ou un identifiant a un format erroné. La correction intervient au niveau des données de base et de la gestion des identifiants Peppol.
Référence de l’acheteur manquante dans XRechnung (BR-DE-15)
La règle BR-DE-15 signale une référence de l’acheteur manquante dans BT-10. Pour les factures adressées à l’administration publique, ce champ contient le Leitweg-ID de l’administration. Pour les factures B2B, selon le ministère fédéral allemand des Finances, un caractère de remplacement comme « - » suffit du point de vue de la TVA lorsque le destinataire de la facture n’impose pas son propre identifiant. Votre logiciel peut donc préremplir ce champ pour les factures B2B avec un caractère de remplacement que vos clients peuvent écraser.
Écarts d’arrondi sur la TVA (BR-S-09)
La règle BR-S-09 compare le montant de TVA de la catégorie taux normal au produit de la base d’imposition et du taux de TVA. Si votre logiciel arrondit la TVA par ligne et additionne les montants, le total peut s’en écarter. Avec de nombreuses lignes, l’écart peut dépasser la tolérance admise par la règle. Calculez donc le montant de TVA par catégorie à partir de la base d’imposition et du taux, comme le prévoit la règle.
Intégrer la validation dans votre logiciel
La validation a sa place à cinq endroits de votre logiciel et de votre processus de développement.
Avant l’envoi
Votre logiciel devrait valider chaque facture électronique immédiatement après sa création et bloquer l’envoi en cas d’erreur. Vos clients ne savent pas quoi faire d’un identifiant de règle ou d’une expression XPath. Traduisez donc les règles que vos clients peuvent corriger eux-mêmes en un message affiché au niveau du champ de formulaire concerné. Le message relatif à BR-DE-6, le numéro de téléphone du contact du vendeur dans BT-42, peut par exemple être : « Veuillez indiquer un numéro de téléphone pour les questions ».
Votre client ne peut pas corriger les erreurs dues à votre mappage ou à votre logique de calcul. Ces erreurs devraient être transmises à votre équipe sous forme de message interne.
À la réception
Votre logiciel devrait aussi valider les factures électroniques entrantes et afficher le résultat au niveau de la pièce. Conservez le fichier d’origine inchangé et le rapport de validation comme document distinct à côté. Le ministère fédéral allemand des Finances exige qu’au moins la partie structurée d’une facture électronique soit conservée intacte dans sa forme d’origine.
Si une facture entrante contient des erreurs, votre client peut demander une facture rectifiée à l’émetteur. Votre logiciel peut faciliter cette étape, par exemple avec une demande préparée à l’émetteur contenant le rapport de validation.
Dans les tests automatisés
Constituez une collection de factures de test couvrant vos types de factures avec leurs codes, par exemple 380 pour une facture et 384 pour une facture rectificative. Couvrez en outre chaque catégorie de TVA utilisée par vos clients. S’y ajoutent les remises et majorations ainsi que chaque syntaxe générée par votre logiciel. Incluez aussi délibérément des fichiers erronés et vérifiez que le validateur les rejette.
Le validateur de la KoSIT est un programme open source en ligne de commande qui peut être intégré dans un pipeline de build. La KoSIT met en outre à disposition une suite de tests avec des factures d’exemple, qui constitue un bon point de départ pour votre propre collection.
Après chaque mise à jour des référentiels de règles
Les référentiels de règles changent aussi sans nouveau numéro de version. Pour XRechnung 3.0.2, la KoSIT publie régulièrement des bundles avec des corrections d’erreurs, dernièrement dans la version du 31 août 2026. XRechnung 3.0 reste en vigueur au moins jusqu’au 31 juillet 2027.
La préversion de la spécification XRechnung 4.0 est parue le 15 septembre 2026. Elle n’est expressément pas destinée à un usage en production, mais vous donne un premier aperçu des fonctionnalités nouvelles et modifiées. La version finale devrait paraître au printemps 2027, avec les composants techniques.
OpenPeppol publie régulièrement de nouvelles versions de Peppol BIS Billing 3.0, ces dernières années à chaque fois en mai et en novembre. La version 3.0.21 a été publiée le 20 mai 2026 et est obligatoire depuis le 17 août 2026.
Prévoyez pour chaque version une date fixe à laquelle vous validez votre collection de tests par rapport aux nouvelles règles. Consignez dans chaque rapport de validation avec quelle version du validateur et du référentiel il a été produit. Vous pourrez ainsi retracer un résultat même si les règles ont changé entre-temps. Pour le passage à XRechnung 4.0, votre environnement de test devrait pouvoir contrôler les deux versions en parallèle.
Analyser les rapports de validation pour l’ensemble des clients
Si votre logiciel génère des factures électroniques pour de nombreux clients, une analyse des rapports de validation sur l’ensemble des clients vaut la peine. Si le même identifiant de règle apparaît soudain chez de nombreux clients, la cause se trouve probablement dans le mappage ou dans un nouveau référentiel de règles. S’il n’apparaît que chez un seul client, la cause se trouve plutôt dans ses données de base.
La validation avec InvoiceRails
Vous pouvez mettre en œuvre vous-même l’intégralité des étapes décrites dans cet article. L’effort ponctuel est raisonnable, l’effort continu ne l’est pas : les référentiels de règles, les listes de codes et les configurations de contrôle changent plusieurs fois par an, et chaque changement doit être répercuté dans vos tests, dans votre envoi et dans votre planification des versions.
La validation, l’envoi et la maintenance des référentiels de règles peuvent donc aussi être confiés à un point d’accès Peppol (Access Point) certifié comme InvoiceRails.
Validateur de factures électroniques pour les contrôles ponctuels
Le validateur de factures électroniques gratuit d’InvoiceRails contrôle les fichiers XML en UBL et en CII ainsi que les factures PDF hybrides, sans inscription. Il détecte automatiquement la syntaxe, la version et le profil, notamment XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X et d’autres profils de la norme EN 16931. Il valide ensuite le fichier par rapport au schéma XML ainsi qu’aux règles Schematron et métier du profil détecté. Vous pouvez télécharger le rapport de validation en PDF ou le partager par lien, par exemple lorsque votre support examine une facture rejetée avec un client.
L’API InvoiceRails dans votre logiciel
InvoiceRails est le point d’accès Peppol certifié OpenPeppol de fino data services. Votre logiciel se connecte à InvoiceRails via une API REST et envoie et reçoit par ce biais des factures électroniques pour un nombre illimité de clients, en marque blanche si vous le souhaitez.
L’API propose la validation comme point de terminaison dédié, également avec détection automatique du profil. Votre logiciel peut ainsi contrôler les factures électroniques immédiatement après leur création. Chaque message de la réponse contient l’identifiant de règle, le niveau de gravité, le texte du message et l’emplacement sous forme de XPath. Votre logiciel peut enregistrer l’identifiant de validation avec la facture et consulter à nouveau le résultat pendant au moins 90 jours.
InvoiceRails valide chaque fichier que votre logiciel envoie via Peppol, même sans cet appel. Votre logiciel doit vérifier au préalable quels formats un destinataire prend en charge.
InvoiceRails contrôle aussi les factures électroniques entrantes et transmet à votre logiciel le fichier d’origine accompagné des données de facture extraites. Un webhook signale à votre logiciel chaque changement du statut de remise.
Votre logiciel reste responsable de la correspondance des champs de votre modèle de données, des messages compréhensibles dans votre interface et des contrôles de plausibilité pour les mentions obligatoires qu’aucune règle ne couvre.
