FacturX API
Technique

Erreurs Factur-X BTP : autoliquidation, situations, retenue de garantie — diagnostic et correction

11 min de lecture Par FacturX API

Corriger les erreurs Factur-X spécifiques au BTP : autoliquidation (art. 283, 2 nonies CGI), factures de situation, retenue de garantie 5%, multi-taux TVA. Exemples XML et API.

En bref

  • 5 erreurs les plus fréquentes sur les factures BTP : autoliquidation (AE), factures de situation, retenue de garantie, multi-taux TVA, codes UNTDID pour avoirs partiels.
  • Autoliquidation sous-traitance (article 283-2 nonies CGI) → catégorie AE, taux 0, code VATEX-EU-AE. Pas Z, pas E.
  • Factures de situation : BT-131 calculé sur le pourcentage d’avancement, pas le total marché.
  • Retenue de garantie : soustraite via TotalPrepaidAmount (BT-113), pas en minorant le total TTC.
  • Validation preflight systématique via /validate avant envoi PDP / Chorus Pro.

Le BTP cumule les cas les plus complexes pour la facturation électronique. Autoliquidation de TVA sur la sous-traitance, factures de situation partielle sur des marchés pluriannuels, retenue de garantie de 5%, trois taux de TVA différents sur un même chantier de rénovation. Ces mécanismes métier, parfaitement maîtrisés par les logiciels sectoriels, deviennent des sources de rejet massif dès qu’il faut les encoder en XML CII conforme EN16931.

Le problème n’est pas technique au sens strict. Les données existent dans l’ERP. Le problème est le mapping : chaque spécificité BTP active des règles Schematron différentes, exige des codes précis et des relations arithmétiques strictes entre champs. Un vatCategory incorrect, un montant de situation mal positionné, une retenue soustraite au mauvais niveau — et la facture est rejetée par la PDP (ou par Chorus Pro pour les marchés publics).

Cet article documente les cinq erreurs Factur-X les plus fréquentes sur les factures BTP, avec le diagnostic Schematron, le XML invalide, le XML corrigé et les références légales exactes. Pour le contexte général de la validation (XSD vs Schematron, workflow de debug), voir Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-*. Pour le mapping complet des données ERP vers CII, voir Données ERP → Factur-X CII : mapper JSON vers XML EN16931.

Erreur #1 : autoliquidation mal déclarée (BR-AE-*)

C’est l’erreur la plus fréquente sur les factures de sous-traitance BTP. Le sous-traitant facture sans TVA — c’est l’entreprise principale qui autoliquide. Le fondement légal est l’article 283, 2 nonies du CGI, spécifique aux travaux immobiliers réalisés en sous-traitance.

Le piège

L’ERP code la ligne avec vatCategory="S" et vatRate=20 puis applique un montant TVA de zéro. Ou bien il utilise le bon code AE mais omet le motif d’exonération ou les identifiants fiscaux. Chaque variante déclenche une erreur BR-AE différente.

XML invalide

<ram:ApplicableTradeTax>
  <!-- ERREUR : catégorie "S" au lieu de "AE" -->
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:CategoryCode>S</ram:CategoryCode>
  <ram:RateApplicablePercent>0</ram:RateApplicablePercent>
  <ram:BasisAmount>15000.00</ram:BasisAmount>
  <ram:CalculatedAmount>0.00</ram:CalculatedAmount>
</ram:ApplicableTradeTax>

Avec CategoryCode=S, le validateur attend un taux strictement positif. Taux 0 avec catégorie S viole BR-S-08 (base taxable incohérente avec le taux). Et même en corrigeant la catégorie vers AE, trois éléments manquent : le motif d’exonération (BT-120/BT-121), un identifiant fiscal vendeur et un identifiant acheteur.

Les règles BR-AE activées

RègleObjet
BR-AE-01Une ventilation TVA (BG-23) avec catégorie AE doit avoir un taux (BT-119) de 0
BR-AE-02Une ventilation TVA AE doit avoir une base taxable (BT-116)
BR-AE-05Les lignes de facture rattachées à la catégorie AE doivent avoir un taux de 0
BR-AE-10Une raison d’exonération (BT-120) ou un code (BT-121) doit être présent pour la catégorie AE

