Vérifier les factures électroniques : comprendre ZUGFeRD, XRechnung, Peppol et EN 16931

Vendredi, 15:40 : le flux de factures entrantes est arrivé. Pas complet – mais suffisamment pour poser problème. Une partie des factures électroniques reçues passe correctement, une autre reste bloquée dans la chaîne d’import. Le métier dit : « Dans le PDF, tout est correct. » L’informatique voit dans le log : „Profil non autorisé“ et „Règle métier violée“. À partir de là, ça devient politique : les achats veulent du débit, la comptabilité veut de la sécurité, l’IT ne veut pas de logique spécifique par fournisseur.

Qui, dans cette situation, doit vérifier les factures électroniques s’aperçoit vite que ZUGFeRD, XRechnung, Peppol et EN 16931 ne relèvent pas d’un débat de vocabulaire, mais d’un arbitrage. Selon la rigueur de vos contrôles, l’effort et le risque évoluent – et avec eux les décisions d’architecture (service de contrôle central vs. plugin dans l’ERP), les questions d’exploitation (supervision, mises à jour, mécanismes de repli) et les questions de déploiement (groupes pilotes, communication aux fournisseurs, classes d’erreurs).

Deux objectifs qui s’opposent dans la pratique

Objectif 1 : automatisation à haut débit. De nombreuses entreprises veulent structurer la réception des factures pour que les factures structurées arrivent dans l’ERP, le workflow et l’archive sans rupture de support. Cela réduit la saisie manuelle et accélère les approbations – mais uniquement si les données sont fiables.

Objectif 2 : sécurité des contrôles avec preuve traçable. Dans le doute, il doit être possible de démontrer pourquoi une facture a été acceptée ou refusée : quel profil, quelle règle, quelle version. Cela devient pertinent au plus tard lorsque des fournisseurs se plaignent (« vous avez refusé, mais chez d’autres cela a passé ») ou que des contrôles internes exigent une chaîne justificative irréprochable.

Les deux objectifs sont légitimes. Le conflit naît du fait que chaque contrôle supplémentaire réduit certes les risques, mais peut aussi générer davantage de cas particuliers. Cela est particulièrement vrai lorsque des fournisseurs envoient des profils différents ou qu’un changement de version dans la spécification n’est pas encore partout déployé.

EN 16931 : pourquoi vous devez gérer la sémantique plutôt que « le format de fichier » lors de la validation

EN 16931 est dans la pratique souvent qualifiée de « format XML ». Une autre perspective est plus utile : EN 16931 est le modèle de données sémantique pour les éléments centraux d’une facture électronique — c’est‑à‑dire la signification des champs de données et les règles métier (Business Rules) associées pour la conformité. La Commission européenne présente EN 16931 exactement de cette façon : comme un modèle de données sémantique des éléments centraux incluant les règles de conformité.^[Source]

La conséquence pratique pour l’IT et l’exploitation : « XML est bien formé » n’est qu’une porte d’entrée. L’essentiel est de vérifier si une facture est cohérente sur le plan sémantique (logique des totaux, indications fiscales, champs obligatoires, codes). Et si elle respecte le profil attendu — les profils définissent quelles parties de la norme s’appliquent et sous quelle déclinaison.

Il est également important de noter que les normes n’immobilisent pas. Une édition mise à jour est déjà répertoriée comme EN 16931‑1:2026 dans les répertoires de normes.^[Source] Cela ne signifie pas que vous devez migrer immédiatement. Cela signifie en revanche que votre modèle de contrôle et d’exploitation doit être conçu pour que les jeux de règles et les validateurs puissent être versionnés et mis à jour de manière contrôlée — sans que l’ensemble du traitement ne se retrouve en situation critique à chaque mise à jour.

ZUGFeRD et XRechnung : deux approches pour mettre en pratique la même obligation

En Allemagne, deux variantes courantes coexistent dans de nombreuses entreprises :

• ZUGFeRD en tant que format hybride : un fichier PDF/A‑3 dans lequel des données de facturation structurées (XML) sont intégrées. FeRD décrit ZUGFeRD 2.2 explicitement comme un modèle hybride : un document lisible accompagné d’un XML lisible par machine inséré dans un PDF/A‑3.^[Source]
• XRechnung en tant que format purement structuré : l’accent est entièrement mis sur des données traitables par machine, sans qu’un PDF accompagne le fichier.

Le choix est moins idéologique qu’opérationnel : ZUGFeRD est souvent plus facile à accepter par les services métier, parce qu’un justificatif lisible existe. En revanche, le PDF ne doit pas inciter à négliger la validation de l’XML. XRechnung est résolument orientée données et donc adaptée à l’automatisation, mais elle exige dans la pratique presque toujours un bon outil d’affichage et de contrôle qui rende le contenu compréhensible.

Cadre juridique : ce qui, à partir de 2025, compte comme « facture électronique »

Pour la planification du projet, une remarque est particulièrement opérante : dans le contexte de la TVA, à partir du 01.01.2025, une facture électronique n’est considérée comme telle que si elle est émise/transmise/reçue dans un format électronique structuré et permet un traitement électronique.^[Quelle] Un simple PDF sans données structurées ne relève donc pas de la définition pertinente ici.

