XRechnung, ZUGFeRD et BIS Billing 3.0 : quels formats de facture électronique votre logiciel devrait prendre en charge

La norme EN 16931 décrit un modèle de données sémantique. Elle définit les informations que contient une facture et leurs relations, par exemple le numéro de facture en tant que BT-1 ou la référence de l’acheteur en tant que BT-10. La norme elle-même n’est pas un format de fichier.

Pour la représentation technique, elle autorise deux syntaxes : UBL et UN/CEFACT CII. Toutes deux représentent le même modèle sémantique, mais diffèrent par les noms des éléments et la structure. Un logiciel qui ne lit que l’UBL ne peut pas traiter automatiquement une facture CII, même si celle-ci est conforme à la norme.

Pour la mise en œuvre, cela détermine l’effort de maintenance. Deux mappages parallèles signifient que chaque modification de règle doit être reportée à deux endroits. Celui qui mappe une seule fois sur le modèle sémantique de la norme et génère à partir de celui-ci les deux syntaxes n’intervient qu’à un seul endroit par modification.

À la réception, le fichier entrant est à l’inverse d’abord mappé sur le modèle sémantique, puis repris dans votre modèle de données.

Au-dessus de la norme se trouvent les déclinaisons nationales et propres aux réseaux, appelées dans la norme Core Invoice Usage Specification, en abrégé CIUS. Une CIUS restreint la norme. Elle rend obligatoires des champs facultatifs, en exclut d’autres et apporte ses propres règles Schematron. Les déclinaisons qui vont au-delà du périmètre de la norme sont appelées extensions.

Indépendamment de la syntaxe et de la déclinaison, une facture électronique se présente soit sous forme de fichier XML pur, soit sous forme de PDF/A-3 avec un fichier XML intégré. Pour ce second cas, l’expression « format hybride » s’est imposée.

XRechnung est une CIUS de la norme EN 16931, maintenue par le centre de coordination des normes informatiques (Koordinierungsstelle für IT-Standards), en abrégé KoSIT. Elle existe dans les deux syntaxes. Elle ne comporte pas de composante visuelle : le fichier est du XML pur.

XRechnung est imposé pour les factures adressées à l’administration fédérale allemande. La facture est adressée via le Leitweg-ID, indiqué dans le jeu de données en tant que référence de l’acheteur.

Le canal de dépôt dépend du destinataire. Les portails ZRE et OZG-RE ou un point d’accès Peppol (Access Point) entrent en ligne de compte. En B2B, le Leitweg-ID ne joue aucun rôle. XRechnung n’y est qu’un profil autorisé parmi d’autres.

La version 3.0.2 est actuellement en vigueur. Pour XRechnung 4.0, la mise en œuvre de la norme EN 16931 dans sa version 2026, une préversion existe déjà. La version finale de XRechnung 4.0 devrait être publiée au printemps 2027.

ZUGFeRD intègre un fichier XML selon CII dans un PDF/A-3. L’humain voit le PDF, tandis que le logiciel lit le XML.

La spécification prévoit plusieurs profils avec des volumes de données différents, de MINIMUM à EXTENDED.

MINIMUM et BASIC WL ne contiennent pas de facture complète et ne satisfont pas à la norme. À partir du profil EN 16931, appelé COMFORT dans les versions antérieures, la partie structurée est conforme à la norme. Votre logiciel devrait lire le profil lors de l’import et traiter séparément les fichiers MINIMUM ou BASIC WL, par exemple au moyen d’un contrôle manuel.

Factur-X est techniquement en grande partie identique à ZUGFeRD.

ZUGFeRD est surtout pertinent lorsque vos clients facturent des destinataires qui continuent de contrôler visuellement les factures. Seul le XML intégré fait alors foi juridiquement. En cas d’écart entre le PDF et le XML, ce sont les données de la partie structurée qui prévalent, selon la circulaire du ministère fédéral allemand des Finances (BMF-Schreiben) du 15 octobre 2025.

Un processus d’approbation qui ne contrôle que le PDF peut donc approuver une facture dont le contenu déterminant est différent.

À l’envoi, votre logiciel devrait générer le PDF et le XML à partir du même jeu de données, afin qu’ils ne divergent pas. À la réception, il devrait construire pour le contrôle sa propre vue à partir du XML au lieu d’afficher le PDF fourni. Le ministère fédéral allemand des Finances recommande lui aussi de visualiser soi-même la partie XML.

Peppol BIS Billing 3.0 est également une CIUS de la norme EN 16931, fixée sur UBL 2.1. OpenPeppol l’a spécifié comme format propre pour l’échange de factures et d’avoirs via le réseau.