La description complète de chaque règle BR-AE est disponible dans les artefacts EN16931 officiels. Le contenu exact peut varier selon la version des artefacts.

Attention aux identifiants requis : le vendeur doit fournir au moins un identifiant fiscal parmi BT-31 (TVA intra), BT-32 (identifiant fiscal national) ou BT-63 (identifiant fiscal supplémentaire). L’acheteur doit fournir BT-48 (identifiant TVA acheteur) ou BT-47 (identifiant légal acheteur). Ce n’est pas “les deux parties doivent avoir un numéro de TVA” — l’acheteur peut fournir son SIRET via BT-47 si le numéro de TVA n’est pas disponible.

XML corrigé

<!-- Vendeur : identifiant fiscal (BT-31) -->
<ram:SpecifiedTaxRegistration>
  <ram:ID schemeID="VA">FR32123456789</ram:ID>
</ram:SpecifiedTaxRegistration>

<!-- Acheteur : identifiant TVA (BT-48) -->
<ram:SpecifiedTaxRegistration>
  <ram:ID schemeID="VA">FR87987654321</ram:ID>
</ram:SpecifiedTaxRegistration>

<!-- Ventilation TVA corrigée -->
<ram:ApplicableTradeTax>
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:CategoryCode>AE</ram:CategoryCode>
  <ram:RateApplicablePercent>0</ram:RateApplicablePercent>
  <ram:BasisAmount>15000.00</ram:BasisAmount>
  <ram:CalculatedAmount>0.00</ram:CalculatedAmount>
  <ram:ExemptionReason>Autoliquidation - Sous-traitance BTP,
    article 283, 2 nonies du CGI</ram:ExemptionReason>
</ram:ApplicableTradeTax>

Le motif d’exonération doit citer le fondement légal exact : article 283, 2 nonies du Code général des impôts. Pas “article 283-2”, pas “article 283-2 nonies”, pas “reverse charge”. Le dispositif d’autoliquidation pour les travaux immobiliers en sous-traitance est codifié à l’article 283, 2 nonies du CGI, introduit par la loi n 2013-1278 du 29 décembre 2013 (article 25), applicable aux contrats de sous-traitance conclus à compter du 1er janvier 2014. Pour les prestations intra-UE (qui utilisent aussi le code AE), le fondement est l’article 283, 1, alinéa 2 du CGI — un régime juridique différent.

Côté interopérabilité EN16931, le code d’exonération recommandé est VATEX-EU-AE (BT-121). En complément, la facture française porte la mention textuelle “Autoliquidation” (BT-120). Les deux champs peuvent — et devraient — coexister dans le XML.

Pour un exemple complet JSON → XML incluant l’autoliquidation, voir Données ERP → Factur-X CII.

Erreur #2 : facture de situation avec des montants incohérents (BR-CO-10)

Les marchés de travaux sont facturés par situations successives : situation 1 à 30% d’avancement, situation 2 à 60%, etc. L’ERP stocke le montant cumulé du marché et calcule le montant de chaque situation par différence. Le piège EN16931 : le XML CII ne modélise pas le cumul. Chaque facture de situation est un document autonome avec ses propres totaux.

Le piège

L’ERP génère une situation n°3 pour un marché de 100 000 EUR HT, avancement cumulé de 45% à 70%. Le montant de la situation est 25 000 EUR. Mais le XML contient des lignes dont la somme fait 70 000 EUR (le cumul) au lieu de 25 000 EUR (la situation courante). Résultat : BR-CO-10 — la somme des montants nets de ligne (BT-106) ne correspond pas au total net de la facture (BT-109).

La bonne approche

Chaque facture de situation est une facture complète et indépendante. Les montants ligne reflètent exclusivement le périmètre de la situation courante — pas le cumul, pas le total du marché. Le chaînage entre situations passe par le champ BT-25 (référence de la facture précédente) qui permet de reconstituer l’historique.

<!-- Référence à la situation précédente (BT-25) -->
<ram:InvoiceReferencedDocument>
  <ram:IssuerAssignedID>SIT-2026-042</ram:IssuerAssignedID>
</ram:InvoiceReferencedDocument>

