Attestwire › Rule reference › BR-DE-25-b

BR-DE-25-b A direct debit code rules out transfer and card data

noun · XRechnung · fatal · BG-17

Your invoice was refused because it names SEPA direct debit as the payment method but also carries a credit transfer IBAN or card data. Each payment method takes exactly one data group, so remove the extra data or change the payment method. In the standard these are groups BG-17 and BG-18, with payment means code 59 in BT-81; BR-DE-25-b is the rule that rules them out.

Diese Regel auf Deutsch: BR-DE-25-b — auf Deutsch erklärt.

Business term

BG-17 — Payment means type code

Severity

fatal

Applies to

xrechnung-ubl, xrechnung-cii

The fix

Remove the credit transfer IBAN (payment.iban) and any card data (payment.card), and keep only the direct debit details (payment.directDebit, BG-19). If a credit transfer was meant after all, change payment.meansCode to "58" instead.

What the rule requires

With payment means code 59, BG-17 (credit transfer) and BG-18 (payment card information) must be absent. Only the direct debit group BG-19 remains.

The most common trigger: your own IBAN is written from the master record into every invoice, including the ones collected by direct debit.

In this library BG-17 is payment.iban and BG-18 is payment.card.

Wenn BT-81 "Payment means type code" einen Schlüssel für Lastschriften enthält (59), dürfen BG-17 und BG-18 nicht übermittelt werden.

A passing value

"payment": { "meansCode": "59", "directDebit": { "mandateReference": "MANDAT-2026-01", "creditorIdentifier": "DE98ZZZ09999999999", "debitedAccount": "DE98700500001234567890" } }

Why it exists

An invoice that says both “we will collect” and “please transfer to this account” is ambiguous, and ambiguity about payment leads to paying twice or not at all. The German rules prevent that by letting the payment method allow exactly one group.

What the library returns

The full error returned by @attestwire/en16931. It includes the rule ID, affected field and suggested correction. Developers can use this object in their application:

{
  "rule": "BR-DE-25-b",
  "field": "BG-17",
  "severity": "fatal",
  "message": "The payment means type code (BT-81) is \"59\", which XRechnung treats as a direct debit (code 59), so the CREDIT TRANSFER (BG-17) group must not be present — but it is. A payment instruction that names one settlement method and then supplies the account details of another is not merely redundant: the payer's system reads the code, looks for the matching group, and has no rule for what to do with the extra one. XRechnung closes that ambiguity by forbidding it outright.",
  "fix": "Remove payment.iban, keeping only payment.directDebit (BG-19). If you meant the other method, change payment.meansCode to match it instead — the code is what decides which group is required.",
  "example": "\"payment\": { \"meansCode\": \"59\", \"directDebit\": { \"mandateReference\": \"MANDAT-2026-01\", \"creditorIdentifier\": \"DE98ZZZ09999999999\", \"debitedAccount\": \"DE98700500001234567890\" } }",
  "xpath": "/ubl:Invoice/cac:PaymentMeans/cac:PayeeFinancialAccount",
  "docsUrl": "https://attestwire.com/rules/BR-DE-25-b"
}

xpath is always a UBL path. On a CII invoice, look for the matching CII field instead.

How our check differs

See also: BR-DE-25-a — the other half: the direct debit group must be there.