Avoirs et factures rectificatives

Qu’un système destinataire comptabilise un document comme une facture ou le passe en avoir dépend d’un seul champ : le code de type de facture (BT-3). Il porte un code de la liste UNTDID 1001, le répertoire UN/EDIFACT des fonctions de document, dont la norme EN 16931 admet un sous-ensemble. Un mauvais code ne provoque aucune erreur de schéma — il provoque des écritures comptables fausses. Ce guide situe les codes 381, 384 et la famille 380, puis montre à quoi doivent ressembler la référence à la facture initiale et la logique des signes en UBL et en CII (Factur-X).

381, 384 ou famille 380 ?

Un avoir (381) est un document commercial autonome qui crédite un montant à l’acheteur — après un retour, une réclamation ou une remise rétroactive. Il porte son propre numéro et n’annule pas la facture initiale : il la compense en tout ou en partie. En pratique française, l’avoir doit mentionner la facture d’origine — d’où l’importance du groupe BG-3 décrit plus bas. À ne pas confondre avec l’autofacturation (la facture émise par le client au nom du fournisseur) : c’est le code 389.

Une facture rectificative (384) remplace une facture antérieure sur le fond — mauvais taux de TVA, mauvaise adresse, mauvais identifiant de routage. Fonctionnellement, la 384 se substitue entièrement à la facture initiale, qui devient caduque.

Pour la facturation par étapes, il y a la famille 380 : 326 (facture partielle), 386 (facture d’acompte), et la facture de solde comme une 380 ordinaire qui impute les acomptes versés via BT-113.

Particularité UBL : un 381 circule habituellement dans son propre élément racine, CreditNote, avec cbc:CreditNoteTypeCode, tandis que 380/384/326 restent dans la racine Invoice avec cbc:InvoiceTypeCode. La syntaxe CII — celle de Factur-X et de ZUGFeRD — ne connaît que CrossIndustryInvoice ; le code s’y trouve toujours dans ram:ExchangedDocument/ram:TypeCode :

<!-- UBL, racine Invoice (380, 384, 326 …) -->
<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>

<!-- UBL, racine CreditNote (381) -->
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>

<!-- CII (Factur-X, ZUGFeRD, XRechnung CII) -->
<ram:TypeCode>381</ram:TypeCode>

Référencer la facture initiale : BG-3

Un avoir ou une rectificative sans référence est quasi inexploitable pour la comptabilité fournisseurs du destinataire. La norme EN 16931 prévoit pour cela le groupe BG-3 : le numéro de la facture antérieure (BT-25) et, en option, sa date d’émission (BT-26). Le groupe est facultatif et répétable dans la norme (un avoir couvrant plusieurs factures), mais en pratique chaque 381 et chaque 384 devrait le porter — beaucoup de systèmes de workflow font le rapprochement automatiquement sur ce champ.

En UBL :

<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>FA-2026-0417</cbc:ID>
    <cbc:IssueDate>2026-05-12</cbc:IssueDate>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

En CII, la référence se place dans ApplicableHeaderTradeSettlement ; comme toujours, la date exige format="102" (AAAAMMJJ) :

<ram:ApplicableHeaderTradeSettlement>
  <!-- … devise, taxes, totaux … -->
  <ram:InvoiceReferencedDocument>
    <ram:IssuerAssignedID>FA-2026-0417</ram:IssuerAssignedID>
    <ram:FormattedIssueDateTime>
      <qdt:DateTimeString format="102">20260512</qdt:DateTimeString>
    </ram:FormattedIssueDateTime>
  </ram:InvoiceReferencedDocument>
</ram:ApplicableHeaderTradeSettlement>

Logique des signes : 381 positif ou 384 négatif ?

La norme EN 16931 autorise explicitement des valeurs négatives dans les champs de totaux (BT-106 à BT-115) et n’impose aucun schéma particulier. Deux conventions se sont établies dans la pratique.

D’abord le 381 avec des montants positifs : le type de document inverse lui-même le sens comptable, les montants ne chiffrent que la valeur créditée. Ensuite la facture négative : une 380 ou 384 avec des totaux négatifs, admise notamment par XRechnung depuis la version 2.0.

Ce qu’il faut éviter, c’est la combinaison : un 381 avec des totaux négatifs est doublement inversé, voire rejeté, par de nombreux systèmes destinataires. Choisissez un schéma — au besoin celui qu’indique le destinataire ou la plateforme — et tenez-le de bout en bout.

De bout en bout signifie : les règles arithmétiques BR-CO de l’EN 16931 calculent en valeurs signées et s’appliquent sans changement. BT-106 doit être la somme des montants de ligne, BT-112 doit valoir BT-109 + BT-110. Ne rendre négatif que le total final en laissant les lignes positives fait échouer la validation à coup sûr.

Erreurs de validation fréquentes

Sur les avoirs et rectificatives, cinq messages reviennent surtout. BH-TYPE-01 signale un code de type exotique tiré du catalogue UNTDID complet (comme 80 ou 261) — restez sur 380, 381, 384 et 326. BR-CO-10 se déclenche quand BT-106 ne correspond pas à la somme des montants nets de ligne (BT-131) — le grand classique : totaux inversés, lignes non. BR-CO-13 touche les rectificatives qui reprennent les remises ou majorations (BT-107/108) de la facture initiale sans inverser leur signe. BR-CO-14 relève un total de TVA qui ne correspond pas à la ventilation (BG-23) — typique quand on a oublié les montants par catégorie lors du changement de signe. Et BR-CO-15 attrape les totaux TTC calculés en valeurs absolues au lieu de la somme signée BT-109 + BT-110.

Valider avant l’envoi

Le validateur Billhorse contrôle le code de type, la référence à la facture initiale et toute l’arithmétique BR-CO directement dans le navigateur — le fichier ne quitte pas votre machine. Le même moteur existe en API avec les points d’accès validate et parse, actuellement en bêta privée.

← Tous les guides · Mis à jour: 2026-07-04