Note de crédit en UBL : deux variantes et quand choisir laquelle

Les deux manières d'envoyer une note de crédit en UBL : le document CreditNote et la facture négative (Invoice). Quand choisir quelle variante ?

Parfois, une facture doit être corrigée. Un montant trop élevé, un taux de TVA erroné, un retour de marchandises : la solution est une note de crédit. Dans la norme UBL, il existe deux manières d'envoyer une note de crédit. Elles sont techniquement très différentes, mais servent le même objectif. La variante que vous choisissez dépend de votre logiciel, de votre destinataire et du profil Peppol que vous utilisez.

Variante 1 : le document CreditNote

La première variante est un type de document UBL distinct : CreditNote. Ce document utilise son propre schéma XML (CreditNote-2) et possède ses propres noms d'éléments. Au lieu de InvoiceLine, on trouve CreditNoteLine, et au lieu de InvoicedQuantity, on trouve CreditedQuantity.

<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2">
  <cbc:ID>CN-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-03-08</cbc:IssueDate>
  <cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>F-2026-00042</cbc:ID>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <!-- parties, totaux TVA, etc. -->
  <cac:CreditNoteLine>
    <cbc:ID>1</cbc:ID>
    <cbc:CreditedQuantity unitCode="EA">5</cbc:CreditedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">125.00</cbc:LineExtensionAmount>
    <!-- article et prix -->
  </cac:CreditNoteLine>
</CreditNote>

Tous les montants dans un CreditNote sont positifs. Le fait qu'il s'agisse d'un document CreditNote indique implicitement qu'il s'agit d'une correction. L'élément BillingReference fait référence à la facture originale qui est créditée.

Caractéristiques du document CreditNote
  • Noeud racine XML propre (CreditNote au lieu de Invoice)
  • Noms d'éléments propres (CreditNoteLine, CreditedQuantity)
  • Tous les montants sont positifs
  • Largement supporté par les destinataires Peppol
  • TypeCode est 381 (credit note related to invoices)
Variante 2 : la facture négative (Invoice)

La deuxième variante utilise le document Invoice standard, mais avec des montants négatifs. Le InvoiceTypeCode reste 380 (facture commerciale). Techniquement, il s'agit d'une facture ordinaire, mais les montants négatifs lui confèrent la fonction de note de crédit. C'est la convention néerlandaise décrite dans le UBL Ketentest du bureau de recherche GBNED.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ID>CN-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-03-08</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>F-2026-00042</cbc:ID>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <!-- parties, totaux TVA, etc. -->
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="EA">-5</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">-125.00</cbc:LineExtensionAmount>
    <!-- article et prix -->
  </cac:InvoiceLine>
</Invoice>

Avec cette variante, les quantités et les montants sont négatifs. Le montant de TVA et le montant à payer sont également négatifs. La structure est par ailleurs identique à celle d'une facture ordinaire.

