EN 16931 : la norme européenne de facture électronique expliquée

EN 16931 est la norme européenne qui définit ce que contient une facture électronique : un modèle sémantique de données composé de termes métier, de leur signification, de leur cardinalité et des règles qui les relient. Ce n'est pas un format de fichier. Deux syntaxes XML portent le modèle — UBL 2.1 et UN/CEFACT Cross Industry Invoice — et des spécifications nationales ou sectorielles telles que XRechnung, ZUGFeRD, Factur-X et Peppol BIS Billing 3.0 le restreignent ou l'étendent. Les acheteurs publics de l'UE doivent accepter les factures EN 16931 ; l'Allemagne, la France et la Belgique ont bâti leurs obligations B2B dessus.

Pourquoi EN 16931 existe

EN 16931 existe parce que la directive 2014/55/UE demandait une norme européenne unique pour remplacer les formats nationaux de facture électronique incompatibles qui fragmentaient les marchés publics. La directive exigeait que la norme soit technologiquement neutre, compatible avec les normes internationales, praticable pour les PME et utilisable dans les échanges B2B, et qu'elle s'accompagne d'un « nombre limité de syntaxes ».

Le CEN/TC 434 l'a livrée en 2017. La Commission a publié la référence de EN 16931-1:2017 et la liste des syntaxes au Journal officiel le 17 octobre 2017 (décision d'exécution (UE) 2017/1870), ce qui a déclenché le compte à rebours de l'obligation de réception B2G. Depuis, la norme est devenue le dénominateur commun de la facturation électronique européenne : la loi allemande sur la TVA définit une facture électronique par référence à elle, les formats acceptés en France sont des syntaxes EN 16931, et le format par défaut de la Belgique est un CIUS EN 16931. Le contexte européen est sur la page exigences de l'UE.

Les parties de la norme

EN 16931 est une famille de documents : une partie normative avec le modèle sémantique, une spécification technique listant les syntaxes, et des liaisons et rapports d'accompagnement.

Seules les parties 1 et 2 sont gratuites, en vertu de l'accord de licence entre la Commission et le CEN. Tout ce dont un implémenteur a besoin pour la validation est cependant public : les artefacts Schematron sont publiés sur GitHub par l'équipe eInvoicing de la Commission.

Le modèle sémantique : termes métier et groupes

Le modèle sémantique liste chaque élément d'information qu'une facture peut porter, numéroté en termes métier (BT) et regroupé en groupes métier (BG), avec une cardinalité qui indique si l'élément est obligatoire, facultatif ou répétable.

Exemples de ce que couvre le modèle :

• Niveau document : numéro de facture, date d'émission, code de type de facture, devise, référence acheteur, date d'échéance de paiement, référence de la facture antérieure pour les avoirs et corrections.
• Parties : vendeur et acheteur avec nom, adresse, identifiant TVA, identifiant d'enregistrement légal et adresse électronique ; bénéficiaire et représentant fiscal facultatifs.
• Livraison et paiement : date et adresse de livraison, moyens de paiement (virement, prélèvement, carte), conditions de paiement, compte bancaire.
• Remises et frais au niveau du document et de la ligne, chacun avec une catégorie de TVA.
• Ventilation de TVA : un groupe par catégorie et taux de TVA, avec base imposable, montant de TVA et, lorsque le taux est nul ou absent, un motif d'exonération.
• Totaux : somme des montants nets de lignes, remises, frais, total hors TVA, total TVA, total TTC, montant payé d'avance, montant dû.
• Lignes : quantité, unité, prix net, montant net de ligne, catégorie de TVA, identifiants et classification de l'article.

Le modèle est délibérément un « noyau » : il contient ce dont la majorité des factures européennes ont besoin à des fins de TVA et de paiement, pas tous les champs qu'un secteur pourrait vouloir. Les besoins supplémentaires sont traités par des extensions, décrites ci-dessous. Un parcours des éléments pour développeurs avec des exemples de requêtes se trouve dans le guide développeur EN 16931.

Syntaxes : UBL 2.1 et UN/CEFACT CII

Le modèle sémantique est porté par deux syntaxes XML listées dans CEN/TS 16931-2 et publiées au Journal officiel : OASIS UBL 2.1 (ISO/IEC 19845:2015) et UN/CEFACT Cross Industry Invoice (CII) D16B. Une liaison UN/EDIFACT existe en tant que partie 3-4 mais ne figure pas dans la liste publiée.

