Attestwire

Rule reference

BR-DE-24-a 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

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.

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
BG-18
Severity
fatal

What the library returns

The exact object in result.errors when this rule fires. Generated by running @attestwire/en16931, not transcribed:

TeachingError
{
  "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 locates the element in the generated UBL document, which is where a KoSIT or Peppol validator will report the same problem.

A passing value

the shape this field expects
"payment": { "meansCode": "48", "card": { "primaryAccountNumber": "4111111111", "holderName": "M Mustermann" } }

The 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.

All 292 rules →

Nearby: BR-DE-24-b — 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; BR-DE-23-b — 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; BR-DE-25-a — The payment means type code (BT-81) is "59" (SEPA direct debit), so exactly one DIRECT DEBIT group (BG-19) must be present.

Check this rule against your invoice via the hosted API → https://api.attestwire.com/docs

Arrived from a stack trace? The docsUrl on every error links straight here. Something wrong on this page — tell us.