Catalogue erreurs BR-* EN16931 Factur-X : causes, correctifs, exemples XML CII

Ce catalogue est une référence consultable. Chaque entrée documente une règle Schematron EN16931 avec sa cause racine, un exemple XML déclenchant l’erreur, la correction correspondante, et les pièges spécifiques à surveiller. L’objectif est de réduire le temps de diagnostic d’une erreur BR-* de plusieurs heures à quelques minutes. Le tableau des familles ci-dessous est une organisation pratique des codes, pas une taxonomie normative officielle.

Pour comprendre la logique générale de la validation (XSD vs Schematron, workflow de debug), voir Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-*. Pour la cartographie complète des champs obligatoires, voir Champs obligatoires EN16931 : cartographie et mapping ERP.

Comment lire ce catalogue

Chaque entrée suit le même format :

• Identifiant : le code BR-* tel qu’il apparaît dans le rapport Schematron
• Sévérité : dans les artefacts EN16931 cœur, les règles BR-* sont en pratique majoritairement bloquantes (fatal). Certains outils ou couches CIUS peuvent exposer d’autres niveaux pour des contrôles additionnels hors noyau EN16931
• Règle : la description officielle issue du standard EN16931-1
• Cause racine : pourquoi cette erreur survient en pratique
• XML invalide : un fragment CII (Factur-X) qui déclenche l’erreur
• XML corrigé : le même fragment après correction
• Pièges : les subtilités qui provoquent des récidives

Les exemples XML utilisent la syntaxe CII (Cross-Industry Invoice) avec les namespaces Factur-X. Les préfixes utilisés sont :

<rsm:CrossIndustryInvoice
  xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
  xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
  xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100"
  xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100">

Familles de règles BR-*

Les règles Schematron EN16931 sont organisées en familles. Chaque préfixe a une sémantique précise :

Les règles BR- et BR-CO- s’appliquent à toute facture EN16931, quel que soit le pays. Les règles BR-S-*, BR-Z-*, etc. ne s’activent que pour les lignes et catégories TVA correspondantes. Les règles BR-DE-* sont des extensions nationales (CIUS) qui ne concernent pas les factures françaises.

Règles cœur : champs obligatoires (BR-*)

BR-01 — Identifiant de spécification absent

Sévérité : fatal

Règle : Une facture doit comporter un identifiant de spécification (BT-24).

Cause racine : Le nœud GuidelineSpecifiedDocumentContextParameter/ID est absent ou vide. BT-24 est obligatoire. En pratique, beaucoup de validateurs et de pipelines s’appuient aussi sur ce champ pour identifier le profil ou le contexte de validation.

XML invalide :

<rsm:ExchangedDocumentContext>
  <!-- BT-24 absent : pas de GuidelineSpecifiedDocumentContextParameter -->
  <ram:BusinessProcessSpecifiedDocumentContextParameter>
    <ram:ID>A1</ram:ID>
  </ram:BusinessProcessSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>

XML corrigé :

<rsm:ExchangedDocumentContext>
  <ram:BusinessProcessSpecifiedDocumentContextParameter>
    <ram:ID>A1</ram:ID>
  </ram:BusinessProcessSpecifiedDocumentContextParameter>
  <ram:GuidelineSpecifiedDocumentContextParameter>
    <ram:ID>urn:cen.eu:en16931:2017</ram:ID>
  </ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>

Pièges :

• La valeur de BT-24 doit correspondre exactement au profil Factur-X déclaré. Pour le profil EN16931, l’URN est urn:cen.eu:en16931:2017. Une coquille dans cette chaîne peut passer BR-01 mais déclencher d’autres erreurs de profil.
• Pour le choix du profil, voir Profils Factur-X : MINIMUM à EXTENDED.

BR-02 — Numéro de facture absent

Sévérité : fatal

Règle : Une facture doit comporter un numéro de facture (BT-1).

Cause racine : Le champ ram:ID dans ExchangedDocument est absent ou contient une chaîne vide. Fréquent quand l’ERP génère le XML avant l’attribution définitive du numéro séquentiel.

XML invalide :

<rsm:ExchangedDocument>
  <ram:ID></ram:ID>
  <ram:TypeCode>380</ram:TypeCode>
  <ram:IssueDateTime>
    <udt:DateTimeString format="102">20260523</udt:DateTimeString>
  </ram:IssueDateTime>
</rsm:ExchangedDocument>

XML corrigé :

<rsm:ExchangedDocument>
  <ram:ID>FA-2026-0042</ram:ID>
  <ram:TypeCode>380</ram:TypeCode>
  <ram:IssueDateTime>
    <udt:DateTimeString format="102">20260523</udt:DateTimeString>
  </ram:IssueDateTime>
