Comprendre les règles BR-* de la norme EN 16931

Quand un fichier Factur-X est rejete par un validateur, le message d'erreur prend toujours la forme d'un code comme [BR-08] ou [BR-CO-15]. Ces codes ne sortent pas de nulle part : ils viennent du Schematron officiel de la norme EN 16931-1:2017+A1:2019, qui formalise les contraintes metier de la facture électronique européenne.

Comprendre les quatre familles BR-* permet de lire un rapport de validation sans dictionnaire, et surtout de corriger la source du problème plutot que de retenter au hasard. Cet article les passe en revue, avec leur rôle respectif et la manière dont notre validateur les expose.

Les 4 familles de règles

La norme EN 16931 publie son corpus de règles sous forme de fichiers Schematron (XSLT applique au XML CII ou UBL). Chaque règle porte un identifiant stable, classe par prefixe. Sur l'ensemble des profils Factur-X, on recense environ 80 règles actives, reparties ainsi :

S'y ajoutent des règles spécifiques au CIUS FR (prefixe FR-CO-) et a l'extension EXTENDED (BR-EX-), qui ne sont pas detaillees ici. Le présent article se concentre sur le socle commun, applicable a tous les profils a partir de BASIC WL.

BR-* : champ obligatoire

La famille BR- nue (sans suffixe additionnel) vérifié qu'un champ cardinal est présent et non vide. C'est la règle la plus simple a interpreter : si elle saute, c'est qu'une donnee de la facture manque a l'appel.

Quelques règles representatives :

• BR-01 : la facture doit porter une specification identifier (BT-24), c'est-a-dire l'URN de profil Factur-X.
• BR-02 : un numéro de facture (BT-1) est requis.
• BR-03 : une date d'émission (BT-2) est requise.
• BR-04 : un type de document (BT-3, code UNCL1001) doit être présent.
• BR-08 : l'identité du vendeur (BG-4) est obligatoire.
• BR-21 : chaque ligne de facture (BG-25) doit avoir un identifiant de ligne (BT-126).

Une règle BR- echouee signifie quasi toujours qu'un émetteur a saute un champ pourtant requis dans la base term list. Le profil MINIMUM, qui n'active qu'une quinzaine de ces règles, reste le bon point d'entree pour comprendre lesquelles sont incontournables avant d'ajouter de la complexite.

BR-CO-* : coherence calculatoire

Les règles BR-CO- verifient que les totaux declares correspondent a la somme des éléments détaillés. Elles sont au coeur de la fiabilite comptable d'une facture électronique : sans elles, rien n'empeche un émetteur d'envoyer un total HT incoherent avec ses lignes.

Exemples :

• BR-CO-10 : la somme des montants nets des lignes (BT-106) doit egaler la somme arithmetique des BT-131 de chaque ligne.
• BR-CO-11 : le total des charges au niveau document (BT-108) doit egaler la somme des montants de charges declares.
• BR-CO-13 : le total HT (BT-109) doit vérifier la formule : somme lignes nettes + charges document - remises document.
• BR-CO-15 : le total TTC (BT-112) doit egaler le total HT plus le total TVA (BT-110).
• BR-CO-16 : le montant restant du (BT-115) doit egaler le total TTC moins les paiements anticipes (BT-113) et plus l'arrondi (BT-114).

Quand une règle BR-CO- déclenché, le rapport indique en general les valeurs attendue et trouvee. Le diagnostic est rapide : soit un arrondi est mal applique en amont, soit une ligne a ete ajoutee/retiree sans recalculer les totaux.

BR-DEC-* : précision decimale

La famille BR-DEC- contraint le nombre maximal de decimales sur les montants. La norme distingue deux niveaux selon le champ :

