EN 16931 est la norme européenne qui définit ce qu’est une facture électronique. Elle décrit une liste de champs et un ensemble de règles de cohérence que toute facture doit respecter pour qu’une machine puisse la lire sans ambiguïté, d’un bout à l’autre de l’Europe.
C’est cette norme qui se cache derrière Factur-X, derrière Chorus Pro et derrière la réforme française de 2026. La comprendre une fois évite de se perdre dans le vocabulaire pendant des mois.
D’où elle vient
Le point de départ est la directive 2014/55/UE du 16 avril 2014, qui impose aux acheteurs publics européens de savoir recevoir et traiter des factures électroniques. Pour que ça fonctionne, encore fallait-il un vocabulaire commun. La Commission a donc mandaté le CEN (Comité Européen de Normalisation), qui a créé un comité technique dédié, le CEN/TC 434, pour produire cette langue commune.
Le résultat est publié en 2017 sous la référence EN 16931-1:2017, complétée depuis par un amendement de 2019 et par une série de documents techniques : la liste des syntaxes acceptées, les règles de traduction vers chacune, la méthodologie d’extension. Le cœur normatif, celui qui compte, reste la partie 1 : le modèle sémantique.
Les trois couches
EN 16931 s’empile en trois niveaux, et confondre deux niveaux est la source de 90 % des malentendus sur le sujet.
1. Le modèle sémantique
C’est la couche abstraite : « une facture contient un numéro, une date d’émission, un vendeur identifié, un acheteur identifié, des lignes, des totaux, une ventilation de TVA ». Chaque information porte un identifiant stable, le Business Term noté BT-xx, et les informations sont regroupées en Business Groups, notés BG-xx. Aucun format de fichier à ce stade.
2. Les syntaxes
La couche technique répond à une question : comment écrire ce modèle dans un fichier ? Deux syntaxes XML ont été retenues comme conformes :
- UBL 2.1 (Universal Business Language, normalisé ISO/IEC 19845), dominant en Europe du Nord et dans le réseau Peppol.
- UN/CEFACT CII (Cross Industry Invoice), celui sur lequel repose Factur-X, et donc la France et l’Allemagne.
Les deux expriment le même modèle. Une facture UBL et une facture CII portant les mêmes données sont sémantiquement identiques, même si elles ne se ressemblent pas du tout quand on ouvre le fichier.
3. Les profils : CIUS et extensions
La couche d’usage. Le modèle européen couvre large, et chaque pays comme chaque secteur en utilise un sous-ensemble. D’où deux mécanismes qu’il ne faut pas confondre :
- Un CIUS (Core Invoice Usage Specification) restreint le modèle. Il peut rendre obligatoire un champ que la norme laisse facultatif, ou limiter une liste de codes, sans rien ajouter. Une facture conforme à un CIUS est donc, par construction, conforme à EN 16931.
- Une extension ajoute des informations que le modèle de base ne prévoit pas : données logistiques, douanières ou sectorielles. La conformité au cœur de la norme n’est alors plus automatique.
Factur-X (France), ZUGFeRD (Allemagne), XRechnung (secteur public allemand) et les profils Chorus Pro sont tous des déclinaisons de ce mécanisme. La différence entre ces formats et les plateformes qui les transportent mérite un article à part entière, tant les deux notions se mélangent.
Les champs obligatoires, en français
Le modèle compte plus de 150 Business Terms, dont une minorité seulement est obligatoire. Ceux qui suivent reviennent sur toutes tes factures, avec leur code, utile le jour où une plateforme te renvoie une erreur en citant un numéro.
En-tête
| Code | Information |
|---|---|
BT-1 | Numéro de facture (unique, séquentiel) |
BT-2 | Date d’émission |
BT-3 | Code type de document (380 = facture, 381 = avoir) |
BT-5 | Devise de la facture (ISO 4217) |
BT-9 | Date d’échéance de paiement |
BT-24 | Identifiant de spécification (quel profil est utilisé) |
Parties
| Code | Information |
|---|---|
BT-27 | Nom légal du vendeur |
BT-31 | Numéro de TVA intracommunautaire du vendeur |
BG-5 | Adresse postale du vendeur |
BT-44 | Nom légal de l’acheteur |
BT-48 | Numéro de TVA intracommunautaire de l’acheteur |
Lignes et totaux
| Code | Information |
|---|---|
BT-153 | Désignation de l’article ou de la prestation |
BT-129 | Quantité facturée |
BT-146 | Prix unitaire net |
BT-131 | Montant net de la ligne |
BT-106 | Somme des montants nets de lignes |
BT-109 | Total facture hors TVA |
BT-110 | Montant total de TVA |
BT-112 | Total facture TTC |
BT-115 | Montant restant dû |
À quoi s’ajoute la ventilation de TVA (groupe BG-23) : pour chaque taux appliqué, la base imposable, le montant de TVA, le taux et le code catégorie. Ce dernier mérite une mention particulière parce qu’il piège beaucoup de freelances : S pour le taux standard, Z pour le taux zéro, E pour exonéré, AE pour l’autoliquidation, K pour l’intracommunautaire, G pour l’export. Un auto-entrepreneur en franchise de TVA n’est pas en Z mais en E, avec la mention légale correspondante.
Les règles métier
Avoir les bons champs ne suffit pas : encore faut-il qu’ils soient cohérents entre eux. C’est le rôle des règles métier, exprimées en Schematron et vérifiées automatiquement par les validateurs et les plateformes. Trois familles :
- BR-xx : les règles de présence. « Le numéro de facture est obligatoire. » Sèche, mais c’est là que la moitié des rejets se joue.
- BR-CO-xx : les règles de cohérence arithmétique. La somme des montants de lignes doit être égale au total HT ; le total TTC doit être égal au HT plus la TVA. Arrondir chaque ligne au centime puis additionner ne donne pas toujours le même résultat qu’additionner puis arrondir : c’est une source classique d’échec de validation.
- BR-CL-xx : les règles de listes de codes. La devise doit exister dans ISO 4217, le pays dans ISO 3166-1, le type de document dans la liste UNTDID 1001.
À quoi s’ajoutent des règles par catégorie de TVA (BR-S-, BR-E-, BR-AE-…) qui rejouent la même logique pour chaque cas. Le décompte exact varie selon qu’on compte le cœur de la norme ou l’ensemble des variantes par syntaxe. Retiens l’ordre de grandeur de plusieurs centaines de contrôles automatiques.
Les règles françaises
La France a ajouté ses propres contraintes, dans le cadre des travaux AFNOR sur le socle minimum. Elles reflètent des obligations du Code de commerce qui n’existent pas ailleurs en Europe. Les plus structurantes pour un freelance :
- Les mentions de paiement obligatoires : le taux des pénalités de retard, l’indemnité forfaitaire de recouvrement de 40 €, et la mention relative à l’escompte pour paiement anticipé. Ce ne sont pas des phrases libres en bas de page : ce sont des notes structurées, portant chacune un code, et leur absence fait échouer la validation.
- La cohérence SIRET / SIREN : les neuf premiers caractères du SIRET doivent correspondre au SIREN déclaré. Une coquille de saisie et la facture est rejetée.
- Le cadre de facturation : il faut déclarer si l’opération porte sur des biens, des services ou les deux. Un code erroné à cet endroit provoque un rejet côté plateforme avec un message assez peu explicite.
- La traduction des codes dans le rendu visuel : le code
380doit s’afficher « Facture » en toutes lettres sur le PDF lisible par l’humain.
Factur-X et ses profils
Factur-X est la déclinaison franco-allemande d’EN 16931. Sa particularité tient à son format hybride : un PDF/A-3 que ton client ouvre normalement, avec un fichier XML structuré embarqué à l’intérieur, que son logiciel lit automatiquement. Personne n’a besoin de changer ses habitudes, et la machine est servie.
La spécification définit cinq profils, du plus pauvre au plus riche :
| Profil | Contenu | Conforme EN 16931 ? |
|---|---|---|
| MINIMUM | En-tête et total seulement, aucune ligne | Non |
| BASIC WL | Totaux détaillés et paiement, sans les lignes | Non |
| BASIC | Ajoute les lignes de facture | Non |
| EN 16931 (ex-COMFORT) | Couvre l’intégralité du modèle sémantique | Oui |
| EXTENDED | EN 16931 + logistique, douane, remises complexes | Oui |
Un outil peut annoncer « factures Factur-X » en n’émettant que du profil MINIMUM, qui n’est pas conforme au cœur de la norme et ne passera pas les contrôles B2B durablement. Le profil à viser est EN 16931. Si ton logiciel ne dit pas lequel il produit, la question vaut d’être posée avant septembre 2027.
La spécification vit : la version 1.08 de Factur-X, alignée avec ZUGFeRD 2.4, est entrée en vigueur en janvier 2026. Vérifie la version supportée par ton outil plutôt que de supposer.
Vérifier une facture soi-même
Deux ressources publiques suffisent pour trancher un doute sans faire confiance à personne :
- Le validateur de la Commission européenne (Interoperability Test Bed) accepte un fichier UBL ou CII et le confronte aux schémas et règles Schematron officiels. Il renvoie la liste des règles violées avec leur code.
- Le dépôt ConnectingEurope/eInvoicing-EN16931 sur GitHub publie les fichiers Schematron source. C’est la référence dont dérivent la plupart des validateurs tiers.
Des validateurs communautaires et commerciaux existent aussi, parfois plus confortables à utiliser. Ils sont pratiques pour du dépannage, mais en cas de désaccord, c’est le validateur officiel qui fait foi.
Ce qu’il faut retenir
EN 16931 n’est pas un logiciel à installer ni un format à choisir : c’est le contrat commun qui rend les factures lisibles par les machines de toute l’Europe. Tu ne la manipuleras pas toi-même : ton outil de facturation s’en charge. Ce qui te concerne tient en trois points : tes données d’entreprise doivent être exactes (le SIRET surtout), ton code de TVA doit correspondre à ta situation réelle, et ton outil doit produire au minimum le profil EN 16931.
Le reste, ce sont des BT et des BR que tu ne verras que le jour où quelque chose casse. Au moins tu sauras lire le message d’erreur.
Si tu veux voir à quoi ça ressemble en pratique plutôt qu’en théorie, le pas-à-pas pour émettre une facture conforme prend le problème par l’autre bout.