</rsm:ExchangedDocument>

Pièges :

• Un espace ou un retour à la ligne dans <ram:ID> </ram:ID> peut techniquement passer le test string-length(.) > 0 selon l’implémentation Schematron, mais produit un numéro invalide en aval. Toujours renseigner un identifiant non-blanc.
• EN16931 n’impose pas de format spécifique pour le numéro de facture — c’est le droit national qui régit la séquentialité. En France, le numéro doit être séquentiel et sans rupture (Code Général des Impôts).

BR-03 — Date d’émission absente

Sévérité : fatal

Règle : Une facture doit comporter une date d’émission (BT-2).

Cause racine : Le nœud ram:IssueDateTime/udt:DateTimeString est absent ou vide. BR-03 porte sur la présence de la date d’émission, pas sur son format.

XML invalide :

<rsm:ExchangedDocument>
  <ram:ID>FA-2026-0042</ram:ID>
  <ram:TypeCode>380</ram:TypeCode>
  <!-- BT-2 absent : pas de IssueDateTime -->
</rsm:ExchangedDocument>

XML corrigé :

<rsm:ExchangedDocument>
  <ram:ID>FA-2026-0042</ram:ID>
  <ram:TypeCode>380</ram:TypeCode>
  <ram:IssueDateTime>
    <udt:DateTimeString format="102">20260523</udt:DateTimeString>
  </ram:IssueDateTime>
</rsm:ExchangedDocument>

Pièges :

• En CII, l’attribut format="102" est requis avec la valeur au format AAAAMMJJ (ex: 20260523). Un mauvais format (ISO 8601 2026-05-23, format localisé 23/05/2026, ou format absent/différent de "102") peut déclencher des erreurs distinctes de BR-03 (erreur XSD ou règle de format CII). La conversion doit se faire dans le générateur XML.
• Voir Champs obligatoires EN16931 : cartographie et mapping ERP pour le détail des formats de date CII.

BR-04 — Code de type de facture absent

Sévérité : fatal

Règle : Une facture doit comporter un code de type de facture (BT-3).

Cause racine : Le champ ram:TypeCode dans ExchangedDocument est absent ou vide. BR-04 porte sur la présence du code de type ; la validité de la valeur dans la liste UNTDID 1001 relève de BR-CL-01.

XML invalide :

<rsm:ExchangedDocument>
  <ram:ID>FA-2026-0042</ram:ID>
  <!-- BT-3 absent : pas de TypeCode -->
  <ram:IssueDateTime>
    <udt:DateTimeString format="102">20260523</udt:DateTimeString>
  </ram:IssueDateTime>
</rsm:ExchangedDocument>

XML corrigé :

<rsm:ExchangedDocument>
  <ram:ID>FA-2026-0042</ram:ID>
  <ram:TypeCode>380</ram:TypeCode>
  <ram:IssueDateTime>
    <udt:DateTimeString format="102">20260523</udt:DateTimeString>
  </ram:IssueDateTime>
</rsm:ExchangedDocument>

Pièges :

• Les codes les plus fréquents en France : 380 (facture), 381 (avoir/note de crédit), 389 (facture d’auto-facturation). Utiliser un code comme INVOICE ou FACTURE déclenche à la fois BR-04 (absence du code attendu) et potentiellement BR-CL-01 (code invalide dans la liste UNTDID 1001).
• L’ordre des éléments enfants de ExchangedDocument est contraint par le XSD : ID, puis Name (optionnel), puis TypeCode, puis IssueDateTime. Un TypeCode placé après IssueDateTime provoque une erreur XSD avant même l’exécution Schematron.

BR-05 — Code devise absent

Sévérité : fatal

Règle : Une facture doit comporter un code de devise (BT-5).

Cause racine : Le champ ram:InvoiceCurrencyCode dans ApplicableHeaderTradeSettlement est absent ou vide. Même si BT-5 est présent, sa validité ISO 4217 est vérifiée séparément par BR-CL-04.

XML invalide :

<ram:ApplicableHeaderTradeSettlement>
  <!-- BT-5 absent : pas de InvoiceCurrencyCode -->
  <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
    <ram:TaxTotalAmount currencyID="EUR">200.00</ram:TaxTotalAmount>
    <ram:GrandTotalAmount>1200.00</ram:GrandTotalAmount>
    <ram:DuePayableAmount>1200.00</ram:DuePayableAmount>
  </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
</ram:ApplicableHeaderTradeSettlement>

XML corrigé :

