BR-17 : Nommer le bénéficiaire, ou supprimer un bénéficiaire qui est le vendeur

La réponse courte

BR-17 échoue sur un cac:PayeeParty qui n'a pas de cac:PartyName/cbc:Name, ou dont le nom ou l'identifiant est le même que celui du vendeur. Lorsqu'une autre partie que le vendeur doit être payée, comme une société d'affacturage, donnez à ce bénéficiaire son propre nom dans cac:PayeeParty/cac:PartyName/cbc:Name. Lorsque le vendeur doit être payé, supprimez entièrement cac:PayeeParty.

Un bénéficiaire sans nom entraîne aussi UBL-SR-19, UBL-SR-20 et UBL-SR-21 sur le même élément, bien que rien n'y soit répété. Chacune de ces règles associe une limite d'une occurrence à un contrôle vérifiant que le nom du bénéficiaire diffère de la raison sociale du vendeur, et sans nom de bénéficiaire ce contrôle ne peut pas passer. Ajouter le nom lève les quatre constats.

Ce que la règle vérifie

La règle s'exécute sur chaque cac:PayeeParty et ne passe que si trois conditions sont réunies : un cac:PartyName/cbc:Name existe ; il n'est égal à aucun nom commercial du vendeur dans cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name ; et aucun cac:PartyIdentification/cbc:ID du bénéficiaire n'est égal à un cac:PartyIdentification/cbc:ID du vendeur.

Les deux comparaisons portent sur des chaînes exactes. Lors d'un essai, un bénéficiaire nommé Example Trading, le nom commercial du vendeur, a fait échouer BR-17 à lui seul, tout comme un bénéficiaire nommé autrement mais portant l'identifiant du vendeur 7300010000001. Un bénéficiaire nommé EXAMPLE TRADING a passé la règle, car la casse diffère, bien qu'il désigne la même entreprise.

Pour le nom, c'est la présence qui compte. Lors d'un essai, un cbc:Name de bénéficiaire vide a satisfait BR-17 et n'a été signalé que par PEPPOL-EN16931-R008.

La raison sociale du vendeur est comparée par les règles associées, pas par celle-ci. Lors d'un essai, un bénéficiaire nommé Example Supplier Ltd, le cbc:RegistrationName du vendeur, a passé BR-17 et a échoué à UBL-SR-19, UBL-SR-20 et UBL-SR-21.

L'identifiant du bénéficiaire est facultatif : lors d'un essai, un bénéficiaire portant seulement le nom Example Factoring Ltd a passé toutes les étapes.

Comment une intégration en arrive là

Causes possibles, déduites de la forme de la règle et non d'une utilisation mesurée :

• L'export écrit toujours cac:PayeeParty, rempli à partir de la fiche du vendeur, parce que le système source traite le vendeur comme bénéficiaire par défaut.
• Le bénéficiaire est stocké sous forme de référence ou de numéro de compte sans nom de partie : le générateur peut donc écrire cac:PartyIdentification mais pas cac:PartyName.
• Un accord d'affacturage ou de cession est enregistré sur la facture, et le bloc du bénéficiaire est construit à partir de la référence de l'accord sans rechercher le nom de la société d'affacturage.
• Le nom commercial du vendeur est copié dans le nom du bénéficiaire comme valeur provisoire lorsque le véritable bénéficiaire n'est pas connu.

Comment corriger le document

1. Déterminez si la facture doit être payée à quelqu'un d'autre que le vendeur. Le groupe bénéficiaire n'existe que pour ce cas, par exemple une créance affacturée ou cédée.
2. Si le vendeur est payé, retirez cac:PayeeParty de la sortie. Le compte sur lequel payer reste dans cac:PaymentMeans.
3. Si un tiers est payé, prenez son nom dans l'accord d'affacturage ou de cession et écrivez-le dans cac:PayeeParty/cac:PartyName/cbc:Name, après l'éventuel cac:PartyIdentification.
4. Donnez au bénéficiaire son propre identifiant, s'il en a un. N'y réutilisez jamais l'identifiant du vendeur, et ne modifiez pas le nom du vendeur pour faire passer la comparaison.
5. Envoyez au plus un nom de bénéficiaire, un identifiant de bénéficiaire autre qu'un identifiant de créancier SEPA, et un identifiant d'enregistrement légal ; UBL-SR-19, UBL-SR-20 et UBL-SR-21 limitent chacun d'eux à une seule occurrence.

