Valider XRechnung : validateur KoSIT, erreurs Schematron et leur signification
Comment le validateur KoSIT vérifie les XRechnungen, ce que signifient les erreurs Schematron et comment automatiser le contrôle.
Comment la visualisation de la KoSIT transforme une XRechnung en une vue HTML ou PDF lisible, sans remplacer l'original.

Une XRechnung est un fichier XML qu'aucun humain n'est censé lire directement, et c'est précisément le cœur du problème lorsqu'un gestionnaire ou un client souhaite néanmoins consulter la facture. La solution s'appelle la visualisation : une transformation XSLT qui génère, à partir de la structure XML, une vue HTML ou PDF lisible par un humain, sans rien modifier au fichier XML original juridiquement déterminant. Cet article montre comment cela fonctionne techniquement et ce qui peut être automatisé. Situation en date d'août 2026.
Une XRechnung contient uniquement des données commerciales dans une structure normalisée selon la norme EN16931 et l'extension CIUS allemande, mais aucune information de mise en page. Si vous ouvrez le fichier directement, vous voyez des balises XML imbriquées au lieu d'une facture avec un en-tête, des lignes de position et un total. Pour que les données brutes redeviennent lisibles, une transformation supplémentaire est nécessaire pour définir quel champ apparaît où sur la page.
La KoSIT met à disposition des transformateurs XSL à cet effet, qui fonctionnent en deux étapes. Selon la description de l'architecture du projet, la facture XML, qu'elle soit au format UBL ou CII, est d'abord convertie en une forme intermédiaire neutre du point de vue de la syntaxe, enrichie d'informations sur les termes commerciaux de la norme EN16931 utilisés. Dans une seconde étape, cette forme intermédiaire sert à générer une représentation HTML spécifique à l'application, dont l'apparence finale est contrôlée par des fichiers CSS définissant la position et l'ordre des différents éléments de la facture. Selon la description du projet, ces éléments constitutifs sont explicitement conçus comme des composants optionnels destinés à être intégrés dans son propre logiciel, et non comme une application prête à l'emploi à télécharger.
Ce qui peut être automatisé, c'est avant tout l'étape allant du fichier XML entrant à la vue HTML ou PDF : un workflow peut exécuter successivement la transformation intermédiaire et la seconde étape, puis joindre directement le résultat à un e-mail, un ticket ou un système de classement dès qu'une nouvelle facture arrive. Ainsi, par exemple, la comptabilité reçoit automatiquement une vue lisible en plus du XML original, sans que personne n'ait à ouvrir manuellement un outil de visualisation. En revanche, ce qui n'est pas automatisable au sens de « configurer une fois pour toutes » est la conception CSS elle-même, car les décisions de mise en page telles que la taille de police ou l'ordre des champs restent prises une seule fois par des humains lors de la configuration de la visualisation.
Seul le fichier XML original reste juridiquement déterminant ; la visualisation HTML ou PDF n'est qu'une aide à la lecture. Pour une conservation conforme aux principes GoBD, archivez donc le fichier XML sans modification ; une visualisation générée en plus peut être conservée en parallèle, mais elle ne remplace pas l'original. Quiconque utilise à la place la version visualisée comme seul support d'archivage risque de perdre les données lisibles par machine, qui constituent en réalité la finalité de la XRechnung pour le traitement ultérieur et le contrôle.
Non, la transformation suit le même schéma pour toutes les XRechnung, car elle s'appuie sur la structure normalisée selon la norme EN16931. Vous configurez la visualisation une seule fois, puis l'appliquez ensuite à chaque facture entrante, quel que soit l'expéditeur.
Les deux formats de syntaxe passent par la même première étape de transformation vers la forme intermédiaire neutre du point de vue de la syntaxe ; ensuite, le chemin vers la vue HTML est identique. Pour les utilisateurs finaux au sein de l'entreprise, la syntaxe XML sous-jacente de la facture entrante n'est donc plus visible.
En grande partie oui, car l'en-tête, les lignes de position et le total peuvent être agencés via la conception CSS de manière à obtenir une présentation de facture familière. Cependant, le résultat ne coïncide exactement avec un modèle de facture propre à une entreprise donnée que si le fichier CSS est adapté individuellement en conséquence.
Les composants fournis par la KoSIT s'adressent aux développeurs, qui les intègrent dans un logiciel existant ou un workflow n8n. Une interface clé en main sans intégration technique n'est pas incluse dans les composants officiels ; certains portails de facturation électronique et logiciels de comptabilité proposent ici leurs propres visionneuses, parfois simplifiées.
NordFlux construit des employés numériques pour les organisations : des automatisations et des agents KI qui prennent en charge le travail répétitif. Vous gardez le contrôle.
Comment le validateur KoSIT vérifie les XRechnungen, ce que signifient les erreurs Schematron et comment automatiser le contrôle.
Réception à partir de 2025, émission à partir de 2027 ou 2028 : quel délai de l'obligation de facturation électronique s'applique à votre entreprise et de quel critère dépend la date butoir.
Comment créer avec n8n une boîte de réception automatique qui récupère, reconnaît et transmet les e-factures.
Une visionneuse rend une XRechnung isolée lisible, mais ne résout pas le vrai problème : vérifier, archiver et acheminer des dizaines de factures chaque jour vers le bon système. NordFlux met en place pour vous la chaîne automatisée de factures électroniques entrantes et sortantes, de la validation jusqu'à l'archivage du XML conforme aux exigences d'audit. Lors d'un premier échange, nous examinons votre processus de facturation actuel et identifions ce qui peut être automatisé.
Automatiser la facture électroniqueObligation de facture électronique 2027/2028