Attestwire › Rule reference › BR-DE-20

`BR-DE-20` A SEPA direct debit needs a valid IBAN for the debited account

noun · XRechnung · warning · BT-91

Your invoice carries a warning because the IBAN of the account you want to collect from does not add up. The check digits are verified under ISO 7064 MOD-97-10, and a typing error is almost always the cause. Take the IBAN from the signed mandate. In the standard the field is BT-91, used with payment means code 59 in BT-81; BR-DE-20 is the rule that recomputes the check digits.

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

Business term: BT-91 — Debited account identifier
Severity: warning
Applies to: xrechnung-ubl, xrechnung-cii

The fix

Copy the IBAN from the signed mandate, as the stored value rather than retyped, into payment.directDebit.debitedAccount.

What the rule requires

With payment means code 59 (SEPA direct debit), BT-91 must hold an IBAN whose check digits work out. It is the payer’s account, not yours.

Take the value from the signed mandate, not from a bank statement and not from an email. Do not retype it and do not normalise it; use the stored value.

In this library the field is payment.directDebit.debitedAccount.

"Debited account identifier" (BT-91) soll eine korrekte IBAN enthalten, wenn in "Payment means type code" (BT-81) mit dem Code 59 SEPA als Zahlungsmittel gefordert wird.

BR-DE-20 — KoSIT XRechnung Schematron 2.6.0 (XRechnung 3.0), XRechnung-UBL-validation.sch

A passing value

the shape this field expects

"directDebit": { "debitedAccount": "DE98700500001234567890" }

Why it exists

Here an error weighs more than under BR-DE-19. A wrong IBAN on a credit transfer means nobody pays you. A wrong IBAN on a direct debit means you try to collect from an account that is not the one on the mandate: an unauthorised debit, with a return, bank charges and an annoyed customer.

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:

TeachingError

{
  "rule": "BR-DE-20",
  "field": "BT-91",
  "severity": "warning",
  "message": "The payment means type code (BT-81) is \"59\" (SEPA direct debit), so the debited account identifier (BT-91) should be a valid IBAN — but \"DE98700500001234567891\" fails the ISO 7064 MOD-97-10 check digits. Positions 3 and 4 are a checksum over the rest of the number, so a single mistyped character makes them disagree. This matters more here than it does for your own account under BR-DE-19: a wrong IBAN on a credit transfer means nobody pays you, while a wrong IBAN on a direct debit means you attempt to collect from an account that is not the one on the mandate.",
  "fix": "Set payment.directDebit.debitedAccount to the IBAN written on the signed mandate. Do not retype it from a bank statement, and do not normalise it — take the stored value.",
  "example": "\"directDebit\": { \"debitedAccount\": \"DE98700500001234567890\" }",
  "xpath": "/ubl:Invoice/cac:PaymentMeans/cac:PaymentMandate/cac:PayerFinancialAccount/cbc:ID",
  "docsUrl": "https://attestwire.com/rules/BR-DE-20"
}

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

How our check differs

A warning, as KoSIT has it, so the invoice stays valid. We strip spaces, check the shape (two letters, two check digits, up to thirty letters or digits) and then the MOD-97-10 checksum. As in KoSIT’s own expression, only the country code is upper-cased before the checksum, so a lower-case letter later in the IBAN fails.

Whether the account exists, or matches the mandate, no check can tell. If the account is missing altogether, the finding is BR-DE-31 instead.

See also: BR-DE-19 — the same check for your own account on a credit transfer; BR-DE-31 — the rule that requires the debited account at all.