EN 16931 — le modèle sémantique européen de la facture

Ce que normalise réellement EN 16931, comment une même facture se projette sur UBL et CII, comment sont organisées les règles de gestion, et pourquoi la conformité au schéma n’est pas la conformité à la norme.

Un modèle, pas un format

EN 16931-1 définit le modèle sémantique de données d’une facture électronique : la liste des termes métier qu’une facture peut ou doit contenir, la signification de chacun, le nombre d’occurrences autorisé et les règles qui les relient. Elle ne définit pas de format XML.

Le format provient d’une transposition syntaxique. EN 16931-3 transpose le modèle dans deux syntaxes : UBL 2.1 de l’OASIS et CII de l’UN/CEFACT. La transposition indique quel élément de chaque syntaxe porte quel terme métier. C’est pourquoi une facture peut passer d’une syntaxe à l’autre sans perte à l’intérieur du modèle noyau : le modèle est le même, seule la sérialisation diffère.

Les termes métier

Chaque champ du modèle possède un identifiant. Le préfixe BT- désigne un terme métier — une valeur terminale — et BG- un groupe métier, c’est-à-dire une structure qui en contient d’autres.

BT-1 — numéro de facture.
BT-2 — date d’émission de la facture.
BT-3 — code de type de facture.
BT-5 — code devise de la facture.
BT-9 — date d’échéance du paiement.
BT-24 — identifiant de spécification, c’est-à-dire le CIUS ou le profil déclaré.
BG-4 / BG-7 — le vendeur et l’acheteur.
BG-25 — une ligne de facture.
BG-23 — une entrée de ventilation de TVA.
BT-112 / BT-115 — total TTC et montant dû.

Ce sont ces identifiants que citent les anomalies de validation, et c’est pourquoi un rapport qui se contente de dire « non conforme » n’aide en rien : l’information utile est quel terme métier et quelle règle.

La même facture dans deux syntaxes

Quelques termes métier, et l’endroit où chaque syntaxe les place :

BT-1 numéro de facture — UBL cbc:ID ; CII rsm:ExchangedDocument/ram:ID.
BT-2 date d’émission — UBL cbc:IssueDate, date ISO ; CII ram:IssueDateTime/udt:DateTimeString avec un qualifiant de format.
BT-9 date d’échéance — UBL cbc:DueDate sur le document ; CII ram:SpecifiedTradePaymentTerms/ram:DueDateDateTime, sur les conditions de paiement.
BT-31 numéro de TVA du vendeur — UBL cac:PartyTaxScheme/cbc:CompanyID avec un régime de taxe VAT imbriqué ; CII ram:SpecifiedTaxRegistration/ram:ID avec schemeID="VA".
BT-115 montant dû — UBL cac:LegalMonetaryTotal/cbc:PayableAmount ; CII ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:DuePayableAmount.

Même signification, structure sensiblement différente. C’est pourquoi les visualiseurs de ce site projettent les deux syntaxes sur un modèle commun pour les champs réellement partagés, tout en laissant visible l’organisation propre à chaque syntaxe dans les données analysées.

Comment les règles sont organisées

Les règles de gestion sont publiées sous forme de Schematron et regroupées selon ce qu’elles vérifient. Le préfixe indique le type d’anomalie :

BR-* — présence et cardinalité. « Une facture doit comporter un numéro de facture. » Une anomalie signifie qu’un élément est absent, ou répété alors qu’il ne devrait pas l’être.
BR-CO-* — conditions et calculs. « La somme des montants nets de lignes doit être égale au total des montants nets de lignes. » Ce sont les règles arithmétiques, et c’est là que les factures réelles échouent le plus souvent.
BR-CL-* — listes de codes. « Le code de catégorie de TVA doit provenir de la liste UNTDID 5305. » Une anomalie signifie que la valeur ne figure pas dans la liste exigée.
BR-S-*, BR-Z-*, BR-E-*, BR-AE-*… — règles propres à chaque catégorie de TVA : taux normal, taux zéro, exonération, autoliquidation, et ainsi de suite.

CIUS et Extension

Un CIUS — Core Invoice Usage Specification — restreint EN 16931 pour un pays ou un secteur. Il peut rendre obligatoire un terme facultatif ou réduire une liste de codes, mais il ne peut ni ajouter de termes hors du modèle noyau ni assouplir une règle. Peppol BIS Billing 3.0, la XRechnung allemande et la NLCIUS néerlandaise sont des CIUS.

Une Extension peut aller plus loin et ajouter de l’information au-delà du modèle noyau. Le profil EXTENDED de Factur-X en est un exemple.

Le profil applicable est déclaré dans BT-24, l’identifiant de spécification : le cbc:CustomizationID d’UBL ou l’identifiant de guide de CII. C’est une déclaration de l’émetteur. La vérifier suppose d’exécuter le jeu de règles correspondant.

Pourquoi la validation doit être organisée en couches

Valider une facture n’est pas une opération unique. Il y en a au moins cinq :

Bonne formation — s’agit-il seulement de XML analysable ?
Détection de la syntaxe — est-ce de l’UBL, du CII, ou autre chose ?
Schéma XML — la structure et les types de données sont-ils corrects pour cette syntaxe et cette version ?
Règles de gestion EN 16931 — les règles sémantiques et arithmétiques sont-elles respectées ?
Règles nationales et de profil — le document satisfait-il le CIUS ou le jeu de règles national qu’il déclare ?

Un document peut satisfaire tous les contrôles de schéma et enfreindre une douzaine de règles de gestion, parce que le schéma XML ne peut pas exprimer « ces montants doivent s’additionner ». Rendre un verdict unique masque la couche en cause, qui est pourtant la seule information utile pour corriger. Il importe également qu’une couche non exécutée soit signalée comme non exécutée plutôt que conforme : les outils de ce site sont explicites sur les couches qui se sont réellement exécutées.

Essayer

Voyez le modèle résolu à partir d’un document réel dans le visualiseur UBL ou le visualiseur CII.

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 assortis de définitions, de cardinalités et de règles. Le format provient d’une transposition syntaxique — UBL 2.1 ou UN/CEFACT CII — qui indique quel élément XML porte chaque terme métier. Deux fichiers dans des syntaxes différentes peuvent exprimer exactement la même facture EN 16931.

Qu’est-ce qu’un CIUS ?

Une Core Invoice Usage Specification : un profil national ou sectoriel qui restreint EN 16931 sans la contredire. Il peut rendre obligatoire un champ facultatif ou réduire une liste de codes, mais il ne peut pas ajouter de champs hors du modèle ni assouplir une règle. Peppol BIS Billing 3.0, XRechnung et NLCIUS sont des CIUS. Une Extension, à l’inverse, peut ajouter des données au-delà du noyau.

Que signifient les identifiants de règles BR, BR-CO et BR-CL ?

Les règles BR sont des règles de gestion élémentaires portant sur la présence et la cardinalité : un champ qui doit exister. Les règles BR-CO portent sur des conditions et des calculs, par exemple la relation entre la somme des montants de lignes et le total du document. Les règles BR-CL vérifient qu’une valeur codée appartient à la liste de codes exigée par la norme. Échouer à une règle BR-CL signifie que le code ne figure pas dans la liste, non que le champ est absent.

Un document peut-il être conforme au schéma et non conforme à la norme ?

Couramment. Le schéma XML contrôle la structure et les types de données ; il ne peut pas exprimer « la somme des montants de lignes doit être égale au total des lignes ». Ce sont les règles de gestion, exécutées séparément sous forme de Schematron. C’est précisément pour cela que la validation est présentée ici en couches plutôt que sous forme d’un verdict unique.