<ram:ApplicableHeaderTradeSettlement>
  <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
  <ram:SpecifiedTradeSettlementHeaderMonetarySummation>
    <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
    <ram:TaxTotalAmount currencyID="EUR">200.00</ram:TaxTotalAmount>
    <ram:GrandTotalAmount>1200.00</ram:GrandTotalAmount>
    <ram:DuePayableAmount>1200.00</ram:DuePayableAmount>
  </ram:SpecifiedTradeSettlementHeaderMonetarySummation>
</ram:ApplicableHeaderTradeSettlement>

Pièges :

• Le code devise doit être un code ISO 4217 alpha-3 : EUR, USD, GBP. Les erreurs courantes : EURO (trop long), eur (la casse est significative selon l’implémentation), 978 (code numérique ISO au lieu de l’alpha-3).
• L’attribut currencyID sur ram:TaxTotalAmount doit correspondre à BT-5. Si InvoiceCurrencyCode est EUR mais currencyID="USD", d’autres règles de cohérence seront déclenchées.

BR-06 — Nom du vendeur absent

Sévérité : fatal

Règle : Une facture doit comporter un nom de vendeur (BT-27).

Cause racine : Le nœud ram:Name dans ram:SellerTradeParty est absent ou vide. Arrive fréquemment avec les ERP qui renseignent uniquement l’identifiant légal (SIRET) sans le nom commercial.

XML invalide :

<ram:SellerTradeParty>
  <!-- BT-27 absent : pas de Name -->
  <ram:SpecifiedLegalOrganization>
    <ram:ID schemeID="0002">12345678901234</ram:ID>
  </ram:SpecifiedLegalOrganization>
  <ram:PostalTradeAddress>
    <ram:CountryID>FR</ram:CountryID>
  </ram:PostalTradeAddress>
</ram:SellerTradeParty>

XML corrigé :

<ram:SellerTradeParty>
  <ram:Name>Entreprise Exemple SAS</ram:Name>
  <ram:SpecifiedLegalOrganization>
    <ram:ID schemeID="0002">12345678901234</ram:ID>
  </ram:SpecifiedLegalOrganization>
  <ram:PostalTradeAddress>
    <ram:CountryID>FR</ram:CountryID>
  </ram:PostalTradeAddress>
</ram:SellerTradeParty>

Pièges :

• BT-27 correspond au nom du vendeur tel qu’il est porté sur la facture ; selon le contexte, il s’agit du nom légal/enregistré ou du nom sous lequel il exerce. Ne pas confondre avec BT-28 (Seller trading name / nom commercial additionnel).
• L’identifiant légal (BT-30, SIRET en France) et le nom (BT-27) sont deux champs distincts, les deux obligatoires. Renseigner l’un ne dispense pas de l’autre.

BR-07 — Nom de l’acheteur absent

Sévérité : fatal

Règle : Une facture doit comporter un nom d’acheteur (BT-44).

Cause racine : Le nœud ram:Name dans ram:BuyerTradeParty est absent ou vide. Courant dans les exports B2C où l’ERP ne renseigne pas toujours l’identité de l’acheteur, ou dans les factures internes.

XML invalide :

<ram:BuyerTradeParty>
  <!-- BT-44 absent : pas de Name -->
  <ram:PostalTradeAddress>
    <ram:CountryID>FR</ram:CountryID>
  </ram:PostalTradeAddress>
</ram:BuyerTradeParty>

XML corrigé :

<ram:BuyerTradeParty>
  <ram:Name>Client SA</ram:Name>
  <ram:PostalTradeAddress>
    <ram:CountryID>FR</ram:CountryID>
  </ram:PostalTradeAddress>
</ram:BuyerTradeParty>

Pièges :

• BT-44 reste obligatoire dans le noyau EN16931, y compris en contexte B2C. La manière de satisfaire cette exigence (nom réel, nom simplifié, etc.) doit être vérifiée au regard du cadre métier et réglementaire applicable.

BR-08 — Adresse postale du vendeur absente

Sévérité : fatal

Règle : Une facture doit comporter une adresse postale du vendeur (BG-5).

Cause racine : Le bloc ram:PostalTradeAddress dans ram:SellerTradeParty est absent, ou le champ ram:CountryID à l’intérieur est absent. BG-5 requiert au minimum le code pays (BT-40).

XML invalide :

<ram:SellerTradeParty>
  <ram:Name>Entreprise Exemple SAS</ram:Name>
  <!-- BG-5 absent : pas de PostalTradeAddress -->
</ram:SellerTradeParty>

XML corrigé :

<ram:SellerTradeParty>
  <ram:Name>Entreprise Exemple SAS</ram:Name>
  <ram:PostalTradeAddress>
    <ram:PostcodeCode>75001</ram:PostcodeCode>
    <ram:LineOne>10 Rue de Rivoli</ram:LineOne>
    <ram:CityName>Paris</ram:CityName>
    <ram:CountryID>FR</ram:CountryID>
  </ram:PostalTradeAddress>
