EN 16931, XRechnung, Factur-X, ZUGFeRD : les formats expliqués

La facturation électronique en Europe ressemble à un zoo d’acronymes, mais la structure en dessous est simple : un standard sémantique, deux syntaxes XML, des profils nationaux par-dessus, et une astuce hybride qui emballe le XML dans un PDF. Une fois les couches identifiées, chaque nom de format trouve sa place.

Le socle : EN 16931

EN 16931 est le standard européen du contenu d’une facture électronique. Il définit les champs métier d’une facture (vendeur, acheteur, lignes, ventilation de TVA, totaux), les numérote de BT-1 à BT-165, et fixe les règles qui les tiennent ensemble : quels champs sont obligatoires, et comment les sommes doivent tomber juste (les règles de gestion BR-*). Les règles de facturation électronique de la plupart des pays de l’UE s’appuient dessus.

EN 16931 ne définit volontairement pas d’octets de fichier. Pour cela, il désigne deux syntaxes XML :

• UBL 2.1, un standard OASIS, avec des éléments comme <cbc:ID> et <cac:AccountingSupplierParty>.
• UN/CEFACT CII (Cross-Industry Invoice), avec des éléments comme <ram:SellerTradeParty>.

Le même contenu de facture peut s’écrire dans l’une ou l’autre syntaxe. Tout le reste est une couche au-dessus de ces deux-là.

Le profil allemand : XRechnung

XRechnung est le profil national allemand (une CIUS, « core invoice usage specification ») d’EN 16931, maintenu par la KoSIT, actuellement en version 3.0.2. Il accepte les deux syntaxes et durcit les règles : la référence acheteur (BT-10) devient obligatoire, et pour les factures au secteur public elle porte la Leitweg-ID qui achemine la facture vers la bonne administration.

Il est exigé pour les factures aux acheteurs publics allemands depuis 2020. Côté B2B, l’Allemagne déploie la facture électronique depuis janvier 2025 (toute entreprise doit pouvoir recevoir), l’émission devenant obligatoire en 2027 pour les entreprises au-dessus de 800 000 euros de chiffre d’affaires, puis en 2028 pour toutes.

L’hybride : Factur-X et ZUGFeRD

Factur-X (nom français) et ZUGFeRD (nom allemand) sont le même standard franco-allemand, publié conjointement par le FNFE-MPE et le FeRD. L’idée : un PDF d’apparence normale (PDF/A-3) dans lequel est embarqué le XML CII lisible par les machines. Un humain ouvre le PDF et voit une facture ; un logiciel extrait le XML et lit des données structurées. Version actuelle : Factur-X 1.09.

Factur-X existe en profils de complétude croissante (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED). Le profil EN 16931 est celui qui porte une facture complète et conforme au standard ; les profils plus petits portent moins que le jeu de données complet, ce qui compte si votre interlocuteur doit traiter le XML seul.

L’obligation française

La France bascule le 1er septembre 2026 : toute entreprise assujettie à la TVA doit pouvoir recevoir des factures électroniques, et les grandes entreprises comme les ETI doivent en émettre (les PME et micro-entreprises suivent le 1er septembre 2027). Les factures transitent par des plateformes agréées par l’administration, et Factur-X est l’un des formats du socle de la réforme, aux côtés d’UBL et de CII.

Quel format allez-vous donc croiser ?

Ce que « valide » veut dire, couche par couche

Un fichier peut être du XML bien formé et rester une facture invalide. Une vraie validation vérifie chaque couche : la syntaxe (schéma), les règles de gestion EN 16931 (champs obligatoires, cohérence des totaux) et les règles propres au profil (référence acheteur de XRechnung, listes de codes). C’est exactement ce qu’exécute l’API einvoicekit, un appel HTTP par fichier, quel que soit le format envoyé : un PDF Factur-X est déballé automatiquement, et XRechnung est vérifié dans les deux syntaxes. Pour un test manuel rapide, il y a le validateur gratuit, qui applique le même jeu de règles officiel complet.

À propos de l’échéance du 1er septembre, nous avons aussi détaillé comment valider une facture Factur-X en Python, PHP et Node.js.