Attestwire › Rule reference › BR-DE-19

BR-DE-19 The IBAN on a SEPA credit transfer must check out

noun · XRechnung · warning · BT-84

an IBAN that doesn’t add up. Literally.

Your invoice has been flagged because the bank account number on it, the IBAN, does not pass its own built-in check: one character is probably mistyped. KoSIT, the German office that publishes the official checker, treats this as a warning, so the invoice is accepted, but a bank rejects a transfer to an IBAN with wrong check digits, so the payment goes nowhere. In the standard the account field is BT-84, and BR-DE-19 is the XRechnung rule that checks it.

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

Business term

BT-84 — Payment account identifier

Severity

warning

Applies to

xrechnung-ubl, xrechnung-cii

The fix

Check the IBAN against your bank’s own record, not a formatted statement or a PDF letterhead, and correct it in payment.iban. Validate it once when it is entered rather than every time it is used. If you store it with spaces for display, store the compact form as well and send that.

If the checksum fails on a number you are certain is right, check for a lookalike character first: a typed O for a zero, or a non-breaking space pasted in from a document.

What the rule requires

When the payment method is a SEPA credit transfer (payment means code BT-81 of 58), the payment account identifier (BT-84) should be a valid IBAN.

Valid means two things: the right shape for the country, and check digits that agree with the rest of the number. Positions 3 and 4 of an IBAN are a checksum over everything else, computed with ISO 7064 MOD-97-10, which is why a single mistyped character makes them disagree, and why this check catches transcription errors that a length test misses.

Spaces are tolerated and stripped. Nothing else is.

Failing and passing

validateInput({
  profile: "xrechnung-ubl",
  // ...
  payment: {
    meansCode: "58",
    iban: "DE02120300000000202052",   // <- BR-DE-19, last digit changed
  },
});
// -> { valid: true, warnings: [ { rule: "BR-DE-19", severity: "warning", ... } ] }
// note: valid stays TRUE. This one is in result.warnings.

validateInput({
  profile: "xrechnung-ubl",
  // ...
  payment: {
    meansCode: "58",
    iban: "DE02120300000000202051",
    accountName: "Acme GmbH",
  },
});
// -> { valid: true, errors: [] }

Why it exists

An IBAN with bad check digits is almost always a right account, typed wrong. What happens next is the problem: the invoice is accepted, it is approved, it goes into a payment run, and the bank rejects the transfer because the check digits do not match.

The checksum exists so that a typo is caught at the desk rather than at the bank, and validating it before you send the invoice is the cheapest place in the whole chain to catch it.

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-19",
  "field": "BT-84",
  "severity": "warning",
  "message": "The payment means type code (BT-81) is \"58\" (SEPA credit transfer), so the payment account identifier (BT-84) should be a valid IBAN — but \"DE02120300000000202052\" fails the ISO 7064 MOD-97-10 check digits. The two digits in positions 3 and 4 are a checksum over the rest of the number, so a single mistyped character makes them disagree: this is almost always a transcription error rather than a wrong account. KoSIT raises this as a warning rather than an error, so the invoice will be accepted; the payment, however, will not go anywhere.",
  "fix": "Set payment.iban to the receiving account's IBAN. Spaces are tolerated and stripped, but nothing else is — take the value from your bank's own record rather than from a formatted statement.",
  "example": "\"payment\": { \"meansCode\": \"58\", \"iban\": \"DE02120300000000202051\" }",
  "xpath": "/ubl:Invoice/cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID",
  "docsUrl": "https://attestwire.com/rules/BR-DE-19"
}

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-23-a — code 58 obliges the credit transfer group to exist; BR-DE-20 — the same check on a direct-debit account; BR-DE-1 — why payment instructions are mandatory at all.