Attestwire › Rule reference › BR-DE-23-b

BR-DE-23-b A credit transfer code rules out card and direct debit data

noun · XRechnung · fatal · BG-18

Your invoice was refused because it names credit transfer as the payment method but also carries card or direct debit data. Each payment method takes exactly one data group, so remove the extra data or change the payment method. In the standard these are groups BG-18 and BG-19, with payment means code 30 or 58 in BT-81; BR-DE-23-b is the rule that reports the contradiction.

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

Business term

BG-18 — Payment means type code

Severity

fatal

Applies to

xrechnung-ubl, xrechnung-cii

The fix

Remove the card data (payment.card) and any direct debit data (payment.directDebit), and keep only the IBAN (payment.iban, BG-17). If you meant the other payment method, change payment.meansCode instead; the code decides which group is required.

What the rule requires

With the credit transfer codes 30 and 58, group BG-18 (payment card information) and group BG-19 (direct debit) must both be absent. Only the credit transfer group BG-17 may be present.

This is not cosmetic. Two payment routes on one document are ambiguous, and XRechnung removes the ambiguity by forbidding it.

In this library BG-18 is payment.card and BG-19 is payment.directDebit.

Wenn BT-81 "Payment means type code" einen Schlüssel für Überweisungen enthält (30, 58), dürfen BG-18 und BG-19 nicht übermittelt werden.

A passing value

"payment": { "meansCode": "58", "iban": "DE02120300000000202051" }

Why it exists

Two contradictory payment routes on one document are worse than a missing one, because they look complete. Which of the two a receiver uses is unpredictable. The German rules allow exactly one combination, and the code is what decides 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-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.

How our check differs

See also: BR-DE-23-a — the other half: the credit transfer group must be there; BR-DE-24-b — the same rule for card codes; BR-DE-25-b — the same rule for direct debit.