</ram:SellerTradeParty>

Pièges :

• Le champ obligatoire minimal dans BG-5 est BT-40 (code pays). Les champs adresse ligne 1, ville, code postal sont techniquement optionnels dans EN16931 mais souvent exigés par certains cadres d’échange ou implémentations sectorielles.
• Le code pays doit être un code ISO 3166-1 alpha-2 : FR, DE, BE. Utiliser FRA (alpha-3) ou France déclenche une erreur BR-CL-* distincte.

Erreurs de cohérence arithmétique (BR-CO-*)

Les règles BR-CO-* vérifient que les montants de la facture sont arithmétiquement cohérents entre eux. Ce sont les erreurs les plus frustrantes car le XML est structurellement correct — ce sont les valeurs numériques qui ne s’accordent pas.

BR-CO-10 — Total HT lignes incohérent

Sévérité : fatal

Règle : La somme des montants nets de ligne (BT-106) doit être égale à la somme des montants nets individuels de chaque ligne de facture (somme des BT-131).

Cause racine : BT-106 (ram:LineTotalAmount) est calculé indépendamment de la somme des BT-131 (ram:LineTotalAmount de chaque ligne), ou une ligne a été ajoutée/supprimée sans recalculer le total.

XML invalide :

<!-- Ligne 1 : BT-131 = 500.00 -->
<ram:IncludedSupplyChainTradeLineItem>
  <ram:AssociatedDocumentLineDocument><ram:LineID>1</ram:LineID></ram:AssociatedDocumentLineDocument>
  <ram:SpecifiedLineTradeSettlement>
    <ram:ApplicableTradeTax><ram:TypeCode>VAT</ram:TypeCode><ram:CategoryCode>S</ram:CategoryCode><ram:RateApplicablePercent>20.00</ram:RateApplicablePercent></ram:ApplicableTradeTax>
    <ram:SpecifiedTradeSettlementLineMonetarySummation>
      <ram:LineTotalAmount>500.00</ram:LineTotalAmount>
    </ram:SpecifiedTradeSettlementLineMonetarySummation>
  </ram:SpecifiedLineTradeSettlement>
  <!-- ... -->
</ram:IncludedSupplyChainTradeLineItem>

<!-- Ligne 2 : BT-131 = 300.00 -->
<ram:IncludedSupplyChainTradeLineItem>
  <ram:AssociatedDocumentLineDocument><ram:LineID>2</ram:LineID></ram:AssociatedDocumentLineDocument>
  <ram:SpecifiedLineTradeSettlement>
    <ram:ApplicableTradeTax><ram:TypeCode>VAT</ram:TypeCode><ram:CategoryCode>S</ram:CategoryCode><ram:RateApplicablePercent>20.00</ram:RateApplicablePercent></ram:ApplicableTradeTax>
    <ram:SpecifiedTradeSettlementLineMonetarySummation>
      <ram:LineTotalAmount>300.00</ram:LineTotalAmount>
    </ram:SpecifiedTradeSettlementLineMonetarySummation>
  </ram:SpecifiedLineTradeSettlement>
  <!-- ... -->
</ram:IncludedSupplyChainTradeLineItem>

<!-- Totaux : BT-106 = 900.00 alors que 500 + 300 = 800 -->
<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:LineTotalAmount>900.00</ram:LineTotalAmount> <!-- BT-106 : FAUX -->
  <ram:TaxBasisTotalAmount>900.00</ram:TaxBasisTotalAmount>
  <!-- ... -->
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

XML corrigé :

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:LineTotalAmount>800.00</ram:LineTotalAmount> <!-- BT-106 = 500 + 300 = 800 -->
  <ram:TaxBasisTotalAmount>800.00</ram:TaxBasisTotalAmount>
  <!-- ... -->
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Pièges :

• En présence de remises/majorations au niveau document (BG-20 allowances, BG-21 charges), BT-106 reste la somme des BT-131. Ce sont BT-107 (total remises) et BT-108 (total majorations) qui ajustent le calcul vers BT-109. Ne pas mélanger les deux niveaux d’agrégation.
• Certains ERP arrondissent chaque BT-131 à 2 décimales, puis somment. D’autres somment les montants exacts puis arrondissent. Les deux approches peuvent donner des résultats différents d’un centime. EN16931 attend que BT-106 soit exactement la somme des BT-131.

BR-CO-13 — Total HT facture incohérent

Sévérité : fatal