Les deux syntaxes expriment les mêmes termes métier, de sorte qu'une facture EN 16931 peut être représentée dans l'une ou l'autre sans perte du contenu de base. Celle que vous rencontrez dépend de l'écosystème :

Un système récepteur qui revendique la prise en charge de EN 16931 devrait accepter les deux syntaxes ; en pratique, de nombreux canaux nationaux restreignent le choix. Peppol exige UBL. ZUGFeRD et Factur-X intègrent CII. Le guide des formats liste ce que chaque pays attend.

CIUS et extensions : comment les pays adaptent le noyau

Un CIUS (Core Invoice Usage Specification) restreint EN 16931 — il peut rendre obligatoires des éléments facultatifs, restreindre des listes de codes ou ajouter des règles — mais n'ajoute jamais d'éléments, de sorte que toute facture CIUS reste une facture EN 16931 valide. Une extension ajoute des éléments et n'est donc pas automatiquement valide pour un récepteur qui ne connaît que le noyau.

XRechnung (Allemagne)

Un CIUS maintenu par la KoSIT pour les acheteurs publics, en UBL ou CII, avec une référence acheteur (Leitweg-ID) et des règles nationales de listes de codes. La version 3.0.2 est en vigueur depuis le 1er février 2024, tenue à jour par des bundles correctifs, le dernier étant l'édition « hiver 2025/26 » applicable au 31 janvier 2026. XRechnung définit aussi un mécanisme d'extension. Voir XRechnung.

Peppol BIS Billing 3.0

Le CIUS d'OpenPeppol, UBL obligatoire, identifié par le customization ID urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0, avec des règles préfixées PEPPOL-EN16931-R et des règles propres à chaque pays par-dessus. Version actuelle 3.0.21 (mai 2026). Voir Peppol.

ZUGFeRD / Factur-X

L'hybride franco-allemand définit des profils : MINIMUM et BASIC WL portent moins que le noyau et ne sont pas conformes à EN 16931 à eux seuls ; BASIC est un sous-ensemble ; EN 16931 est le noyau complet ; EXTENDED va au-delà. La version 2.5.2 (Factur-X 1.09.2) a été publiée le 4 août 2026 et s'applique à partir du 1er septembre 2026, fondée sur CII D22B avec rétrocompatibilité D16B. Voir ZUGFeRD et Factur-X.

Chaque CIUS et chaque extension s'annonce dans la facture : le customization ID (BT-24) indique quelle spécification le fichier suit, et le profile ID (BT-23) nomme le processus métier. Un récepteur lit ces deux valeurs avant de choisir un jeu de règles.

Règles métier et validation

Une facture EN 16931 est valide lorsqu'elle passe le schéma de sa syntaxe et les règles métier du modèle sémantique, exprimées en Schematron. Les règles sont la partie qui attrape les erreurs du monde réel : des totaux qui ne s'additionnent pas, une ventilation de TVA à laquelle manque une catégorie, un identifiant TVA du vendeur absent là où il est requis.

L'équipe eInvoicing de la Commission publie les artefacts de validation sur GitHub (ConnectingEurope/eInvoicing-EN16931) pour UBL et CII ; la dernière version est la 1.3.16 du 10 avril 2026, avec un rythme d'environ six mois. Les identifiants de règles suivent un schéma :