• 2 decimales maximum sur les totaux comptables et la majorite des montants de ligne (prix unitaire net pouvant aller jusqu'a 4 sous conditions).
• 4 decimales maximum sur les quantites et les pourcentages (taux de TVA, taux de remise).

Quelques règles clés :

• BR-DEC-09 : BT-131 (montant net ligne) limite a 2 decimales.
• BR-DEC-13 : BT-112 (total TTC) limite a 2 decimales.
• BR-DEC-15 : BT-115 (montant du) limite a 2 decimales.
• BR-DEC-19 : BT-130 (quantite facturee) autorisee jusqu'a 4 decimales.

Ces règles tombent souvent lorsqu'un logiciel comptable emet un montant brut sans arrondi explicite (ex. 123.456789 au lieu de 123.46). C'est un piege classique : l'ecart est invisible sur la sortie PDF mais explicite dans le XML embarque. La revision Q4 2024 du Schematron CEN a durci certaines de ces règles, point evoque dans notre article Spec Factur-X v1.0.08 : ce qui change.

BR-CL-* : codes de liste

Les règles BR-CL- verifient qu'une valeur appartient bien a une code list normative. La norme EN 16931 référence plusieurs catalogues UN/CEFACT : pays (ISO 3166-1), devises (ISO 4217), catégories de TVA (UNCL5305), unites de mesure (UN/ECE Recommendation 20), types de document (UNCL1001), etc.

Exemples concrets :

• BR-CL-03 : BT-5 (devise) doit être un code ISO 4217 valide.
• BR-CL-04 : BT-6 (devise comptable TVA) doit aussi être ISO 4217.
• BR-CL-13 : la catégorie TVA d'une ligne (BT-151) doit appartenir a UNCL5305 (S, Z, E, AE, K, G, O, L, M).
• BR-CL-23 : l'unite de mesure d'une ligne (BT-130 schemeID) doit être un code UN/ECE Rec 20 (par exemple C62 pour piece, HUR pour heure, KGM pour kilogramme).

L'erreur typique BR-CL- est une devise saisie en toutes lettres (EURO au lieu de EUR) ou une unite en français (PIECE au lieu de C62). Le validateur ne suppose rien : la valeur est rejetee si elle ne figure pas litteralement dans la liste.

Lire un rule-ID dans un rapport

Un message d'erreur typique remonte par notre validateur se decompose ainsi :

[BR-CO-15] Le total TTC (BT-112) doit egaler le total HT (BT-109)
            plus le total TVA (BT-110).
            attendu : 1200.00
            trouve  :  1199.50
            xpath   : /rsm:CrossIndustryInvoice/.../ram:GrandTotalAmount

Quatre informations sont systematiquement présentes :

• Le rule-ID entre crochets (BR-CO-15), stable et tracable dans le Schematron officiel.
• Le texte normalisé de la règle, traduit en français.
• Les valeurs en jeu (attendue vs trouvee) quand il s'agit d'une coherence.
• Le XPath du noeud fautif dans le XML CII, pour pointer directement la donnee a corriger.

Comment notre validateur les traduit

Notre validateur execute deux pipelines en série sur le XML Factur-X extrait du PDF :

• Un XSD structurel (CII D16B) vérifié d'abord la grammaire du document. Les erreurs XSD sont rendues comme XSD-*, distinctes des BR-.
• Le Schematron CEN (version Q4 2024) execute ensuite les règles BR-*. Le rapport SVRL natif est reformate en JSON, chaque assertion devient un finding annote en français.
• Les règles CIUS FR (FR-CO-*) tournent en dernier, sur le même principe.

Chaque finding renvoye conserve son rule-ID d'origine : c'est cette stabilite qui permet de croiser un rapport avec la documentation du CEN ou avec un autre validateur (Mustang, OpenPEPPOL, etc.) si besoin. Si une règle vous parait erronee, le rule-ID est la clé pour la rouvrir dans le Schematron source et lever le doute.

Ce qu'il faut retenir

• BR- : un champ obligatoire manque (lecture immediate).
• BR-CO- : un total ne tombe pas juste (vérifier les arrondis amont).
• BR-DEC- : trop de decimales (arrondir a 2 ou 4 selon le champ).
• BR-CL- : valeur hors code list (utiliser le code normalisé, pas le libelle).

Pour aller plus loin sur le contexte normatif et la structure des profils : Qu'est-ce que Factur-X ? et Différences entre profils MINIMUM, BASIC, EN 16931 et EXTENDED donnent le cadre d'ensemble, tandis que notre validateur affiche chaque rule-ID en clair sur les fichiers que vous y deposez.