Le BMF cite en outre XRechnung ainsi que ZUGFeRD à partir de la version 2.0.1 (avec des exceptions de profil) comme formats qui, en principe, satisfont aux exigences fiscales en matière de TVA.^[Quelle] Opérationnellement, cela ne pose pas une « question de religion du format », mais une obligation claire : vous devez reconnaître, vérifier et documenter de manière traçable le profil et la version. Sinon, ni une passerelle fiable ni une justification propre expliquant pourquoi une facture a été traitée d’une certaine manière ne sont possibles.

Bien situer Peppol : transport et interopérabilité plutôt que « encore un format »

Dans le quotidien, Peppol est souvent traité comme un autre format de facture. Cela crée de fausses attentes. Peppol est d’abord un cadre de transmission et d’interopérabilité pour les documents commerciaux structurés. Pour les factures, Peppol BIS Billing 3.0 est le composant pertinent.

Dans la documentation officielle BIS Billing, la conformité EN‑16931 est visible via le schéma CustomizationID (c’est‑à‑dire via un identifiant qui décrit le profil/le contexte de « customization »). C’est important car cela montre : dans l’environnement Peppol, les identifiants de profil et de conformité sont une partie de l’analyse automatique et pas seulement un « nice to have ».^[Quelle]

Les conséquences en exploitation sont très concrètes : outre la vérification des documents, s’ajoutent des aspects liés au transport. Adressage, identifiants de participants, rejets techniques, accusés de réception – tout cela génère ses propres typologies d’erreurs. Si vous ne classez pas ces erreurs séparément, tout finit par arriver chez la comptabilité comme « facture cassée » ou chez l’informatique comme « Peppol plante ».

Leitweg-ID & Peppol-ID : pourquoi les identifiants sont critiques en production

Le guide d’utilisation du canal d’arrivée Peppol pour l’administration fédérale décrit par exemple la formation de la Peppol-ID à partir du préfixe 0204 et de la Leitweg-ID pour les services fédéraux raccordés, et situe la Peppol Authority Deutschland chez KoSIT.^[Quelle] C’est un contexte spécifique (administration fédérale). La leçon transférable pour les entreprises reste cependant claire : les identifiants ne sont pas un sujet marginal. Ils appartiennent aux runbooks, aux cas de test et à la configuration – car une « mauvaise ID » bloque en production tout autant qu’un « mauvais profil ».

Carte d’arbitrage : stratégie de vérification selon utilité, effort et risque

Une stratégie opérationnelle pratique segmente les vérifications en niveaux. Vous décidez délibérément quel niveau sert de gate strict (rejet) et quel niveau déclenche seulement un avertissement (clarification). La carte suivante aide à comparer des options typiques.

Contrôle des factures électroniques : un parcours d’examen robuste en exploitation

Si vous formulez le processus de contrôle de manière à ce qu’il soit retrouvable dans les logs, runbooks et systèmes de tickets, les frictions ultérieures diminuent. Le parcours suivant est délibérément « orienté exploitation » et indépendant du canal d’entrée, qu’il s’agisse d’e‑mail, d’upload, d’API ou de Peppol.

1. Enregistrer la réception : canal, horodatage, identifiants expéditeur/destinataire, métadonnées techniques. C’est votre piste d’audit.
2. Identifier le conteneur : pur XML ? ZUGFeRD (PDF/A‑3 avec XML incorporé) ? Autre ? En cas d’hybride : extraire l’XML et le traiter comme objet de vérification séparé.
3. Déterminer le profil et la version : quelle déclinaison est présente (p. ex. profil EN‑16931, version XRechnung, Peppol BIS Billing avec CustomizationID) ? Sans cette information, vos contrôles sont vains.
4. Validation de la structure : contrôle schéma/profil avec version du validateur et état du jeu de règles consignés. Le résultat doit être reproductible.
5. Règles sémantiques : évaluer les EN‑16931 Business Rules et les contrôles de cohérence (totaux/taxes/logique des champs obligatoires).
6. Règles métiers internes : rapprochement des données de base, référence à la commande, vérification des doublons, règles d’approbation, exigences d’imputation comptable. Ces règles sont spécifiques à l’entreprise et évoluent souvent plus fréquemment que les standards.
7. Piloter le résultat : transmettre/comptabiliser automatiquement, mettre en clarification ou rejeter – incluant la classe d’erreur, une brève justification et la référence au log de contrôle.

La limite de ce parcours : il ne détermine pas automatiquement quelle règle doit être « stricte » chez vous. C’est une décision de management entre débit de processus et risque — et elle doit être documentée afin que les changements soient traçables ultérieurement.

Conséquences architecturales : service de validation centralisé ou validation dans le système cible ?

Dans un projet, une question apparemment mineure surgit souvent : « Où validons‑nous ? » En pratique, elle détermine la maintenabilité et les coûts d’exploitation.

Validation centralisée (service ou plateforme d’intégration)