• BR-xx — règles générales de présence et de structure (une facture doit avoir un numéro, une date d'émission, un nom de vendeur, …).
• BR-CO-xx — règles de calcul et de cohérence, par exemple que le total de la facture est égal à la somme des montants nets de lignes plus les frais moins les remises.
• BR-S-, BR-Z-, BR-E-, BR-AE-, BR-IC-, BR-G-, BR-O-, BR-IG-, BR-IP- — règles par catégorie de TVA : taux normal, taux zéro, exonéré, autoliquidation, intracommunautaire, exportation, hors champ, et les taxes des Canaries et de Ceuta/Melilla.
• BR-CL-xx — règles de listes de codes (codes devise, codes unité, codes de catégorie de TVA, codes pays).

Les spécifications nationales superposent leurs propres jeux de règles : la KoSIT publie un Schematron XRechnung et un validateur configurable, et OpenPeppol publie les règles Peppol. Un fichier doit donc franchir jusqu'à trois couches — schéma, noyau EN 16931, CIUS national — et chaque couche signale ses propres identifiants. Le vérificateur de factures électroniques gratuit passe un fichier par les règles du pays choisi sans le stocker.

Versions : 2017, A1:2019 et l'édition 2026

L'édition en vigueur pendant l'essentiel de la dernière décennie est EN 16931-1:2017 avec son amendement A1:2019. Selon la Commission, une nouvelle édition, EN 16931-1:2026, a été publiée en mai 2026 ; l'édition 2017 a été formellement retirée mais reste conforme pendant une période de migration, et des plans de migration sont en cours d'élaboration par les organisations concernées et les autorités des États membres.

Ce que cela signifie aujourd'hui pour les implémenteurs : les customization ID en circulation référencent encore urn:cen.eu:en16931:2017, et les artefacts de validation, XRechnung et Peppol BIS continuent tous de fonctionner avec le modèle 2017. FeRD note que le profil EXTENDED de ZUGFeRD 2.5.2 porte déjà des éléments supplémentaires « pour la réforme française de la facturation électronique B2B et le modèle de données EN 16931 révisé ». Attendez-vous à ce que les spécifications nationales publient leurs propres dates de migration ; jusque-là, le modèle 2017 est celui contre lequel les récepteurs valident.

Comment KRONENWERK gère cela

KRONENWERK génère des factures EN 16931 dans la syntaxe et le CIUS attendus par le pays de l'acheteur, et les valide contre les couches de règles applicables avant l'émission de la facture.

• Allemagne — XRechnung (UBL ou CII) et ZUGFeRD, validés avec les règles Schematron de la KoSIT et contre-vérifiés avec la bibliothèque Mustang : PRIS EN CHARGE.
• France — Factur-X en PDF/A-3 avec CII intégré : génération PRIS EN CHARGE ; transmission via une plateforme agréée PAS ENCORE PRÊT.
• Belgique — Peppol BIS Billing 3.0 UBL : PRIS EN CHARGE AVEC LIMITATIONS, envoyé et reçu par l'intermédiaire d'un prestataire de point d'accès accrédité (Storecove) une fois l'entreprise connectée dans Paramètres → Envoi.
• Réception — les fichiers XRechnung, ZUGFeRD/Factur-X et UBL entrants sont lus en factures fournisseurs : PRIS EN CHARGE.

La catégorie de TVA sur chaque ligne et dans la ventilation de TVA provient du verdict fiscal de la facture (taux normal, taux zéro, exonéré, autoliquidation, hors champ), dérivé des faits de la transaction et jamais deviné ; lorsqu'un professionnel devrait trancher, la facture est retenue avec la mention « confirmation professionnelle requise ». Le FA(3) polonais est un schéma national hors EN 16931 et est traité sur la page FA(3). Les développeurs peuvent créer des brouillons via l'API de facturation électronique ; la présentation du produit se trouve sur la page facturation électronique. Retour au hub Europe.

Questions fréquentes

EN 16931 est-elle un format de fichier ?

Non. C'est un modèle sémantique — une liste de termes métier et de règles. Les formats de fichier sont les syntaxes qui le portent, UBL 2.1 et UN/CEFACT CII, et les spécifications construites dessus telles que XRechnung, ZUGFeRD, Factur-X et Peppol BIS.

Une facture ZUGFeRD est-elle conforme à EN 16931 ?

Les profils EN 16931 et EXTENDED portent le noyau complet ; BASIC est un sous-ensemble qui se valide contre les règles du noyau ; MINIMUM et BASIC WL portent moins que le noyau et ne sont pas des factures EN 16931 conformes à elles seules.

Quelle est la différence entre un CIUS et une extension ?

Un CIUS restreint le noyau (plus d'éléments obligatoires, listes de codes plus étroites) et reste valide pour tout récepteur EN 16931. Une extension ajoute des éléments et nécessite un récepteur qui les comprend.

Où obtenir les règles de validation ?

Les artefacts Schematron de la Commission pour UBL et CII sont publics sur GitHub (ConnectingEurope/eInvoicing-EN16931). La KoSIT publie les règles et le validateur XRechnung ; OpenPeppol publie les règles Peppol BIS.

Dois-je migrer vers EN 16931-1:2026 dès maintenant ?

Pas au 3 septembre 2026. La Commission indique que l'édition 2017 reste conforme pendant une période de migration et que les plans sont encore en cours d'élaboration. Suivez les annonces de la KoSIT, d'OpenPeppol, de FeRD/FNFE et de votre autorité nationale.