Règle : Le montant total HT de la facture (BT-109) doit être égal à la somme des montants nets de ligne (BT-106) diminuée de la somme des remises au niveau document (BT-107) et augmentée de la somme des majorations au niveau document (BT-108). Formule : BT-109 = BT-106 - BT-107 + BT-108.

Cause racine : Les remises ou majorations au niveau document ne sont pas intégrées dans le calcul de BT-109, ou BT-107/BT-108 sont absents alors que des BG-20/BG-21 existent.

XML invalide :

<!-- Remise document de 50.00 -->
<ram:SpecifiedTradeAllowanceCharge>
  <ram:ChargeIndicator><udt:Indicator>false</udt:Indicator></ram:ChargeIndicator>
  <ram:ActualAmount>50.00</ram:ActualAmount>
  <ram:CategoryTradeTax>
    <ram:TypeCode>VAT</ram:TypeCode>
    <ram:CategoryCode>S</ram:CategoryCode>
    <ram:RateApplicablePercent>20.00</ram:RateApplicablePercent>
  </ram:CategoryTradeTax>
</ram:SpecifiedTradeAllowanceCharge>

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>      <!-- BT-106 -->
  <ram:AllowanceTotalAmount>50.00</ram:AllowanceTotalAmount> <!-- BT-107 -->
  <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount> <!-- BT-109 : FAUX, devrait être 950 -->
  <!-- ... -->
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

XML corrigé :

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>         <!-- BT-106 -->
  <ram:AllowanceTotalAmount>50.00</ram:AllowanceTotalAmount>  <!-- BT-107 -->
  <ram:TaxBasisTotalAmount>950.00</ram:TaxBasisTotalAmount>   <!-- BT-109 = 1000 - 50 = 950 -->
  <!-- ... -->
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Pièges :

• Si aucune remise ni majoration au niveau document n’existe, BT-107 et BT-108 peuvent être absents ou à 0. Dans ce cas, BT-109 = BT-106.
• Les remises au niveau ligne (BG-27) sont déjà intégrées dans BT-131 (montant net de la ligne). Ne pas les déduire une deuxième fois dans BT-109.

BR-CO-15 — Montant TTC incohérent

Sévérité : fatal

Règle : Le montant total TTC de la facture (BT-112) doit être égal au montant total HT (BT-109) plus le montant total de TVA (BT-110). Formule : BT-112 = BT-109 + BT-110.

Cause racine : BT-112 est calculé indépendamment au lieu d’être la somme de BT-109 et BT-110. Les erreurs d’arrondi en cascade depuis BR-CO-10 ou BR-CO-13 se propagent ici.

XML invalide :

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
  <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>          <!-- BT-109 -->
  <ram:TaxTotalAmount currencyID="EUR">200.00</ram:TaxTotalAmount>    <!-- BT-110 -->
  <ram:GrandTotalAmount>1199.99</ram:GrandTotalAmount>                <!-- BT-112 : FAUX -->
  <ram:DuePayableAmount>1199.99</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

XML corrigé :

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
  <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>          <!-- BT-109 -->
  <ram:TaxTotalAmount currencyID="EUR">200.00</ram:TaxTotalAmount>    <!-- BT-110 -->
  <ram:GrandTotalAmount>1200.00</ram:GrandTotalAmount>                <!-- BT-112 = 1000 + 200 -->
  <ram:DuePayableAmount>1200.00</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Pièges :

• Si la devise de TVA (BT-111) diffère de la devise de facturation (BT-5), deux ram:TaxTotalAmount coexistent avec des attributs currencyID différents. BT-112 utilise le montant TVA dans la devise de facturation (BT-110), pas celui dans la devise de TVA (BT-111).
• Un écart de 0,01 suffit à déclencher l’erreur. Toujours calculer BT-112 comme BT-109 + BT-110 en dernière étape, jamais indépendamment.

BR-CO-25 — Montant à payer incohérent

Sévérité : fatal

Règle : Si le montant à payer (BT-115) est renseigné, il doit être égal au montant total TTC (BT-112) diminué du montant déjà payé (BT-113) et augmenté de l’arrondi (BT-114). Formule : BT-115 = BT-112 - BT-113 + BT-114.

Cause racine : Un acompte (BT-113) a été versé mais BT-115 n’a pas été ajusté, ou BT-114 (montant d’arrondi) est utilisé sans être intégré dans le calcul.

XML invalide :

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
  <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
  <ram:TaxTotalAmount currencyID="EUR">200.00</ram:TaxTotalAmount>
  <ram:GrandTotalAmount>1200.00</ram:GrandTotalAmount>                 <!-- BT-112 -->
  <ram:TotalPrepaidAmount>300.00</ram:TotalPrepaidAmount>              <!-- BT-113 : acompte -->
  <ram:DuePayableAmount>1200.00</ram:DuePayableAmount>                 <!-- BT-115 : FAUX -->
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