Caractéristiques de la facture négative (Invoice)
  • Même noeud racine XML qu'une facture ordinaire (Invoice)
  • Mêmes noms d'éléments (InvoiceLine, InvoicedQuantity)
  • Montants et quantités sont négatifs
  • InvoiceTypeCode est 380 (facture ordinaire), le signe négatif indique qu'il s'agit d'un avoir
  • Plus simple à implémenter pour le logiciel émetteur (pas besoin d'un type de document distinct)
  • Décrite dans le GBNED/UBL Ketentest comme la méthode standard néerlandaise
Quelle variante choisir ?

Le choix dépend de trois facteurs :

Que supporte votre logiciel ? Certains logiciels de comptabilité génèrent par défaut un document CreditNote, d'autres une facture négative (Invoice). Si votre logiciel ne supporte qu'une seule variante, le choix est fait.

Qu'attend le destinataire ? Au sein de Peppol, les deux variantes sont supportées par le profil BIS Billing 3.0. En pratique, les systèmes récepteurs peuvent toutefois avoir une préférence. En cas de doute, le document CreditNote est le choix le plus sûr, car c'est la variante la plus explicite.

Quel profil Peppol utilisez-vous ? Le profil standard BIS Billing 3.0 accepte aussi bien le schéma CreditNote (381) que le schéma Invoice avec des montants négatifs (380). Tous les profils ne supportent pas les deux. Vérifiez cela si vous utilisez un profil sectoriel spécifique.

Conseil : avec eConnect, vous pouvez envoyer les deux variantes. La plateforme reconnaît automatiquement s'il s'agit d'un document CreditNote ou d'une facture négative (Invoice), et les traite de la même manière. Si le destinataire attend un format spécifique, le PSB transforme automatiquement le document.

Conventions de signe comparées

Les deux variantes utilisent des conventions de signe opposées. Ce tableau montre comment le même avoir (5 unités de 25 euros) se présente dans les deux variantes :

ÉlémentCreditNote (TypeCode 381)Facture négative (TypeCode 380)Schéma XMLCreditNoteInvoicePriceAmount25,00 (positif)25,00 (positif, obligatoire selon BR-27)CreditedQuantity / InvoicedQuantity5 (positif)-5 (négatif)LineExtensionAmount125,00 (positif)-125,00 (négatif)Montants AllowanceChargepositifsnégatifsTaxAmountpositifnégatifPayableAmountpositifnégatif

La différence essentielle réside dans l'interprétation. Dans un CreditNote, le signe inverse est implicite : tous les montants sont positifs, mais le type de document indique clairement qu'il s'agit d'un avoir. Dans une facture négative, ce sont les montants négatifs eux-mêmes qui servent d'indicateur.

Le PriceAmount (le prix unitaire) est positif dans les deux variantes. Cela est défini par la règle de validation BR-27. Dans la facture négative, vous rendez le montant négatif via la quantité ou via le LineExtensionAmount, pas via le prix unitaire.

Les rôles des parties ne changent pas lors d'un avoir (Supplier/Customer/Payee)

Variantes de recherche : "avoir Payee propre organisation", "note de crédit destinataire fournisseur", "Payee à la place du fournisseur avoir", "Supplier Customer inverser sur avoir", "à payer vs à recevoir PayableAmount".

Débit et crédit n'impliquent pas d'inversion des parties. AccountingSupplierParty reste le fournisseur et AccountingCustomerParty reste l'acheteur, même sur un avoir. Le fait que l'acheteur doive payer ou recevoir découle du type de document et du signe de PayableAmount (voir tableau ci-dessus) : sur une facture négative (380), PayableAmount est négatif, donc l'acheteur reçoit ; sur un CreditNote (381) les montants sont positifs et le crédit est exprimé par le type de document.

Le PayeeParty optionnel n'est pertinent que lorsque le montant doit être transféré à une autre partie, par exemple en cas d'affacturage. Ce n'est pas la même chose que le « destinataire de l'avoir » au sens informel. Si la propre organisation apparaît dans un champ Payee ou destinataire alors que Supplier et Customer sont déjà corrects, vérifiez d'abord s'il s'agit de données PayeeParty/PaymentMeans optionnelles avant de demander une correction.

eConnect ne réécrit pas les rôles des parties à la réception et n'applique pas automatiquement une correction Payee antérieure si l'UBL source est déjà correct. Les factures sont traitées telles qu'elles sont soumises ; les données de parties incorrectes doivent être corrigées par l'expéditeur dans l'UBL source. Voir aussi Traitement UBL.

Changement silencieux de signe prix/quantité (BIS3 / BR-27)

Variantes de recherche : "silent price/quantity sign change during BIS3 transformation", "negative unit price mapping", "prix unitaire négatif", "changement de signe prix quantité", BR-27 PriceAmount.

Le prix net de l'article (BT-146 / PriceAmount) ne doit pas être négatif (BR-27). Avec une facture négative (TypeCode 380), le prix unitaire reste positif ; le signe moins se trouve sur la quantité (BT-129) et sur les montants de ligne et totaux. CreditNote (381) garde prix et quantité positifs ; le crédit est exprimé par le type de document. Lors de la normalisation ou de la transformation entre les schémas CreditNote et facture négative (notamment par la PSB), un déplacement silencieux de signe entre prix et quantité est un comportement attendu pour respecter BR-27 — pas un bug de plugin. Données source avec prix unitaires négatifs : mapper côté intégration vers un prix positif plus le signe sur la quantité ou le type de document, conformément au tableau ci-dessus.

Convention néerlandaise et Peppol

Le UBL Ketentest du bureau de recherche GBNED décrit exclusivement la variante 380 (facture négative) pour les notes de crédit. De nombreux logiciels de comptabilité néerlandais certifiés "UBL Ready" génèrent donc par défaut une facture négative. Peppol BIS 3.0 utilise en revanche par défaut le schéma CreditNote (381) avec des montants positifs.

Les logiciels récepteurs doivent supporter les deux variantes. Le PSB transforme automatiquement entre les deux schémas si nécessaire, de sorte que le destinataire reçoive le document dans le format attendu par son logiciel.

Ce qui doit toujours figurer

Quelle que soit la variante choisie, une note de crédit valide contient toujours :

  • Une référence à la facture originale via BillingReference / InvoiceDocumentReference
  • Le TypeCode correct : 381 pour le schéma CreditNote, 380 pour la facture négative
  • Un calcul de TVA correct (conforme à la facture originale)
  • La même devise que la facture originale

Une note de crédit sans référence à la facture originale est refusée par de nombreux systèmes récepteurs. Cette référence est en outre nécessaire pour l'administration de la TVA : lors d'un contrôle, il doit être possible de retracer quelle facture a été créditée.

Correction d'une facture déjà envoyée

Variantes de recherche : "aide avoir", "creer une note de credit", "note de credit portail", "note de credit facture deja envoyee", "creer facture corrective Invoice Portal", "crediter facture en double", "facture en double note de credit", "deux fois la meme facture crediter", "comment creer une note de credit".

Une facture déjà envoyée via Peppol (ou un autre canal) ne peut plus être modifiée -- seules les factures encore en brouillon peuvent l'être. Une erreur dans une facture envoyée se corrige toujours avec un nouveau document, jamais en modifiant l'original. Il n y a pas de bouton separe Avoir dans le portail; choisissez le type de facture Facture corrective (libelle UI). Le flux comptable standard :

Étape 1 : Créditez la facture originale

Envoyez une facture rectificative ou une note de crédit qui référence le numéro de la facture originale via BillingReference/InvoiceDocumentReference. Sur la plateforme : choisissez le type Facture rectificative lors de la création et indiquez le numéro de la facture originale dans le champ référence.

Étape 2 : Émettez une nouvelle facture correcte

Créez une nouvelle facture avec un nouveau numéro unique. Un numéro identique à l'original peut être bloqué par la détection de doublons.

Conventions de signe : avec le schéma CreditNote (381), les montants doivent être positifs -- le type de document exprime le crédit. Avec la facture négative (380), rendez la quantité négative en gardant le prix unitaire positif (BR-27). Des quantités accidentellement positives génèrent une « facture de crédit » positive qui ne peut pas être traitée comme un avoir.

Nouveau numéro obligatoire : si vous créez une nouvelle facture en copiant l'original, attribuez toujours un nouveau numéro. Voir aussi Détection des doublons.

TypeCode 384 : facture rectificative

Outre les TypeCodes 380 et 381, le TypeCode 384 (facture rectificative) existe. Ce type de document peut contenir des montants positifs et négatifs dans le même document, destiné aux cas où l'on crédite et facture en supplément simultanément. NLCIUS recommande le 384 plutôt que les notes de crédit pour des raisons de lisibilité. Attention : le TypeCode 384 n'est pas disponible dans tous les profils -- il n'est par exemple pas supporté dans le profil standard BIS Billing V3.

Aperçu des InvoiceTypeCodes les plus utilisés
CodeSignificationContexte380Facture commercialeFacture standard381Note de créditCrédit standard383Note de débitCorrection avec montant supplémentaire384Facture rectificativePositif et négatif dans un seul document386Facture d'acompteScénario de paiement anticipé389Facture de self-billingFacture établie par l'acheteur261Note de crédit de self-billingNote de crédit en contexte self-billing
Avoir partiel

Il n'est pas obligatoire de créditer une facture dans son intégralité. Vous pouvez également envoyer une note de crédit partielle qui ne corrige qu'une partie de la facture originale. Si vous créditez par exemple deux des dix articles facturés, la note de crédit ne contient que ces deux lignes avec les montants correspondants.

Conseil : si vous envoyez des factures via l'API PSB, vous pouvez spécifier lors du téléchargement d'un document, via le paramètre targetDocumentTypeId, si vous souhaitez recevoir une variante CreditNote ou Invoice. Le PSB peut transformer à la volée entre les deux variantes.

Validez votre note de crédit