Attestwire

Rule reference

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

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.

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-17 / BG-19
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-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 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" } }

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

All 292 rules →

Nearby: 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; 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; BR-DE-25-b — The payment means type code (BT-81) is "59", which XRechnung treats as a direct debit (code 59), so the CREDIT TRANSFER (BG-17) group must not be present — but it is.

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.