# Avoirs et factures rectificatives
> https://billhorse.com/fr/guides/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)](/fr/termes/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` :
```xml
384
381
381
```
## 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](/fr/termes/bg-3/) : le numéro de la facture antérieure ([BT-25](/fr/termes/bt-25/)) et, en option, sa date d'émission ([BT-26](/fr/termes/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 :
```xml
FA-2026-0417
2026-05-12
```
En CII, la référence se place dans `ApplicableHeaderTradeSettlement` ; comme toujours, la date exige `format="102"` (AAAAMMJJ) :
```xml
FA-2026-0417
20260512
```
## 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](/fr/regles/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](/fr/regles/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](/fr/regles/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](/fr/regles/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](/fr/regles/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](/fr/) 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](/fr/api/) avec les points d'accès validate et parse, actuellement en bêta privée.