<!-- Ligne : montant de la situation courante uniquement -->
<ram:IncludedSupplyChainTradeLineItem>
  <ram:AssociatedDocumentLineDocument>
    <ram:LineID>1</ram:LineID>
  </ram:AssociatedDocumentLineDocument>
  <ram:SpecifiedTradeProduct>
    <ram:Name>Gros oeuvre — avancement situation 3 (45% à 70%)</ram:Name>
  </ram:SpecifiedTradeProduct>
  <ram:SpecifiedLineTradeAgreement>
    <ram:NetPriceProductTradePrice>
      <ram:ChargeAmount>25000.00</ram:ChargeAmount>
    </ram:NetPriceProductTradePrice>
  </ram:SpecifiedLineTradeAgreement>
  <ram:SpecifiedLineTradeDelivery>
    <ram:BilledQuantity unitCode="C62">1</ram:BilledQuantity>
  </ram:SpecifiedLineTradeDelivery>
  <ram:SpecifiedLineTradeSettlement>
    <ram:ApplicableTradeTax>
      <ram:TypeCode>VAT</ram:TypeCode>
      <ram:CategoryCode>S</ram:CategoryCode>
      <ram:RateApplicablePercent>10</ram:RateApplicablePercent>
    </ram:ApplicableTradeTax>
    <ram:SpecifiedTradeSettlementLineMonetarySummation>
      <ram:LineTotalAmount>25000.00</ram:LineTotalAmount>
    </ram:SpecifiedTradeSettlementLineMonetarySummation>
  </ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>

Les totaux du document (BT-106 à BT-115) doivent être cohérents avec les seules lignes de la situation courante. La vérification arithmétique porte sur BR-CO-10 (somme des LineTotalAmount = LineTotalAmount du document), BR-CO-13 (total net = somme ventilations TVA) et BR-CO-15 (total TTC = total HT + total TVA). Un centime d’écart entre le montant de la situation calculé par l’ERP et la somme des lignes XML provoque un rejet.

La description de la ligne (BT-153) peut mentionner la tranche d’avancement pour la traçabilité. Mais la cohérence arithmétique se joue sur les montants, pas sur le libellé.

Erreur #3 : retenue de garantie mal modélisée

La retenue de garantie est un mécanisme propre aux marchés de travaux : le maître d’ouvrage retient 5% du montant TTC de chaque situation, libérable un an après la réception (article 1er de la loi n°71-584 du 16 juillet 1971). C’est un montant dû mais non payé immédiatement — le total TTC reste inchangé, seul le montant à payer diminue.

Le piège

Soustraire la retenue du GrandTotalAmount (BT-112) au lieu du DuePayableAmount (BT-115). Le total TTC de la facture ne change pas du fait de la retenue — c’est le montant à régler qui diminue. Confondre les deux casse la formule de cohérence.

La bonne modélisation

La modélisation de la retenue de garantie en EN16931 n’est pas triviale. L’exemple ci-dessous utilise une approche simplifiée via BT-113 (montant déjà payé). D’autres modélisations sont possibles selon le contexte contractuel (charge de niveau document BG-21, par exemple).

La règle BR-CO-16 impose : BT-115 (DuePayableAmount) = BT-112 (GrandTotalAmount) - BT-113 (PrepaidAmount) + BT-114 (RoundingAmount). En modélisant la retenue via BT-113, l’équation reste satisfaite.

Exemple avec un total TTC (BT-112) de 39 600 EUR et une retenue de 5% :

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
  <!-- Total HT (BT-109) -->
  <ram:LineTotalAmount>33000.00</ram:LineTotalAmount>
  <!-- Total TVA (BT-110) -->
  <ram:TaxTotalAmount currencyID="EUR">6600.00</ram:TaxTotalAmount>
  <!-- Total TTC (BT-112) — inchangé par la retenue -->
  <ram:GrandTotalAmount>39600.00</ram:GrandTotalAmount>
  <!-- Retenue de garantie 5% modélisée comme prépaiement (BT-113) -->
  <ram:TotalPrepaidAmount>1980.00</ram:TotalPrepaidAmount>
  <!-- Montant à payer (BT-115) = 39600 - 1980 = 37620 -->
  <ram:DuePayableAmount>37620.00</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>