XML corrigé :

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
  <ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
  <ram:TaxTotalAmount currencyID="EUR">200.00</ram:TaxTotalAmount>
  <ram:GrandTotalAmount>1200.00</ram:GrandTotalAmount>                 <!-- BT-112 -->
  <ram:TotalPrepaidAmount>300.00</ram:TotalPrepaidAmount>              <!-- BT-113 -->
  <ram:DuePayableAmount>900.00</ram:DuePayableAmount>                  <!-- BT-115 = 1200 - 300 = 900 -->
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Pièges :

• Si aucun acompte n’est versé et qu’il n’y a pas d’arrondi, BT-115 = BT-112. Beaucoup d’ERP omettent simplement BT-113 dans ce cas, ce qui est correct (son absence équivaut à 0).
• BT-114 (rounding amount) est rarement utilisé mais existe pour les pays où les montants sont arrondis au nickel le plus proche (ex: Suisse, 0.05 CHF). Si présent, il doit être intégré dans le calcul de BT-115.

Erreurs de catégorie TVA

Les règles BR-S-*, BR-Z-*, BR-E-* (et les autres familles TVA) vérifient la cohérence entre le code de catégorie TVA déclaré sur chaque ligne et dans les totaux, le taux appliqué, et les montants calculés. Ces règles sont conditionnelles : elles ne s’activent que pour les lignes utilisant la catégorie correspondante.

BR-S-08 — Base taxable incohérente pour catégorie Standard

Sévérité : fatal

Règle : Pour chaque ventilation de catégorie TVA (BG-23) avec le code catégorie Standard (S), la base taxable de la catégorie (BT-116) doit être la somme des montants nets des lignes, remises au niveau document et majorations au niveau document rattachés à cette catégorie et à ce taux.

Cause racine : BT-116 ne reflète pas la somme correcte des éléments rattachés à la même catégorie et au même taux. Typiquement, une ligne de facture, une remise ou une majoration au niveau document a été ajoutée ou modifiée sans recalculer la ventilation TVA correspondante.

XML invalide :

<!-- Ligne 1 : montant net 500.00, catégorie S, taux 20% -->
<!-- Ligne 2 : montant net 300.00, catégorie S, taux 20% -->
<!-- Remise document sur catégorie S 20% : 50.00 -->

<ram:ApplicableTradeTax>
  <ram:CalculatedAmount>150.00</ram:CalculatedAmount>             <!-- BT-117 -->
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:BasisAmount>800.00</ram:BasisAmount>                       <!-- BT-116 : FAUX (devrait être 750) -->
  <ram:CategoryCode>S</ram:CategoryCode>
  <ram:RateApplicablePercent>20.00</ram:RateApplicablePercent>    <!-- BT-119 -->
</ram:ApplicableTradeTax>

XML corrigé :

<ram:ApplicableTradeTax>
  <ram:CalculatedAmount>150.00</ram:CalculatedAmount>             <!-- BT-117 = 750 × 20 / 100 -->
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:BasisAmount>750.00</ram:BasisAmount>                       <!-- BT-116 = 500 + 300 - 50 = 750 -->
  <ram:CategoryCode>S</ram:CategoryCode>
  <ram:RateApplicablePercent>20.00</ram:RateApplicablePercent>    <!-- BT-119 -->
</ram:ApplicableTradeTax>

Pièges :

• BT-116 est la somme des montants nets des lignes de même catégorie et taux, ajustée des remises (BG-20) et majorations (BG-21) au niveau document imputées à cette même catégorie/taux. Oublier d’inclure les remises/charges document est la cause d’erreur la plus fréquente.
• Quand plusieurs taux coexistent dans la même catégorie (ex: 20% et 5.5% en France, tous deux S), chaque combinaison catégorie+taux produit sa propre ventilation BG-23 avec son propre BT-116. Vérifier que chaque ligne est correctement rattachée à la bonne ventilation.

Erreurs TVA Zero-rated (BR-Z-*)

Les règles BR-Z-* s’appliquent quand le code catégorie TVA est Z (zero rated). Les exigences principales :

• Le taux de TVA (BT-119) doit être 0
• Le montant de TVA de la catégorie (BT-117) doit être 0
• Un motif d’exonération (BT-120 ou BT-121) peut être requis selon la règle BR-Z exacte applicable

Erreur fréquente : déclarer un taux à 0.00 avec le code catégorie S au lieu de Z. Du point de vue Schematron, un taux zéro avec code S viole BR-S-05 (qui exige un taux > 0 pour la catégorie Standard).

