Aller au contenu principal

Référence

Export Markdown

BR-DE-23-b Un virement ne doit contenir ni données de carte (BG-18) ni données de prélèvement (BG-19)

Selon la règle allemande XRechnung BR-DE-23-b, un moyen de paiement dont BT-81 porte un code de virement (30 ou 58) ne doit pas contenir en plus des informations de carte de paiement (BG-18) ni des informations de prélèvement (BG-19). XRechnung associe chaque code de moyen de paiement à un seul groupe : BR-DE-23 couvre le virement, BR-DE-24 la carte de paiement et BR-DE-25 le prélèvement. En UBL, le validateur signale l’erreur lorsque cac:CardAccount ou cac:PaymentMandate figure dans le même cac:PaymentMeans. En CII, il la signale lorsque le moyen de paiement contient ram:ApplicableTradeSettlementFinancialCard ou ram:PayerPartyDebtorFinancialAccount/ram:IBANID, ou lorsque le règlement d’en-tête contient une référence de mandat (ram:DirectDebitMandateID, BT-89) ou un identifiant créancier (ram:CreditorReferenceID, BT-90). KoSIT classe l’erreur comme fatale.

Description du problème

ERREUR

Règle nationale allemande XRechnung (KoSIT, BR-DE) · XRechnung 3.0

Chaîne de validation interactive

Cliquez sur une étape pour voir ce qu’elle contrôle, ou saisissez un identifiant de règle pour trouver l’étape qui la signale.

Essayer:

BR-DE-23-b règle XRechnung (Allemagne)

Signalée à l’étape 3 : Règles nationales (CIUS).

Niveau erreur : le rapport recommande de rejeter la facture.

Étape 3 · Ce qui est contrôlé

  • L’identifiant de spécification en BT-24 sélectionne le jeu de règles, par exemple XRechnung 3.0 ou Peppol BIS Billing 3.0.
  • XRechnung ajoute les règles allemandes BR-DE : référence acheteur (BT-10), contact du vendeur, instructions de paiement.
  • Peppol ajoute les règles PEPPOL-EN16931 et des règles par pays. XRechnung applique aussi certaines règles PEPPOL-EN16931.

Codes d’exemple

Correction type

Renseignez dans vos données de base les champs exigés par le jeu de règles, comme la Leitweg-ID en BT-10 ou le contact du vendeur.

Un validateur contrôle une facture électronique par étapes. D’abord, le fichier doit être un XML bien formé conforme au schéma UBL ou CII (XSD). Viennent ensuite les règles métier de l’EN 16931 : règles de base BR, calculs BR-CO, listes de codes BR-CL, décimales BR-DEC et règles par catégorie de TVA comme BR-S. Puis les règles nationales ou de réseau sélectionnées par BT-24 : BR-DE pour XRechnung, PEPPOL-EN16931 pour Peppol BIS Billing. Le rapport liste chaque règle en échec : une erreur signifie rejet, des avertissements seuls signifient toujours acceptation. BR-DE-23-b : règle XRechnung (Allemagne), étape « Règles nationales (CIUS) ». Jeux de règles : validateur KoSIT 1.6.3 avec la configuration XRechnung du 31 août 2026 (artefacts EN 16931 1.3.16), Peppol BIS Billing 3.0.21.

Contexte et importance

L’erreur provient le plus souvent de modèles ERP qui remplissent tous les champs de paiement à partir de la fiche client, par exemple un mandat SEPA enregistré ou l’identifiant créancier, alors que la facture est réglée par virement. En UBL, le contrôle se limite au cac:PaymentMeans qui porte le code de virement. En CII, BT-89 et BT-90 se trouvent au niveau de l’en-tête : une facture CII qui propose un virement (30 ou 58) enfreint donc BR-DE-23-b dès qu’elle contient aussi une référence de mandat ou un identifiant créancier.

Solution

Déterminez le moyen de paiement proposé par la facture et n’exportez que son groupe. Pour un virement, conservez BG-17 avec le compte dans BT-84 et supprimez les données de carte et de mandat : en UBL, retirez cac:CardAccount et cac:PaymentMandate du <cac:PaymentMeans> portant le code 30 ou 58. En CII, retirez ram:ApplicableTradeSettlementFinancialCard et ram:PayerPartyDebtorFinancialAccount du moyen de paiement, puis supprimez ram:DirectDebitMandateID et ram:CreditorReferenceID du règlement d’en-tête. Si l’acheteur paie par prélèvement SEPA, indiquez 59 dans BT-81 et transmettez BG-19 au lieu de BG-17.

Actions rapides

Valider le XMLConvertir la facture

Exemples valides

  • BT-81 = 58 avec BG-17 (IBAN dans BT-84), sans données de carte ni de mandat dans le même moyen de paiement
  • CII : TypeCode 30 avec BG-17, sans ram:DirectDebitMandateID ni ram:CreditorReferenceID dans le règlement d’en-tête

Exemples invalides

  • UBL : le cac:PaymentMeans au code 58 contient cac:PayeeFinancialAccount et aussi cac:PaymentMandate avec une référence de mandat
  • CII : moyen de paiement au TypeCode 58, mais ram:CreditorReferenceID (BT-90) de l’en-tête est rempli à partir de la fiche client
  • UBL : code 30 accompagné d’un cac:CardAccount contenant les quatre derniers chiffres de la carte

Exemples de code

XML valide
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE89370400440532013000</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
XML invalide
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE89370400440532013000</cbc:ID>
  </cac:PayeeFinancialAccount>
  <cac:PaymentMandate>
    <cbc:ID>MANDATE-2026-001</cbc:ID>
  </cac:PaymentMandate>
</cac:PaymentMeans>

Champs concernés

BT-81 Code du type de moyen de paiement
BG-18 Informations sur la carte de paiement
BG-19 Prélèvement

Outils de validation

Validateur KoSIT officiel

Exécutez le validateur officiel du KoSIT avec la configuration XRechnung pour contrôler les règles EN 16931 et XRechnung.

Convertir un PDF en XRechnung

Repérez les erreurs de validation pendant la conversion et vérifiez chaque correction.