# 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

> **Où BR-DE-23-b est contrôlée**
>
> 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) ».

## 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.

- [Valider le XML](/fr/xrechnung-validator?source=resource&rule=BR-DE-23-b)
- [Convertir la facture](/fr/pdf-to-xrechnung?source=resource&rule=BR-DE-23-b)

## 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](/resources/xrechnung/bt-81-payment-means-type-code)
- [BG-18 Informations sur la carte de paiement](/resources/xrechnung/bt-87-payment-card-primary-account-number)
- [BG-19 Prélèvement](/resources/xrechnung/bt-89-mandate-reference-identifier)

## Règles associées

- [BR-DE-23-a](/resources/kosit-validator-errors/br-de-23-a-credit-transfer-requires-credit-transfer-group)
- [BR-DE-30](/resources/kosit-validator-errors/br-de-30-direct-debit-requires-creditor-identifier)
- [BR-DE-31](/resources/kosit-validator-errors/br-de-31-direct-debit-requires-debited-account)
- [PEPPOL-EN16931-R061](/resources/kosit-validator-errors/peppol-en16931-r061-direct-debit-mandate-reference-required)

## Outils de validation

- [Validateur KoSIT officiel](https://github.com/itplr-kosit/validator): 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](/pdf-to-xrechnung): Repérez les erreurs de validation pendant la conversion et vérifiez chaque correction.

## Ressources associées

- [Spécification officielle](https://xeinkauf.de/xrechnung/)
- [Suite de tests](https://github.com/itplr-kosit/xrechnung-testsuite)
- [Toutes les erreurs de validation](/resources/kosit-validator-errors): Vue d’ensemble des règles de validation EN 16931, XRechnung et Peppol expliquées ici.