La validation s’exécute comme un service central : règles unifiées, classes d’erreurs uniformes, un emplacement pour les mises à jour. Cela facilite le monitoring (par ex. taux de rejet par fournisseur/profil) et simplifie les audits, car les résultats des contrôles sont déposés de manière cohérente.

Le prix à payer : vous exploitez un composant supplémentaire. La haute disponibilité, les fenêtres de maintenance, la gestion des versions et le rollback pour les mises à jour de règles deviennent obligatoires. En contrepartie, vous gagnez en contrôle.

Validation décentralisée (plugins ERP/DMS, clients)

Ici, les contrôles sont effectués dans plusieurs systèmes. Cela peut sembler attractif à court terme (« l’ERP peut déjà le faire »), mais conduit souvent à une dérive : versions de validateurs différentes, messages d’erreur disparates, exceptions variées. Et c’est précisément ce qui nuit à la standardisation et au support.

Pour la direction IT, une règle empirique est utile : si plusieurs canaux d’entrée et plusieurs systèmes cibles sont en jeu, un service de validation centralisé est souvent la décision la plus robuste à long terme. S’il n’y a qu’un chemin clair (un ERP, une entrée), la validation décentralisée peut être acceptable — mais la gestion des versions doit alors rester soigneusement réglée.

Ce qui prend vraiment du temps dans les projets lors des vérifications

Techniquement, la lecture du XML est rarement le problème. Le temps et le risque apparaissent aux interfaces :

• Diversité des profils et des versions : Sans transparence sur quels partenaires envoient quels profils, chaque release devient un vol à l’aveugle. La télémétrie (profil/version par entrée) n’est donc pas un luxe, mais un instrument de pilotage.
• Traduction des erreurs : Les sorties du validateur sont souvent trop brutes pour les départements métier ou les fournisseurs. Elles nécessitent un mappage vers des catégories compréhensibles et des options d’action.
• Données de base et processus : Les factures structurées rendent visibles les problèmes de données de base (affectation fournisseur manquante, numéros de commande incohérents). C’est positif, mais génère initialement davantage de cas à clarifier.
• Chaîne de documents et archivage : Pour la traçabilité, « fichier archivé » ne suffit pas. Sont déterminants : l’original (PDF/XML), le résultat de la vérification, la version du jeu de règles, l’horodatage et le lien avec le processus métier (validation, comptabilisation).

Déploiement sans rupture de processus : vagues, basculement et critères mesurables

Un déploiement stable se construit en n’activant pas tout en même temps. Une logique en vagues s’est avérée efficace :

• Pilote : peu de fournisseurs et de types de documents, journalisation très détaillée, revue quotidienne des classes d’erreurs les plus fréquentes.
• Stabilisation : affiner les règles, mais avec des fenêtres de changement et une communication claire. Traiter de manière ciblée les erreurs récurrentes avec les achats/fournisseurs.
• Mise à l’échelle : transférer le monitoring en exploitation courante (taux de rejet, durée de clarification, principales violations de règles, part manuelle).

Prévoyez aussi le mode dégradé. Si une mise à jour des règles bloque soudainement de nombreuses factures, vous avez besoin d’un basculement contrôlé (p. ex. mode avertissement temporaire au lieu d’un refus catégorique) — avec décision documentée et contrôle ultérieur. Ce n’est pas un « assouplissement », mais un frein opérationnel contre des arrêts incontrôlés.

Trois malentendus typiques à dissiper dès le départ

1) « ZUGFeRD est comme autrefois un PDF. » Dans le processus, c’est l’XML embarquée qui compte. Le PDF est utile pour les humains, mais ne remplace pas la vérification automatique. Si le PDF et l’XML divergent, il doit être clair quelle source fait foi dans le processus.

2) « Peppol rend automatiquement tout conforme. » Peppol facilite l’échange et l’interopérabilité. La conformité naît uniquement de contenus corrects et de profils appropriés. La livraison n’est pas une validation.

3) « Si le validateur est vert, on peut comptabiliser. » La conformité aux standards est une base, pas une autorisation complète du processus. Les règles internes (obligation de commande, réception des marchandises, seuils d’autorisation) restent en vigueur et devraient constituer un palier séparé, plutôt que d’être mélangées à la logique du validateur.

Conclusion : une bonne vérification allège la charge — si elle est conçue comme un processus opérationnel

La vérification des e-factures n’est pas une fin en soi. Le bénéfice apparaît lorsque la validation est pensée comme un système opérationnel : versionné, observable, avec des classes d’erreurs claires et une voie de retour qui ne se noie pas dans un embouteillage de tickets. Alors, des standards comme EN 16931, des profils comme XRechnung/ZUGFeRD et des canaux de transport comme Peppol deviennent des éléments maîtrisables de votre chaîne de processus, et non des chantiers permanents.

Pour ce sujet, Zugferd Prüfen et Xrechnung Validieren sont également importants. L’article replace ces aspects de manière compréhensible et montre ce qui importe au quotidien.

Discuter d’un projet ou d’une modernisation avec Net-Base.