En plus des règles de la norme, il apporte ses propres règles Schematron. Un fichier peut réussir le contrôle selon la norme EN 16931 et échouer sur une règle Peppol. Il s’agit souvent de listes de codes ou de champs que le réseau définit de manière plus stricte que la norme.

La spécification évolue par versions successives. Celui qui valide lui-même devrait vérifier si ses jeux de règles sont à jour.

À plus long terme, Peppol évolue vers PINT, une base harmonisée à l’échelle internationale pour les profils de facture en dehors de l’Europe. Pour la mise en œuvre en Allemagne, cela ne change rien pour l’instant.

Pour ces factures, votre logiciel doit pouvoir générer XRechnung. Le Leitweg-ID du destinataire doit figurer comme champ obligatoire dans le jeu de données de la facture et est restitué dans la XRechnung en tant que référence de l’acheteur (BT-10). S’il manque ou figure dans le mauvais champ, le portail de réception rejette la facture.

La loi exige une facture conforme à la norme EN 16931 et laisse le format ouvert. XRechnung, ZUGFeRD à partir du profil EN 16931 et aussi Peppol BIS Billing sont autorisés. Le XML intégré reste juridiquement déterminant. En cas d’écart entre le PDF et le XML, le destinataire contrôle peut-être d’autres données que celles qui font juridiquement foi.

Les entreprises nationales doivent pouvoir recevoir des factures électroniques conformes à la norme EN 16931 depuis le 1er janvier 2025. Pour une facture électronique conforme à la norme, l’émetteur n’a donc pas besoin de l’accord du destinataire, même si celui-ci préfère un format particulier.

Les deux parties doivent seulement s’entendre sur le canal de transmission et sur les formats non couverts par la norme. En pratique, le canal convenu a donc sa place dans les données de base de chaque partenaire commercial.

Outre Peppol BIS Billing 3.0, le réseau Peppol permet aussi de transmettre XRechnung et, depuis mars 2025, ZUGFeRD sous forme de fichier hybride. Les types de documents qu’un destinataire a enregistrés dans le service d’annuaire indiquent quels formats il accepte. Avant l’envoi, votre logiciel doit interroger cet enregistrement et choisir le format adapté. Pour des vérifications ponctuelles, la recherche d’identifiant Peppol l’affiche sans inscription.

En exploitation courante, votre logiciel devrait effectuer cette requête automatiquement avant l’envoi, soit directement via les services d’annuaire SML et SMP, soit via l’API de votre point d’accès Peppol. Sur cette base, un format pris en charge par les deux parties est déterminé, puis la facture électronique est générée dans ce format.

Les factures entrantes arrivent dans le format choisi par l’émetteur. Votre logiciel devrait donc pouvoir lire les deux syntaxes, UBL et CII, et donc aussi XRechnung dans ses deux variantes. S’y ajoutent ZUGFeRD et Factur-X en tant que fichiers hybrides et, dès que vos clients reçoivent des factures de l’étranger, les profils qui y sont d’usage.

Chaque fichier entrant contient un identifiant indiquant la déclinaison qu’il utilise. En UBL, il figure dans l’élément cbc:CustomizationID, en CII dans le paramètre de contexte de la directive (guideline). Votre logiciel devrait lire cet identifiant en premier, car il détermine quelles règles de contrôle s’appliquent et comment le fichier est repris dans votre modèle de données.

Certains points d’accès Peppol vous déchargent de cette étape. Ils contrôlent le fichier entrant, en extraient les données de facture et les transmettent avec le fichier d’origine sous forme de jeu de données uniforme.

Votre logiciel devrait couvrir entièrement la réception avant l’envoi, c’est-à-dire les deux syntaxes et les formats hybrides, car vos clients doivent déjà pouvoir recevoir des factures électroniques aujourd’hui.

L’envoi deviendra obligatoire pour vos clients en deux étapes. À partir du 1er janvier 2027 pour un chiffre d’affaires total de l’année précédente supérieur à 800 000 euros, et à partir du 1er janvier 2028 pour toutes les autres opérations B2B nationales.

Celui qui commence par la syntaxe CII peut ainsi générer XRechnung dans sa variante CII et ZUGFeRD. UBL devient nécessaire dès que des destinataires du réseau Peppol attendent Peppol BIS Billing 3.0, car ce format requiert UBL.

Toutes les mentions obligatoires en matière de TVA doivent figurer dans la partie structurée de la facture électronique, sous une forme exploitable par machine. Cela inclut la description de la prestation. Un renvoi à une annexe, à un bon de livraison ou à un lien ne remplace pas un champ obligatoire. Les bases en sont la FAQ du ministère fédéral allemand des Finances sur la facture électronique et la circulaire du ministère fédéral allemand des Finances (BMF-Schreiben) du 15 octobre 2025.

