Attestwire

Rule reference

BR-DE-20 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

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.

This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.

Business term
BT-91
Severity
warning

What the library returns

The exact object in result.errors when this rule fires. Generated by running @attestwire/en16931, not transcribed:

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 locates the element in the generated UBL document, which is where a KoSIT or Peppol validator will report the same problem.

A passing value

the shape this field expects
"directDebit": { "debitedAccount": "DE98700500001234567890" }

The 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.

All 292 rules →

Nearby: BR-DE-22 — Two embedded attachments carry the same filename "a.pdf" — supportingDocuments[0] and supportingDocuments[1]; BR-DE-19 — 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; BR-DE-23-a — The payment means type code (BT-81) is "58", which XRechnung treats as a credit transfer, so the CREDIT TRANSFER group (BG-17) must be present.

Check this rule against your invoice via the hosted API → https://api.attestwire.com/docs

Arrived from a stack trace? The docsUrl on every error links straight here. Something wrong on this page — tell us.