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

BR-DE-24-a A card payment code requires the card group

noun · XRechnung · fatal · BG-18

Your invoice was refused because it names card payment as the payment method but carries no card information. Each payment method takes its matching data group, and for a card that is the masked card number. In the standard this is group BG-18, with payment means code 48, 54 or 55 in BT-81; BR-DE-24-a is the rule that requires it.

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

Business term

BG-18 — Payment card information

Severity

fatal

Applies to

xrechnung-ubl, xrechnung-cii

The fix

Set payment.card with the masked card number (BT-87) and, optionally, the cardholder name (BT-88). If the invoice is not settled by card, change payment.meansCode instead: "58" with payment.iban is the usual case.

What the rule requires

With the card codes 48, 54 and 55, group BG-18 is mandatory, exactly once.

BG-18 is explicitly not an invitation to put a card number on the invoice. BR-51 limits the card number (BT-87) to ten characters, and the card industry’s security standard allows no more: the first six and the last four digits. The group exists for reconciliation, so that your customer can match this invoice to a line on a card statement they have already been charged.

In this library the group is payment.card, with primaryAccountNumber (BT-87) and, optionally, holderName (BT-88).

Wenn BT-81 "Payment means type code" einen Schlüssel für Kartenzahlungen enthält (48, 54, 55), muss genau BG-18 "PAYMENT CARD INFORMATION" übermittelt werden.

A passing value

"payment": { "meansCode": "48", "card": { "primaryAccountNumber": "4111111111", "holderName": "M Mustermann" } }

Why it exists

A card payment has already gone through by the time the invoice is written. Without an anchor in the invoice, accounts payable cannot bring the charge and the document together, and the case stays open. The masked number is exactly as much information as the match needs and data protection allows.

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-a",
  "field": "BG-18",
  "severity": "fatal",
  "message": "The payment means type code (BT-81) is \"48\", which XRechnung treats as a card payment, so exactly one PAYMENT CARD INFORMATION group (BG-18) must be present. BG-18 is not an invitation to put a card number on an invoice: BR-51 caps the primary account number (BT-87) at ten characters, which is the most the PCI Security Standards Council permits — the first six and the last four digits. What the group is actually for is letting the buyer reconcile this invoice against a card statement line they have already been charged for.",
  "fix": "Set payment.card with the masked primary account number (BT-87) and, optionally, the cardholder name (BT-88). If the invoice is not settled by card, change payment.meansCode instead — \"58\" (SEPA credit transfer) with payment.iban is what most invoices want.",
  "example": "\"payment\": { \"meansCode\": \"48\", \"card\": { \"primaryAccountNumber\": \"4111111111\", \"holderName\": \"M Mustermann\" } }",
  "xpath": "/ubl:Invoice/cac:PaymentMeans/cac:CardAccount",
  "docsUrl": "https://attestwire.com/rules/BR-DE-24-a"
}

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-b — the other half: the transfer and direct debit groups must be absent; BR-51 — how much of the card number may appear.