Le calcul : 39 600.00 (TTC) - 1 980.00 (retenue 5% de 39 600) = 37 620.00 EUR à payer. BR-CO-16 est satisfaite : BT-115 (37 620) = BT-112 (39 600) - BT-113 (1 980). Le total TTC (BT-112) reste à 39 600.00 — il reflète le montant juridiquement dû. Le DuePayableAmount (BT-115) reflète le montant effectivement réglé sur cette situation.

Pour documenter la retenue dans le XML, ajouter une note au niveau document (BT-22) :

<ram:IncludedNote>
  <ram:Content>Retenue de garantie de 5% (loi n°71-584 du 16 juillet 1971) :
    1 980,00 EUR. Libérable un an après réception des travaux.</ram:Content>
  <ram:SubjectCode>AAK</ram:SubjectCode>
</ram:IncludedNote>

Erreur #4 : multi-taux TVA incohérents sur un même chantier (BR-S-08, BR-CO-14)

Un chantier de rénovation résidentielle combine fréquemment trois taux de TVA : 10% pour les travaux d’amélioration (article 279-0 bis du CGI), 5,5% pour les travaux d’amélioration de la qualité énergétique (article 278-0 bis A), et 20% pour les fournitures ou prestations hors périmètre réglementaire. Chaque combinaison catégorie + taux doit produire une ventilation TVA séparée dans le XML (groupe BG-23).

Le piège

L’ERP rattache toutes les lignes au taux principal (10%) ou agrège les bases taxables sans distinguer par taux. Le XML ne contient qu’une seule ventilation TVA, mais les lignes portent des taux différents. Résultat : BR-S-08 (la base taxable de la ventilation ne correspond pas à la somme des lignes rattachées à ce taux) et BR-CO-14 (la somme des montants TVA par ventilation ne correspond pas au total TVA du document).

XML corrigé : trois ventilations séparées

<!-- Ventilation 1 : travaux à 10% -->
<ram:ApplicableTradeTax>
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:CategoryCode>S</ram:CategoryCode>
  <ram:RateApplicablePercent>10</ram:RateApplicablePercent>
  <ram:BasisAmount>18000.00</ram:BasisAmount>
  <ram:CalculatedAmount>1800.00</ram:CalculatedAmount>
</ram:ApplicableTradeTax>

<!-- Ventilation 2 : amélioration énergétique à 5.5% -->
<ram:ApplicableTradeTax>
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:CategoryCode>S</ram:CategoryCode>
  <ram:RateApplicablePercent>5.5</ram:RateApplicablePercent>
  <ram:BasisAmount>8500.00</ram:BasisAmount>
  <ram:CalculatedAmount>467.50</ram:CalculatedAmount>
</ram:ApplicableTradeTax>

<!-- Ventilation 3 : fournitures à 20% -->
<ram:ApplicableTradeTax>
  <ram:TypeCode>VAT</ram:TypeCode>
  <ram:CategoryCode>S</ram:CategoryCode>
  <ram:RateApplicablePercent>20</ram:RateApplicablePercent>
  <ram:BasisAmount>3200.00</ram:BasisAmount>
  <ram:CalculatedAmount>640.00</ram:CalculatedAmount>
</ram:ApplicableTradeTax>

Le total TVA (BT-110) doit être la somme exacte : 1 800.00 + 467.50 + 640.00 = 2 907.50 EUR. Le total HT (BT-109) : 18 000.00 + 8 500.00 + 3 200.00 = 29 700.00 EUR. Chaque ligne de facture doit porter le RateApplicablePercent correspondant à la ventilation dont elle relève. Une ligne de travaux à 10% rattachée par erreur à la ventilation 20% fausse les deux bases taxables et déclenche BR-S-08 sur les deux ventilations.

Pour le détail complet des règles BR-S-* et BR-CO-*, voir le Catalogue des erreurs BR-* EN16931.

Erreur #5 : SIRET manquant ou mal formaté

Les marchés publics et la plupart des marchés privés BTP exigent l’identification complète des entreprises. Le SIRET (Système d’identification du répertoire des établissements) est l’identifiant légal de référence en France — 14 chiffres : 9 chiffres SIREN + 5 chiffres NIC.

Le piège