La raison tient à la structure de la facture électronique. Dans les formats hybrides comme ZUGFeRD, ce sont les données XML qui priment ; le PDF n’est qu’une vue. Une information visible uniquement dans le PDF ne compte donc pas.

S’il manque une mention obligatoire dans la partie structurée, la facture est considérée comme non conforme et le droit à déduction de la TVA du destinataire peut être compromis. Vos clients s’en aperçoivent au plus tard lorsque des partenaires commerciaux rejettent des factures pour cette raison.

De nombreux modèles de facture véhiculent des mentions obligatoires sous forme de blocs de texte qui n’apparaissent que dans le PDF. Cela concerne souvent la description de la prestation, par exemple « selon l’offre 2026-114 », la période de prestation dans le pied de page de la facture et la mention de l’autoliquidation par le preneur.

Dans le modèle de données, chacune de ces informations devrait disposer de son propre champ, à partir duquel le XML est alimenté. La période de prestation a sa place dans les champs de la période de facturation (BG-14), la mention d’autoliquidation dans la catégorie de TVA avec motif d’exonération (BT-120 et BT-121).

La validation technique contrôle si les champs obligatoires de la norme sont présents et formellement correctement remplis. Elle ne détecte pas si une description de prestation est suffisante du point de vue de la TVA. Une facture peut donc réussir le contrôle tout en contenant une mention obligatoire de manière insuffisante.

Les bons de livraison, relevés d’heures et autres documents accompagnant la facture peuvent être intégrés en pièce jointe dans la facture électronique, dans la norme EN 16931 via le groupe des pièces justificatives additionnelles (BG-24). Cela remplace l’envoi séparé et réunit facture et justificatif dans un seul fichier.

Une XRechnung est contrôlée selon deux référentiels de règles : les règles de la norme EN 16931 et les règles supplémentaires de la KoSIT. Il en va de même pour Peppol BIS Billing 3.0 avec les règles d’OpenPeppol. Un contrôle effectué uniquement selon la norme n’indique donc que de façon limitée si le destinataire acceptera le fichier. Votre logiciel devrait contrôler selon le référentiel de la déclinaison attendue par le destinataire.

La KoSIT et OpenPeppol publient régulièrement de nouvelles versions de leurs référentiels de règles, avec des listes de codes et des règles Schematron adaptées. Si votre logiciel ne tient pas ses jeux de règles à jour, des factures jusqu’ici acceptées peuvent être rejetées. Le rejet vient alors du destinataire, mais la cause réside dans votre propre jeu de règles obsolète.

Pour les tests pendant le développement, des fichiers individuels peuvent être contrôlés selon la norme EN 16931 et les règles Peppol avec le validateur de factures électroniques gratuit. Pour le contrôle automatique en exploitation, InvoiceRails propose aussi la validation via une API, selon la norme EN 16931 et des profils comme XRechnung, ZUGFeRD et Peppol BIS Billing. Le rapport de validation distingue erreurs, avertissements et remarques.

Un mappage se construit une fois, mais les règles de contrôle qui le sous-tendent peuvent changer plusieurs fois par an. Le prochain changement majeur s’annonce déjà avec XRechnung 4.0 et la norme EN 16931 dans sa version 2026.

La version 2026 s’appuie sur UBL 2.5. Dans les implémentations conformes, UBL 2.5 ne pourra être utilisé qu’une fois que le CEN aura publié une liaison syntaxique (syntax binding) mise à jour. D’ici là, les liaisons existantes basées sur UBL 2.1 s’appliquent. Les éditeurs peuvent donc préparer la transition, mais pas encore la mettre en œuvre.

Celui qui construit lui-même la connexion assume durablement cette maintenance. Cela implique de tenir à jour les mappages pour les deux syntaxes, les listes de codes et les règles Schematron, et de suivre les calendriers de versions de la KoSIT, du FeRD, d’OpenPeppol et du CEN. C’est faisable, mais cela mobilise du temps de développement qui manque au produit lui-même.

Il est aussi possible de confier la maintenance des formats à un point d’accès Peppol. InvoiceRails, le point d’accès certifié OpenPeppol de fino data services, couvre via une API plus de 60 formats, dont XRechnung, ZUGFeRD et Factur-X, et maintient en continu les règles de validation et les mises à jour de formats.

Les éditeurs connectent l’envoi et la réception une seule fois et mettent la fonction à la disposition d’autant de clients qu’ils le souhaitent, sous leur propre marque s’ils le désirent. La correspondance entre leurs propres données de facturation et l’interface reste à la charge de l’éditeur, de même que les champs obligatoires de son propre modèle de données.

Pour savoir comment les éditeurs de logiciels intègrent de manière générale la facture électronique à leur produit, lisez l’article consacré à la facture électronique pour les éditeurs de logiciels.