Back to the error catalogue
BR-DE-20BT-91
input

Germany

The debited account identifier is not a valid IBAN for a SEPA direct debit

When `Payment means type code` (BT-81) is 59 (SEPA direct debit), `Debited account identifier` (BT-91) must be a correct IBAN.

Only the issuer holds this value: Factlint reports it and never fabricates it. Test your invoice to find out whether it is affected.

The message your validator prints

Copied verbatim from the sealed artefact: this is the exact sentence the check prints when this rule fails.

[BR-DE-20] "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.

Quoted from schematron-xrechnung 3.0.2, licensed under Apache-2.0.

Common searches around this code

These phrases mirror what an integrator searches for: code, syntax, rule, business field and correction.

BR-DE-20 The debited account identifier is not a valid IBAN for a SEPA direct debitBR-DE-20 XRechnung Schematron package (KoSIT)BR-DE-20 BT-91[BR-DE-20] "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 correction

Test your file with this error in mind

Upload the invoice involved: the report will say whether this code appears, where it appears in the document, and whether Factlint can only report it or also fix it.

To automate this check in an ERP flow, call the validation API and link every returned code to its public page.

Why this error happens

The mirror of BR-DE-19, on the debited account. Mistakes are more frequent here: the credit IBAN belongs to the seller and is captured once; the debit IBAN belongs to the customer and is copied from a mandate.

How to fix it

Fix the IBAN on the direct debit mandate. Factlint never writes it: it is a financial field (rule 1).

Severity returned by the rule set

The XRechnung package classifies this rule as `warning`. An in-scope warning still rules out a “compliant” verdict — at best the invoice comes out as `needs_input`.

XML correction example

BEFORE (invalid)
<ram:TypeCode>59</ram:TypeCode> … <ram:IBANID>DE00123456789012345678</ram:IBANID>
AFTER (compliant)
<ram:IBANID>DE43123456789012345678</ram:IBANID>