<!-- FAUX : code S avec taux 0 -->
<ram:ApplicableTradeTax>
  <ram:CalculatedAmount>0.00</ram:CalculatedAmount>
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:BasisAmount>500.00</ram:BasisAmount>
  <ram:CategoryCode>S</ram:CategoryCode>                          <!-- Devrait être Z -->
  <ram:RateApplicablePercent>0.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>

<!-- CORRECT : code Z avec taux 0 -->
<ram:ApplicableTradeTax>
  <ram:CalculatedAmount>0.00</ram:CalculatedAmount>
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:BasisAmount>500.00</ram:BasisAmount>
  <ram:CategoryCode>Z</ram:CategoryCode>
  <ram:RateApplicablePercent>0.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>

Erreurs TVA Exempt (BR-E-*)

Les règles BR-E-* s’appliquent quand le code catégorie TVA est E (exempt). Les exigences principales :

• Le taux de TVA (BT-119) doit être 0
• Le montant de TVA (BT-117) doit être 0
• Un motif d’exonération en texte libre (BT-120) ou un code d’exonération (BT-121) doit être renseigné

Erreur fréquente : oublier le motif d’exonération. En pratique, des mentions légales complémentaires peuvent être requises par le droit national (en France, article 261 du CGI, article 293 B pour les micro-entreprises, etc.).

<!-- FAUX : catégorie E sans motif d'exonération -->
<ram:ApplicableTradeTax>
  <ram:CalculatedAmount>0.00</ram:CalculatedAmount>
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:BasisAmount>500.00</ram:BasisAmount>
  <ram:CategoryCode>E</ram:CategoryCode>
  <ram:RateApplicablePercent>0.00</ram:RateApplicablePercent>
  <!-- BT-120 absent : motif d'exonération manquant -->
</ram:ApplicableTradeTax>

<!-- CORRECT : catégorie E avec motif -->
<ram:ApplicableTradeTax>
  <ram:CalculatedAmount>0.00</ram:CalculatedAmount>
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:ExemptionReason>TVA non applicable, article 293 B du CGI</ram:ExemptionReason>
  <ram:BasisAmount>500.00</ram:BasisAmount>
  <ram:CategoryCode>E</ram:CategoryCode>
  <ram:RateApplicablePercent>0.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>

Pièges :

• BR-E-10 exige que le montant TVA de la catégorie Exempt soit nul. Si un montant TVA non nul est déclaré avec le code E, deux erreurs seront levées simultanément.
• En France, le motif d’exonération est aussi une obligation légale (article 242 nonies A du CGI). Son absence peut être sanctionnée indépendamment de la conformité EN16931.

Erreurs TVA Reverse Charge (BR-AE-*)

Les règles BR-AE-* s’appliquent quand le code catégorie TVA est AE (reverse charge / autoliquidation). L’acheteur, et non le vendeur, est redevable de la TVA.

• Le taux de TVA (BT-119) doit être 0
• Le montant de TVA (BT-117) doit être 0
• Un motif (BT-120) ou un code d’exonération (BT-121) doit être renseigné
• Des exigences spécifiques portent sur la présence des identifiants TVA (BT-31 vendeur, BT-48 acheteur) — se référer à la règle BR-AE exacte applicable pour connaître les combinaisons requises

<!-- CORRECT : autoliquidation avec motif et identifiants TVA -->
<ram:ApplicableTradeTax>
  <ram:CalculatedAmount>0.00</ram:CalculatedAmount>
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:ExemptionReason>Autoliquidation - Article 283-2 du CGI</ram:ExemptionReason>
  <ram:BasisAmount>5000.00</ram:BasisAmount>
  <ram:CategoryCode>AE</ram:CategoryCode>
  <ram:RateApplicablePercent>0.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>

Pièges :

• L’autoliquidation est fréquente dans le BTP (sous-traitance) et les prestations de services intra-UE. Le code AE est distinct de IC (intra-community supply of goods). Les confondre déclenche des erreurs dans les deux familles de règles.
• BT-31 (identifiant TVA du vendeur) est distinct de BT-30 (identifiant d’enregistrement légal / SIRET en France). Pour l’autoliquidation, c’est bien le numéro de TVA intracommunautaire (BT-31) qui est requis, pas le SIRET.

Diagnostic systématique

Face à une erreur BR-* dans un rapport de validation, voici la procédure de diagnostic en 5 étapes.

1. Identifier la famille

Le préfixe indique immédiatement le domaine :

2. Lire le message, pas seulement le code

Le rapport de validation contient un message en clair pour chaque erreur. Ce message est la traduction humaine de l’assertion XPath Schematron. Il décrit ce qui est attendu, pas ce qui est trouvé. Exemple :

