← Back to all articles

Comprendre EN16931 : le modèle de données de facturation européen

SealDoc Team · · 8 min read

EN16931 est la norme européenne qui définit ce qu’une facture électronique doit contenir. Ce n’est pas un format XML. C’est un modèle de données sémantique. Chaque grand format européen de facturation électronique, que ce soit Peppol BIS Billing 3.0, Factur-X, ZUGFeRD ou XRechnung, est une implémentation d’EN16931 dans une syntaxe XML spécifique.

Comprendre EN16931 fait gagner du temps lors du débogage d’erreurs de validation, de l’explication des exigences d’intégration aux éditeurs ERP, ou de l’implémentation d’un nouveau profil de facturation à partir de zéro.

Ce que spécifie réellement EN16931

EN16931 se compose de deux parties :

  • EN 16931-1 définit le modèle de données sémantique : quels éléments de données une facture peut contenir, lesquels sont obligatoires et quelles sont les règles métier
  • EN 16931-2 définit les liaisons syntaxiques : comment le modèle sémantique se mappe sur le XML UBL 2.1 et le XML CII UN/CEFACT

Il en résulte qu’une facture UBL Peppol BIS Billing 3.0 et une facture CII Factur-X peuvent représenter la même facture commerciale. Le contenu sémantique est identique. La syntaxe XML est complètement différente.

Termes métier et groupes métier

EN16931 organise les données de facturation en groupes métier (BG) et termes métier (BT).

Un groupe métier est un ensemble de termes liés. Un terme métier est un élément de données unique avec un identifiant défini, un nom, une cardinalité et un type de données.

Les groupes les plus importants au niveau supérieur :

GroupeContenu
BG-2 Contrôle de processusIdentifiant de spécification (BT-24), type de processus métier (BT-23)
BG-4 VendeurNom, adresse, numéro TVA, immatriculation légale
BG-7 AcheteurNom, adresse, identifiant de référence, adresse électronique
BG-22 Totaux du documentBase d’imposition, total de la facture, montant TVA, montant dû
BG-25 Ligne de factureQuantité, prix unitaire, taux TVA, montant net de ligne

Le modèle complet couvre plus de 150 BT répartis dans tous les groupes. La plupart des implémentations n’en utilisent qu’un sous-ensemble, mais valider un document exige de savoir quels BT sont obligatoires pour le profil cible.

Termes métier sur lesquels les développeurs butent

La plupart des erreurs de validation proviennent d’un petit ensemble de BT mal compris ou mal documentés dans les guides d’implémentation.

BT-24 : Identifiant de spécification

Il doit s’agir d’un URI spécifique identifiant le profil auquel la facture se déclare conforme. Pour Peppol BIS Billing 3.0 :

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1

Une erreur ici amène le validateur du destinataire à rejeter la facture avant même de vérifier le contenu des champs. Chaque profil (base EN16931, Peppol BIS 3.0, Peppol BIS 3.0 avec extension nationale) possède un URI différent.

BT-10 : Référence acheteur

Utilisé différemment selon les pays. En Allemagne, il porte le Leitweg-ID, un identifiant de routage obligatoire pour les factures B2G. Dans la plupart des autres pays, il s’agit d’une référence de bon de commande interne ou est laissé vide. Le champ est facultatif dans la base EN16931 mais obligatoire dans le profil national allemand.

BT-49 : Adresse électronique de l’acheteur

L’identifiant Peppol du participant acheteur. Format : scheme:identifier. Pour une entreprise belge identifiée par son numéro d’entreprise :

<cbc:EndpointID schemeID="0208">0468863455</cbc:EndpointID>

Obligatoire lors de la transmission sur le réseau Peppol. De nombreuses implémentations l’omettent pour les factures B2B hors Peppol, ce qui est acceptable dans la base EN16931 mais invalide dans les profils Peppol BIS.

BT-131 : Montant net de la ligne de facture

Le montant net pour une seule ligne, calculé comme la quantité multipliée par le prix unitaire moins les remises au niveau de la ligne. La règle métier BR-CO-10 d’EN16931 exige que la somme de toutes les valeurs BT-131 soit égale à BT-106 (somme des montants nets des lignes de facture).

L’arrondi est important ici. La norme attend que les calculs arithmétiques soient effectués sur des valeurs brutes et arrondis au niveau agrégé, et non par ligne. Arrondir chaque ligne indépendamment puis additionner produit des divergences qui font échouer BR-CO-10 pour de grandes quantités.

BT-110 : Montant de TVA par catégorie

Le montant de TVA par catégorie fiscale. La règle BR-CO-15 d’EN16931 exige que le total de la facture moins la base d’imposition soit égal à la somme de tous les BT-117 (montants de TVA par catégorie). Les erreurs ici sont souvent causées par l’arithmétique en virgule flottante ou un arrondi prématuré.

Règles métier : la couche de validation

Les règles métier (BR) sont des contraintes formelles exprimées en Schematron. Il en existe deux catégories.

Règles structurelles imposant la présence et le format des champs :

BR-01: An Invoice shall have a Specification identifier (BT-24).
BR-02: An Invoice shall have an Invoice number (BT-1).
BR-04: An Invoice shall have an Invoice currency code (BT-5).

Règles de calcul imposant la cohérence arithmétique :

BR-CO-10: Sum of Invoice line net amount (BT-106) = sum of all BT-131 values.
BR-CO-15: Invoice total VAT amount (BT-110) = sum of all BT-117 values.
BR-CO-16: Amount due for payment (BT-115) = Invoice total with VAT (BT-112)
          - Paid amount (BT-113) + Rounding amount (BT-114).

Peppol BIS 3.0 ajoute des règles d’extension nationale au-delà des règles de base EN16931. Exemples :

