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
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.
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-84- Severity
warning
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"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 locates the element in the generated UBL document,
which is where a KoSIT or Peppol validator will report the same problem.
A passing value
"payment": { "meansCode": "58", "iban": "DE02120300000000202051" }The 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.