— 2 mai 2026 · 11 min de lecture

PEPPOL BIS Billing 3.0 : décrypter EN 16931 sans douleur

EN 16931 n'est pas un format. C'est un modèle sémantique : la liste des informations qu'une facture électronique européenne doit porter. PEPPOL BIS Billing 3.0 en est l'une des implémentations syntaxiques, en UBL. Comprendre ce double étage est la première marche du dossier e-invoicing.

Un malentendu pédagogique qui dure

Le lecteur qui ouvre pour la première fois la documentation européenne sur la facture électronique fait souvent le même constat : les termes circulent de manière confuse. EN 16931, PEPPOL BIS, UBL, CII, Factur-X, XRechnung, ZUGFeRD… la liste s'allonge, et chacun de ces noms paraît désigner « à peu près la même chose ». Le réflexe consiste alors à parler de « format européen » sans préciser de quoi il retourne — ce qui finit par produire des cahiers des charges où l'éditeur se retrouve incapable de répondre à la question pourtant simple : « quel fichier doit-on produire ? »

Le malentendu vient d'une confusion entre deux niveaux. EN 16931 est un modèle sémantique — une liste structurée de champs métier qu'une facture doit porter pour être valide en Europe. Ce modèle ne dit rien du format dans lequel les champs sont sérialisés. PEPPOL BIS Billing 3.0 et UBL 2.1, à l'inverse, sont des choix syntaxiques : ils décident comment les champs du modèle sont écrits dans un fichier XML. Le lecteur trouvera la généalogie complète sur la page PEPPOL chez ediverse, mais le résumé tient en trois lignes.

EN 16931, le modèle sémantique

Publiée par le CEN (Comité européen de normalisation), EN 16931 est issue de la Directive 2014/55/UE sur la facturation électronique dans les marchés publics. Le texte normatif définit deux artefacts. D'une part une liste de business terms — souvent abrégés « BT- », numérotés de BT-1 à BT-200 et au-delà — qui décrivent chaque information utile : numéro de facture (BT-1), date de facture (BT-2), code de type de facture (BT-3), code de devise (BT-5), TVA totale (BT-110), montant TTC (BT-112), et ainsi de suite jusqu'aux notions plus fines comme l'identifiant de la commande de référence (BT-13) ou le motif de remise sur ligne (BT-139).

D'autre part, une liste de business rules — les « BR- » — qui contraignent les business terms : BR-01 impose la présence d'un identifiant de facture, BR-02 impose une date, BR-CO-10 vérifie la cohérence des montants TVA avec les lignes… et ainsi de suite sur près de cent cinquante règles. Le rôle de ces règles est de garantir qu'une facture déclarée conforme est non seulement bien remplie, mais aussi arithmétiquement cohérente. Un total qui ne tombe pas juste, une devise qui contredit le pays de l'émetteur, une ligne sans prix unitaire : chacune de ces situations fait échouer une règle, et la facture est rejetée à la frontière du réseau.

EN 16931 reste à dessein syntaxe-indépendante. Le texte ne dit pas comment écrire BT-1 dans un fichier. Il dit simplement : BT-1 doit être présent, c'est une chaîne, c'est l'identifiant unique de la facture. Le choix d'écrire ce champ <cbc:ID>FA-2026-0001</cbc:ID> ou BGM+380+FA-2026-0001 est laissé à la couche en-dessous.

UBL 2.1, la syntaxe

UBL — Universal Business Language — est une famille de schémas XML publiée par OASIS et ratifiée comme standard OASIS Open en 2013. La version 2.1 couvre 65 documents métier (commande, accusé, bon de livraison, facture, avoir, instruction de paiement, etc.). Le document qui intéresse l'e-invoicing européen est évidemment Invoice, et son cousin CreditNote pour les avoirs.

Le binding UBL d'EN 16931 consiste à mapper chaque business term à un chemin XML UBL. BT-1 devient /Invoice/cbc:ID, BT-2 devient /Invoice/cbc:IssueDate, BT-5 devient /Invoice/cbc:DocumentCurrencyCode, et ainsi de suite. Le document EN 16931 Mapping UBL, publié par le CEN/TC 434, donne le tableau complet de correspondance. Toute la subtilité tient dans les cardinalités : certains BT sont obligatoires, d'autres ne sont autorisés que si un autre BT est rempli, d'autres encore admettent plusieurs occurrences.

