UBL-SR-47 : Utiliser le même code de moyen de paiement dans chaque PaymentMeans

La réponse courte

UBL-SR-47 échoue lorsque les valeurs de cbc:PaymentMeansCode d'un document ne sont pas toutes identiques. L'exemple enregistré propose un compte sous 30, virement, et un second sous 58, virement SEPA. Choisissez le code unique qui décrit comment la facture doit être payée et utilisez-le dans chaque cac:PaymentMeans.

Répéter cac:PaymentMeans est la façon dont UBL énumère plusieurs comptes pour le même mode de paiement. Ce n'est pas un moyen de proposer des modes de paiement différents, car le modèle n'a qu'un code de type de moyen de paiement par facture.

Ce que la règle vérifie

La règle s'exécute une fois sur la racine du document, rassemble chaque cbc:PaymentMeansCode et échoue lorsqu'elle trouve plus d'une valeur distincte. Un nombre quelconque de moyens de paiement partageant un code réussit, comme le montre la facture corrigée avec deux moyens sous 30.

Les codes sont comparés tels qu'ils sont écrits, sans nettoyage. Lors d'un essai, 30 avec un espace initial à côté de 30 a fait échouer cette règle, alors que BR-CL-16 a accepté les deux comme le code 30.

Tout mélange de modes échoue de la même façon. Lors d'un essai, un paiement par carte sous 48, donnant les quatre derniers chiffres de la carte, à côté d'un virement sous 30 a signalé cette règle et rien d'autre.

L'attribut facultatif name du code n'est pas comparé. Lors d'un essai, donner au premier code name="Credit transfer" et aucun au second 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 :

• La facture énumère chaque façon dont le fournisseur accepte d'être payé, comme un virement et une carte, sous forme de moyens de paiement distincts.
• Les comptes nationaux et les comptes en euros sont exportés avec le code de leur propre système, 30 pour l'un et 58 pour le compte SEPA.
• Les moyens de paiement sont copiés d'un profil fournisseur dans lequel chaque compte a son propre code, et chaque compte se retrouve dans chaque facture.
• Un code est complété, ou lu dans un champ à largeur fixe, à un seul endroit, si bien qu'une copie porte un espace.

Comment corriger le document

1. Choisissez le type de moyen de paiement unique de cette facture. Si l'acheteur peut utiliser l'un ou l'autre de deux comptes pour un virement, un seul code de virement couvre les deux ; 30 est le code général du virement.
2. Écrivez ce code, nettoyé et identique, dans chaque cac:PaymentMeans.
3. Laissez hors de la facture les moyens de paiement d'autres modes, comme une carte. Si l'acheteur doit les connaître, décrivez-les dans la note des conditions de paiement.
4. Gardez un cac:PayeeFinancialAccount dans chaque moyen de paiement, avec son identifiant, comme BR-61 l'exige pour les virements.

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 second compte est proposé en virement SEPA, code 58

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <!-- first payee account omitted from this fragment -->
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Fragment de la facture corrigée : les deux comptes sont proposés sous le code 30

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <!-- first payee account omitted from this fragment -->
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Dans la facture en échec, le second cac:PaymentMeans utilise le code 58 ; dans la facture corrigée, il utilise 30, comme le premier. Le compte et la référence de paiement sont identiques dans les deux. Seul UBL-SR-47 est signalé, sur la racine du document : 58 est un code autorisé, et chaque moyen de paiement remplit à lui seul les exigences d'un virement.

Où la règle s'applique

• S'applique à Invoice et à CreditNote. Lors d'un essai, un avoir avec des moyens de paiement sous 30 et 58 a aussi signalé cette règle.
• Signalée par l'étape EN 16931 dans le cadre de la syntaxe UBL.
• Un moyen de paiement unique sous 58 ne pose pas de problème. Lors d'un essai, la facture d'exemple à un seul compte, dont le code est passé de 30 à 58, a passé toutes les étapes.
• La référence de paiement est limitée à une seule valeur de la même façon, par UBL-SR-44.

Règles liées

• UBL-SR-44 n'admet qu'une seule référence de paiement distincte dans l'ensemble des moyens de paiement
• BR-CL-16 vérifie que chaque code de moyen de paiement figure dans la liste autorisée
• BR-61 exige le compte du bénéficiaire dans chaque moyen de paiement codé comme un virement
• UBL-SR-48 est une autre règle de syntaxe UBL qui ramène un élément répétable à ce que le modèle permet : une catégorie de taxe par ligne
• 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-28.1 : source vérifiée le 2026-09-28, explication mise à jour le 2026-09-28.

La définition officielle de UBL-SR-47 (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.