Valider votre facture corrigée

Avant et après

Ce sont des extraits, pas des documents complets. Les documents synthétiques complets dont ils proviennent sont liés ci-dessous.

Fragment de la facture en échec : le bénéficiaire a un identifiant mais pas de nom

<cac:PayeeParty>
  <cac:PartyIdentification>
    <cbc:ID>PAYEE-001</cbc:ID>
  </cac:PartyIdentification>
</cac:PayeeParty>

Fragment de la facture corrigée : le bénéficiaire est nommé, et son nom diffère de celui du vendeur

<cac:PayeeParty>
  <cac:PartyIdentification>
    <cbc:ID>PAYEE-001</cbc:ID>
  </cac:PartyIdentification>
  <cac:PartyName>
    <cbc:Name>Example Factoring Ltd</cbc:Name>
  </cac:PartyName>
</cac:PayeeParty>

La facture corrigée comporte cac:PartyName avec Example Factoring Ltd après l'identifiant du bénéficiaire ; la facture en échec n'a que l'identifiant. En plus de BR-17, le document en échec signale UBL-SR-19, UBL-SR-20 et UBL-SR-21, tous sur cac:PayeeParty. Aucune de ces règles n'a trouvé de répétition : chacune exige aussi que le nom du bénéficiaire diffère du cbc:RegistrationName du vendeur, Example Supplier Ltd, et un nom absent échoue à cette comparaison. Une fois le nom ajouté, les quatre constats sont levés. Un second exemple enregistré ajoute un bénéficiaire nommé Example Trading, le nom commercial du vendeur, et ne signale que BR-17 ; dans ce cas, le bénéficiaire est le vendeur et doit être omis.

Où la règle s'applique

• Les avoirs portent le bénéficiaire au même endroit. Lors d'un essai, un avoir avec un bénéficiaire sans nom a signalé les quatre mêmes règles.
• Les quatre constats viennent de l'étape EN 16931 ; l'étape Peppol de la facture en échec ne signale rien au sujet du bénéficiaire.
• Seul cac:PartyIdentification/cbc:ID est comparé au vendeur. L'adresse électronique, l'identifiant TVA et l'identifiant d'enregistrement légal du vendeur n'interviennent pas dans cette règle.
• Un identifiant de créancier SEPA peut figurer dans le cac:PartyIdentification du bénéficiaire avec schemeID="SEPA". UBL-SR-20 l'exclut de son décompte des identifiants du bénéficiaire.

Règles liées

• BR-06 exige le RegistrationName du vendeur, la valeur à laquelle UBL-SR-19 à UBL-SR-21 comparent le nom du bénéficiaire
• BR-CL-10 contrôle le schéma d'un identifiant de bénéficiaire et y accepte SEPA
• PEPPOL-EN16931-R008 signale un élément de nom de bénéficiaire présent mais vide
• Parcourir toutes les règles de la référence
• Contexte (en anglais) : Understanding EN 16931 validation errors

Portée et source

Rédigé pour Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, tel qu'appliqué aux documents Invoice et CreditNote en UBL 2.1. D'autres profils, syntaxes et versions peuvent définir cet identifiant autrement. Version du catalogue d'aide 2026-09-24.1 : source vérifiée le 2026-09-24, explication mise à jour le 2026-09-24.

La définition officielle de BR-17 (en anglais) contient le texte normatif et le test. Cette page en est notre explication, pas une copie.

Cette aide ne modifie pas le verdict du moteur. Corriger ce constat ne signifie pas que le document passe toutes les étapes de validation, et la validation ne certifie pas la conformité juridique ou fiscale et ne transmet aucun document via Peppol.