L’ERP stocke le SIREN (9 chiffres) au lieu du SIRET (14 chiffres), ou passe le SIRET sans le schemeID qui identifie le répertoire. Sans schemeID="0002" (code ISO 6523 pour le répertoire SIRENE de l’INSEE), le validateur ne sait pas interpréter l’identifiant.

XML invalide vs corrigé

<!-- INVALIDE : SIREN au lieu de SIRET, pas de schemeID -->
<ram:SpecifiedLegalOrganization>
  <ram:ID>123456789</ram:ID>
</ram:SpecifiedLegalOrganization>

<!-- CORRIGÉ : SIRET 14 chiffres + schemeID 0002 -->
<ram:SpecifiedLegalOrganization>
  <ram:ID schemeID="0002">12345678901234</ram:ID>
</ram:SpecifiedLegalOrganization>

Le schemeID="0002" correspond à l’entrée “SIRENE” dans la liste ISO 6523 des identifiants d’organisations. Pour les factures BTP destinées au secteur public (marchés publics), Chorus Pro reste la plateforme de référence et exige ce code pour les entreprises françaises. Pour le B2B privé, la transmission passe par la PDP de l’acheteur.

L’absence du schemeID sur BT-30 est une erreur de formatage (le validateur exige l’attribut). La règle BR-CO-26 porte sur un sujet différent : la présence d’au moins un identifiant vendeur parmi BT-29, BT-30 ou BT-31. Un SIREN à 9 chiffres au lieu d’un SIRET à 14 ne provoque pas d’erreur Schematron EN16931 (le standard ne valide pas le format du contenu), mais sera rejeté par Chorus Pro et les PDP qui effectuent des contrôles métier supplémentaires.

Pour les règles de réparation automatique des schemeID manquants, voir Corriger automatiquement un XML CII Factur-X invalide.

Pipeline de diagnostic pour le BTP

Face à une facture BTP rejetée, le diagnostic suit un arbre de décision basé sur le type d’erreur :

1. Identifier la famille d’erreur

  • Erreur BR-AE-* → problème d’autoliquidation
  • Erreur BR-CO-10, BR-CO-13, BR-CO-15 → problème de cohérence des montants (situation, retenue)
  • Erreur BR-S-08, BR-CO-14 → problème de ventilation multi-taux
  • Erreur BR-CO-26 → identifiant vendeur manquant (SIRET / TVA intra)

2. Vérifier par type

Type de facture BTPPoints de contrôle
Sous-traitancevatCategory=AE + vatRate=0 + motif exonération + identifiants vendeur/acheteur
SituationMontants = situation courante (pas cumul) + BT-25 pour chaînage
Avec retenueBT-112 = total TTC complet, BT-115 = TTC - retenue
Multi-taux rénovationUne ventilation BG-23 par combinaison catégorie + taux
Toute factureSIRET 14 chiffres + schemeID 0002

3. Valider et itérer

L’API Validate analyse le XML et retourne le diagnostic Schematron complet avec les codes BR-* précis. L’API Repair corrige automatiquement les erreurs de format (dates, décimaux, schemeID) — mais les erreurs de fond (mauvais vatCategory, montants incohérents) nécessitent une correction dans les données source de l’ERP.

Testez une facture BTP directement dans le validateur en ligne pour obtenir un diagnostic immédiat.

Erreurs fréquentes et fiches de diagnostic

Les 22 fiches unitaires : catalogue complet des erreurs BR-*.

Et maintenant ?

Tester ma facture maintenant →

 
curl -X POST https://api.facturxapi.com/api/v1/validate \
  -H "Authorization: Bearer VOTRE_CLE" \
  -F "file=@facture.pdf"

10 opérations gratuites par mois, sans carte bancaire. Obtenir une clé API.

Aller plus loin

#BTP #factur-x #autoliquidation #EN16931 #erreurs #facture de situation #retenue de garantie

Et maintenant ?

Prochaines étapes

Choisissez l'étape suivante pour activer FacturX API sur votre stack. Tous les liens sont internes pour garder le suivi clair.

→

Obtenir une clé API

Accédez gratuitement à l'API de validation Factur-X.

→

Voir les tarifs

Plans adaptés du prototype à la production. Essai gratuit inclus.

→

Documentation

Référence complète de l'API : endpoints, paramètres, exemples.

→

Tester une facture

Validez un fichier Factur-X directement dans le navigateur.