BR-DE-TMP-32: Delivery date (BT-72) is required for German B2G invoices.
BR-DE-18:     VAT identifier of the seller (BT-31) or tax registration (BT-32)
              shall be present.

Ces règles d’extension varient selon le profil national et sont publiées à chaque version de Peppol BIS.

Comment EN16931 se mappe sur UBL et CII

Les deux syntaxes XML traitent les mêmes BT mais utilisent des noms d’éléments et des structures complètement différents. C’est pourquoi le code qui analyse les factures UBL ne peut pas analyser les factures CII sans une implémentation distincte, même si les deux sont conformes à EN16931.

Le nom du vendeur (BT-27) dans les deux syntaxes :

UBL 2.1 :

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyName>
      <cbc:Name>Acme GmbH</cbc:Name>
    </cac:PartyName>
  </cac:Party>
</cac:AccountingSupplierParty>

UN/CEFACT CII :

<ram:SellerTradeParty>
  <ram:Name>Acme GmbH</ram:Name>
</ram:SellerTradeParty>

Les deux correspondent à BT-27. Le contenu sémantique est identique. Le chemin XML diffère complètement.

Peppol BIS 3.0 utilise UBL. Factur-X et ZUGFeRD utilisent CII. XRechnung prend en charge les deux. Le document de mappage EN16931-2 (disponible gratuitement auprès de CEN/TC 434) liste les deux chemins pour chaque BT et vaut la peine d’être gardé ouvert lors de l’implémentation.

Validation Schematron

La validation EN16931 est implémentée sous forme de règles Schematron précompilées en XSLT 2.0. Les ensembles de règles officiels sont publiés à chaque version de Peppol BIS :

github.com/OpenPEPPOL/peppol-bis-invoice-3/releases

Les artefacts contiennent des fichiers XSLT compilés :

peppol-en16931-ubl.xsl    (for UBL invoices)
peppol-en16931-cii.xsl    (for CII invoices)

L’exécution de l’un ou l’autre contre une facture retourne du SVRL (Schematron Validation Report Language). Une règle échouée ressemble à :

<svrl:failed-assert test="..." location="/Invoice/...">
  <svrl:text>
    [BR-CO-10]-Sum of Invoice line net amount (BT-106) = 
    sum of Invoice line net amount (BT-131).
  </svrl:text>
</svrl:failed-assert>

Un processeur XSLT 2.0 est requis. En .NET, Saxon HE (open source, sans licence enterprise) est le choix standard. En Java, Saxon ou Xerces fonctionnent tous les deux.

Erreurs d’implémentation courantes

Mélanger les chemins d’éléments UBL et CII. Les développeurs travaillant avec les deux formats copient des noms d’éléments du mauvais binding. Le document de mappage EN16931-2 évite cette erreur.

Supposer que les règles de présence sont identiques entre les profils. Un champ facultatif dans la base EN16931 peut être obligatoire dans Peppol BIS 3.0 ou dans une extension nationale. Valider par rapport au profil cible, et non par rapport à la norme de base.

Arrondir au mauvais niveau. Calculer les totaux arithmétiques bruts sur toutes les lignes, puis arrondir l’agrégat. Arrondir chaque ligne indépendamment et additionner les valeurs arrondies produit des incohérences arithmétiques qui font échouer BR-CO-10, souvent de quelques centimes sur de grandes factures comportant de nombreuses lignes.

BT-24 incorrect pour le profil cible. Chaque profil possède un URI d’identifiant de spécification spécifique. Utiliser l’URI de base EN16931 sur une facture Peppol BIS 3.0 entraîne un rejet immédiat au niveau du profil.

Coder en dur les codes de catégorie TVA. EN16931 définit des valeurs de code spécifiques pour les catégories TVA (S, Z, E, AE, K, G, O, L, M). De nombreuses implémentations codent en dur « S » (taux standard) et se brisent lors du traitement de factures en autoliquidation ou à taux zéro.

EN16931 est une connaissance infrastructurelle

EN16931 sous-tend chaque mandat de facturation électronique européen. Au fur et à mesure que les exigences se déploient en Belgique, en France, en Allemagne et en Pologne, la compréhension du modèle sémantique devient de plus en plus importante pour les développeurs qui construisent ou maintiennent des pipelines de facturation.

Comprendre la structure BT/BG, les règles de calcul et les liaisons syntaxiques vous permet de déboguer des erreurs de validation qui nécessiteraient autrement des heures de lecture de spécifications, d’implémenter de nouveaux profils proprement et de communiquer clairement avec les éditeurs ERP et les équipes de conformité.

Le problème pratique n’est pas d’apprendre EN16931 une fois. C’est de maintenir les implémentations correctes à mesure que les ensembles de règles sont mis à jour à chaque version de Peppol BIS, que les extensions nationales ajoutent de nouveaux champs obligatoires et que les cas limites d’arrondi apparaissent en production avec les données de facturation réelles des systèmes ERP réels.

SealDoc est livré avec des ensembles de règles qui suivent les versions de Peppol BIS. Lorsque vous générez une facture via l’API SealDoc, le document est validé par rapport au profil correct avant de quitter le système. BR-CO-10 et BR-CO-15 sont appliqués côté serveur afin que les erreurs d’arrondi n’atteignent pas vos acheteurs. Lorsque vous recevez une erreur de validation d’un partenaire commercial, le validateur public SealDoc accepte le document et associe chaque échec au BT et au BR spécifique violés, réduisant le temps de diagnostic de quelques heures à quelques minutes.

Si vous implémentez EN16931 à partir de zéro, le validateur est un outil de calibration utile : générer un document candidat, l’exécuter, corriger ce que le rapport identifie, recommencer.

← Back to all articles