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

BR-DE-24-b A card payment code rules out transfer and direct debit data

noun · XRechnung · fatal · BG-17 / BG-19

Your invoice was refused because it names card payment as the payment method but also carries credit transfer 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-17 and BG-19, with payment means code 48, 54 or 55 in BT-81; BR-DE-24-b is the rule that rules them out.

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

Business term

BG-17 / BG-19 — Payment means type code

Severity

fatal

Applies to

xrechnung-ubl, xrechnung-cii

The fix

Remove the bank details (payment.iban and payment.directDebit) and keep only the card information (payment.card, BG-18). If you meant the other payment method, change payment.meansCode instead.

What the rule requires

With the card codes 48, 54 and 55, BG-17 (credit transfer) and BG-19 (direct debit) must be absent. Only the card group BG-18 remains.

In practice this finding almost always comes from bank details written automatically from the company or customer record, although the payment went through by card long ago.

In this library BG-17 is payment.iban and BG-19 is payment.directDebit.

Wenn BT-81 "Payment means type code" einen Schlüssel für Kartenzahlungen enthält (48, 54, 55), dürfen BG-17 und BG-19 nicht übermittelt werden.

A passing value

"payment": { "meansCode": "48", "card": { "primaryAccountNumber": "4111111111" } }

Why it exists

As with BR-DE-23-b: a document that names one payment method and supplies the account details of another is ambiguous. Which of them a receiver uses is unpredictable, so the German rules forbid the extra group.

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-24-b",
  "field": [
    "BG-17",
    "BG-19"
  ],
  "severity": "fatal",
  "message": "The payment means type code (BT-81) is \"48\", which XRechnung treats as a card payment (codes 48, 54 and 55), so the CREDIT TRANSFER (BG-17) and DIRECT DEBIT (BG-19) groups must not be present — but they are. 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.iban and payment.directDebit, keeping only payment.card (BG-18). 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\": \"48\", \"card\": { \"primaryAccountNumber\": \"4111111111\" } }",
  "xpath": "/ubl:Invoice/cac:PaymentMeans/cac:PayeeFinancialAccount",
  "docsUrl": "https://attestwire.com/rules/BR-DE-24-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-24-a — the other half: the card group must be there.