Un développeur qui travaille déjà sur ORDERS en EDIFACT (cf. la fiche ORDERS D.96A) retrouvera une familiarité conceptuelle frappante : les notions de qualifier (qualifier de partie, de date, d'identifiant) reviennent, simplement renommées en UBL. L'identifiant de la partie acheteuse, par exemple, porte un schemeID au lieu d'un qualifier dans le composite C082, mais l'idée est identique : dire à la machine ce que représente la chaîne qu'on lui donne.

PEPPOL BIS Billing 3.0, les règles métier

PEPPOL — Pan-European Public Procurement Online — est un réseau d'échange piloté par OpenPeppol AISBL. Le réseau définit des Business Interoperability Specifications, ou BIS, qui sont des profils d'usage : un BIS dit « voici comment, sur le réseau PEPPOL, on envoie ce type de message ». BIS Billing 3.0 est le profil facture, et son contenu se laisse résumer en quatre couches :

• il impose la syntaxe UBL 2.1 (pas de CII en BIS Billing 3.0 ; CII a son propre BIS dans d'autres contextes) ;
• il restreint le modèle d'EN 16931 — certains BT optionnels au niveau européen deviennent obligatoires pour le profil ;
• il ajoute des règles métier propres au réseau PEPPOL — préfixées BR-NN- dans le Schematron : par exemple, le BR-NN-001 impose la présence d'un endpoint PEPPOL sur la facture ;
• il publie des artefacts de validation — un Schematron pour les règles PEPPOL, un autre pour les règles TC434 (les règles européennes pures), des exemples XML, une feuille de style XSLT pour rendu humain.

Le tout est documenté à l'adresse docs.peppol.eu/poacc/billing/3.0/ et archivé chez ediverse au titre des sources primaires. La page-index de la spécification liste explicitement quinze sous-listes de codes : ISO 6523 ICD, Electronic Address Scheme, codes pays ISO 3166-1, devises ISO 4217, codes Rec 20 (unités de mesure) avec Rec 21 (emballages) préfixées X, codes de catégorie de taxe extraits d'UNCL5305, codes de type de facture UNCL1001, codes de moyens de paiement UNCL4461, codes de motif de remise UNCL5189, codes de motif de charge UNCL7161, codes MIME, indicateur SEPA, et la liste VATEX. Cet écosystème de code lists est ce qui transforme un document UBL générique en une facture européenne reconnaissable.

Les sous-règles nationales (BR-FR, BR-DE, BR-IT)

Aux trois étages précédents (UBL, EN 16931, PEPPOL BIS Billing) chaque pays peut, et souvent doit, ajouter un quatrième étage de règles. Les CIUS — Core Invoice Usage Specifications — sont des restrictions de profil : l'Italie, par exemple, exige une identification fiscale supplémentaire pour le SdI, et l'Allemagne, à travers XRechnung, impose un identifiant Leitweg-ID dans les marchés publics fédéraux.

Les notations BR-FR-, BR-DE-, BR-IT- qu'on rencontre dans les Schematron nationaux désignent ces règles ajoutées. Elles ne contredisent jamais les règles européennes : elles les durcissent, ou contraignent un détail laissé libre par EN 16931. Un éditeur qui veut être conforme dans plusieurs pays doit donc empiler les Schematron — PEPPOL BIS Billing 3.0 + le profil national, ce dernier étant souvent identique à un CIUS publié par l'organisme local (l'AGID en Italie, l'AIFE en France, la KoSIT en Allemagne).

Le piège pratique est connu : une facture valide en PEPPOL BIS générique peut être rejetée par le SdI italien parce qu'elle n'a pas le bon Codice Destinatario. Le développeur français ne peut donc pas se contenter du Schematron OpenPeppol. Il doit embarquer le Schematron de chaque pays cible.

Un exemple lu business term par business term

Voici, pour ancrer le tout, ce que devient une facture minimale lue à la verticale. Un émetteur français qui facture un client belge pour deux articles à 250 € HT chacun, TVA 20 % applicable, écrit en BIS Billing 3.0 une grappe XML dont les éléments-clés portent les business terms suivants :

• BT-1 — l'identifiant FA-2026-0142, dans cbc:ID au niveau racine ;
• BT-2 — la date d'émission 2026-05-02, dans cbc:IssueDate ;
• BT-3 — le code de type 380 (facture commerciale, extrait de UNCL1001), dans cbc:InvoiceTypeCode ;
• BT-5 — la devise EUR, dans cbc:DocumentCurrencyCode ;
• BT-27, BT-44 — les noms commerciaux du vendeur et de l'acheteur ;
• BT-31, BT-48 — les numéros de TVA intracommunautaire (avec schemeID="VAT") ;
• deux lignes cac:InvoiceLine portant chacune BT-126 (identifiant de ligne), BT-129 (quantité 1), BT-131 (montant net de ligne 250.00), BT-146 (prix unitaire net) ;
• une grappe cac:TaxTotal portant BT-110 (montant TVA 100.00) et un cac:TaxSubtotal avec BT-117 (TVA catégorie S, taux 20) ;
• une grappe cac:LegalMonetaryTotal portant BT-106 (somme nette des lignes 500.00), BT-109 (montant hors taxes 500.00), BT-112 (montant à payer TTC 600.00).

Le BR-CO-10 vérifie ensuite, sur cette facture, que BT-112 vaut bien BT-109 + BT-110. Si le rédacteur a calculé un total à 601 €, le Schematron lève une erreur, et l'access point PEPPOL refuse la facture. Cette logique d'arithmétique vérifiable, parfois pénible à l'intégration, est la principale différence avec le monde EDIFACT : là où ORDERS et INVOIC se contentent d'un comptage de lignes en CNT, EN 16931 impose une cohérence totale entre les sommes déclarées.

Le réseau PEPPOL, le transport, la signature

Une fois la facture conforme à BIS Billing 3.0, elle voyage : PEPPOL définit un modèle à quatre coins. Côté émetteur, un Access Point Provider (Corner 1) reçoit la facture de l'application métier (Corner C1). Le Corner 2 est l'access point de l'expéditeur, qui dépose le message dans le réseau via le protocole AS4 PEPPOL eDelivery (basé sur OASIS ebMS 3.0). Le message est routé à l'access point du destinataire (Corner 3) qui le livre à l'application métier du destinataire (Corner C4). Le Service Metadata Locator (SML) et le Service Metadata Publisher (SMP) permettent de résoudre l'identifiant de destination (souvent un numéro de TVA, parfois un GLN ICD 0088) en URL d'access point.

Concrètement, l'émetteur qui passe par PEPPOL ne s'occupe pas du transport : il envoie à son access point — Stedi, Pagero, Ibanity, B2Brouter et une centaine d'autres sont certifiés — et le réseau s'occupe du routage. La signature et le chiffrement sont gérés au niveau du tunnel AS4 par les certificats PEPPOL, non au niveau du XML lui-même. C'est une différence importante avec l'écosystème historique du XAdES, où la facture portait sa propre signature détachée.

Ce qu'il faut coder, en pratique

Pour un éditeur qui prépare son module de facturation, le plan technique se résume en quatre briques. Une brique de sérialisation qui produit l'XML UBL à partir du modèle métier interne — souvent un mapping à la main, parce que les bibliothèques UBL génériques mappent mal les cardinalités EN 16931. Une brique de validation à deux passes XSD + Schematron, exécutée avant envoi : il vaut mieux refuser localement une facture invalide que d'attendre le rejet du réseau. Une brique de transport AS4, en général déléguée à l'access point — peu d'éditeurs gèrent le tunnel AS4 PEPPOL en propre, car la certification et la maintenance du certificat ont un coût récurrent significatif. Et enfin une brique d'archivage légal : la facture doit pouvoir être restituée dans son XML original pendant la durée légale de conservation, dix ans en France pour les pièces commerciales.

Pour valider sa première facture, le lecteur peut utiliser n'importe quel validateur PEPPOL en ligne — OpenPeppol publie un validateur officiel — ou auto-héberger les Schematron via Saxon. La page validateur EDIFACT chez ediverse couvre la famille EDIFACT ; un validateur UBL/PEPPOL équivalent est en cours de cadrage côté ediverse pour la suite V1.5.

L'étage qui n'existait pas il y a dix ans

Le saut le plus subtil dans tout l'édifice EN 16931 / PEPPOL BIS, c'est l'existence même d'un étage sémantique séparé du format. Là où EDIFACT confondait, depuis 1986, le modèle métier et le format à la ligne, EN 16931 sépare nettement les deux. Cela rend possible une chose qui n'existait pas avant : changer la syntaxe — passer d'UBL à CII, par exemple, dans un Factur-X — sans changer la facture, ni les règles, ni les contrôles. La facture devient un objet conceptuel, indépendant du fichier qui la porte.

Pour qui doit livrer un module de facturation européen en 2026, c'est une bonne nouvelle : le travail d'implémentation se déplace de la sérialisation vers la validation. Et la validation, elle, est testable par contrats — Schematron est un format explicite, versionné, public. À l'inverse, les surprises viendront moins du XML que des sous-règles locales (BR-FR, BR-DE…) qui changent au fil des décrets. C'est là, et plus dans la grammaire UBL, que le diable se cache.