The credit account identifier is not a valid IBAN for a SEPA transfer

When `Payment means type code` (BT-81) is 58 (SEPA credit transfer), `Payment account identifier` (BT-84) must be a correct IBAN — both its shape and its check digits.

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-19] "Payment account identifier" (BT-84) soll eine korrekte IBAN enthalten, wenn in "Payment means type code" (BT-81) mit dem Code 58 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-19 The credit account identifier is not a valid IBAN for a SEPA transferBR-DE-19 XRechnung Schematron package (KoSIT)BR-DE-19 BT-84[BR-DE-19] "Payment account identifier" (BT-84) soll eine korrekte IBAN enthalten, wenn in "Payment means type code" (BT-81) mit dem Code 58 SEPA als Zahlungsmittel gefordert wird.BR-DE-19 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.

Open the validator See the API

Why this error happens

The rule recomputes the check digits, it does not merely look at the shape. It therefore catches the transposed digit in a hand-typed IBAN, which nothing else detects before the bank rejects the payment. Presentation spaces are stripped before the check: formatting is never what fails.

How to fix it

Fix the IBAN in your bank master data. Factlint never writes it, even when it is supplied explicitly: the IBAN is named as a financial field (rule 1), and an automatic correction of payment details is exactly the write a fraudster would try to induce.

Severity returned by the rule set

The XRechnung package classifies this rule as `warning` — a doubtful IBAN does not stop the document from being formally compliant. An in-scope warning still rules out a “compliant” verdict — at best the invoice comes out as `needs_input`. The bank, for its part, will not return a warning.

XML correction example

BEFORE (invalid)

<ram:TypeCode>58</ram:TypeCode> … <ram:IBANID>DE00123456789012345678</ram:IBANID>

AFTER (compliant)

<ram:IBANID>DE43123456789012345678</ram:IBANID>