attestwireAttestwire › Rule reference › BR-DE-23-b
BR-DE-23-b A credit transfer code rules out card and direct debit details
noun · XRechnung · fatal · BG-18
For a sample invoice, the library reports: The payment means type code (BT-81) is "58", which XRechnung treats as a credit transfer (codes 30 and 58), so the PAYMENT CARD INFORMATION (BG-18) group must not be present — but it is.
Diese Regel auf Deutsch: BR-DE-23-b — auf Deutsch erklärt.
- Business term
BG-18- Severity
fatal
The fix
Remove payment.card, keeping only payment.iban (BG-17). If you meant the other method, change payment.meansCode to match it instead — the code is what decides which group is required.
A passing value
"payment": { "meansCode": "58", "iban": "DE02120300000000202051" }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-23-b",
"field": "BG-18",
"severity": "fatal",
"message": "The payment means type code (BT-81) is \"58\", which XRechnung treats as a credit transfer (codes 30 and 58), so the PAYMENT CARD INFORMATION (BG-18) group must not be present — but it is. A payment instruction that names one settlement method and then supplies the account details of another is not merely redundant: the payer's system reads the code, looks for the matching group, and has no rule for what to do with the extra one. XRechnung closes that ambiguity by forbidding it outright.",
"fix": "Remove payment.card, keeping only payment.iban (BG-17). If you meant the other method, change payment.meansCode to match it instead — the code is what decides which group is required.",
"example": "\"payment\": { \"meansCode\": \"58\", \"iban\": \"DE02120300000000202051\" }",
"xpath": "/ubl:Invoice/cac:PaymentMeans/cac:CardAccount",
"docsUrl": "https://attestwire.com/rules/BR-DE-23-b"
}
xpath is always a UBL path. On a CII invoice, look for the
matching CII field instead.