[BR-CO-15] Invoice total amount with VAT (BT-112) = Invoice total amount
without VAT (BT-109) + Invoice total VAT amount (BT-110).

Ce message indique la formule exacte. Il suffit de vérifier les trois valeurs dans le XML.

3. Naviguer au XPath

Selon le validateur, le rapport peut fournir un chemin XPath, un contexte Schematron ou un nœud de rattachement. Pour les erreurs arithmétiques, le contexte pointe généralement vers :

/rsm:CrossIndustryInvoice
  /rsm:SupplyChainTradeTransaction
    /ram:ApplicableHeaderTradeSettlement
      /ram:SpecifiedTradeSettlementHeaderMonetarySummation

Pour les erreurs de champs manquants, le contexte pointe souvent vers le parent du champ absent (comportement courant mais dépendant de l’implémentation du validateur). Si BR-02 indique /rsm:CrossIndustryInvoice/rsm:ExchangedDocument, c’est que ram:ID est absent dans ce nœud.

4. Reconstituer le calcul

Pour les erreurs BR-CO-*, extraire les valeurs du XML et refaire le calcul à la main :

BT-106 (LineTotalAmount)        = somme des BT-131 de chaque ligne
BT-107 (AllowanceTotalAmount)   = somme des remises document
BT-108 (ChargeTotalAmount)      = somme des majorations document
BT-109 (TaxBasisTotalAmount)    = BT-106 - BT-107 + BT-108
BT-110 (TaxTotalAmount)         = somme des BT-117 de chaque catégorie TVA
BT-112 (GrandTotalAmount)       = BT-109 + BT-110
BT-113 (TotalPrepaidAmount)     = acomptes versés
BT-115 (DuePayableAmount)       = BT-112 - BT-113 + BT-114

L’écart entre la valeur attendue et la valeur trouvée indique la source du problème. Un écart de 0.01 pointe vers un arrondi. Un écart de plusieurs centaines pointe vers une ligne manquante dans le calcul.

5. Corriger dans le générateur, pas dans le XML

La correction doit se faire dans le code qui produit le XML (moteur ERP, bibliothèque de génération, template). Modifier le XML manuellement corrige le symptôme mais l’erreur réapparaîtra à la prochaine génération.

Après correction, re-valider le fichier complet. Une correction en cascade est fréquente : corriger BT-117 impacte BT-110, qui impacte BT-112, qui impacte BT-115. Valider après chaque modification intermédiaire est contre-productif — corriger toute la chaîne puis valider une seule fois.

# Validation via l'API FacturX
curl -s -X POST https://facturxapi.com/api/v1/validate \
  -H "X-API-Key: votre-cle-api" \
  -F "[email protected]" | jq '.errors'

Un tableau vide [] confirme la conformité.

Chaîne de calcul : vue d’ensemble

Le schéma suivant résume les dépendances entre Business Terms pour les montants. Toute erreur BR-CO-* se localise sur l’une de ces liaisons.

Lignes (BG-25)
│
├─ BT-131 (montant net ligne 1)
├─ BT-131 (montant net ligne 2)
├─ ...
│
▼
BT-106 = Σ BT-131                    ← BR-CO-10
│
├─ BT-107 = Σ remises document        (BG-20)
├─ BT-108 = Σ majorations document    (BG-21)
│
▼
BT-109 = BT-106 - BT-107 + BT-108   ← BR-CO-13
│
├─ Catégorie TVA (BG-23)
│  ├─ BT-116 = base taxable catégorie    ← BR-S-08 (et équivalents par catégorie)
│  ├─ BT-119 = taux catégorie
│  └─ BT-117 = BT-116 × BT-119 / 100
│
├─ BT-110 = Σ BT-117                  ← BR-CO-14
│
▼
BT-112 = BT-109 + BT-110             ← BR-CO-15
│
├─ BT-113 = acomptes versés
├─ BT-114 = arrondi
│
▼
BT-115 = BT-112 - BT-113 + BT-114   ← BR-CO-25

Erreurs les plus fréquentes : récapitulatif

Aller plus loin

• Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-* — workflow de debug complet, validation XSD vs Schematron, pièges courants
• Facturation électronique 2026 : le guide technique complet — contexte de la réforme, architecture PDP, calendrier
• Champs obligatoires EN16931 : cartographie et mapping ERP — tous les Business Terms par Business Group, avec XPath CII
• Profils Factur-X : MINIMUM à EXTENDED — quel profil choisir selon votre flux et vos obligations

La validation automatisée via l’API retourne les codes BR-* avec messages explicatifs et chemins XPath dans un rapport JSON structuré. Chaque erreur de ce catalogue correspond à une entrée du rapport, directement exploitable pour le diagnostic.