Attestwire

Rule reference

BR-DE-23-a The payment means type code (BT-81) is "58", which XRechnung treats as a credit transfer, so the CREDIT TRANSFER group (BG-17) must be present

The payment means type code (BT-81) is "58", which XRechnung treats as a credit transfer, so the CREDIT TRANSFER group (BG-17) must be present. In UBL that group is cac:PayeeFinancialAccount, and this library emits it only when you supply an account identifier. Core EN 16931 states the same requirement as BR-61; BR-DE-23-a is the German CIUS restating it against the group rather than the field, and both appear in a KoSIT report.

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 / BT-84
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-23-a",
  "field": [
    "BG-17",
    "BT-84"
  ],
  "severity": "fatal",
  "message": "The payment means type code (BT-81) is \"58\", which XRechnung treats as a credit transfer, so the CREDIT TRANSFER group (BG-17) must be present. In UBL that group is cac:PayeeFinancialAccount, and this library emits it only when you supply an account identifier. Core EN 16931 states the same requirement as BR-61; BR-DE-23-a is the German CIUS restating it against the group rather than the field, and both appear in a KoSIT report.",
  "fix": "Set payment.iban to the account the buyer should transfer to. If you did not intend a credit transfer, change payment.meansCode — \"59\" for SEPA direct debit (then supply payment.directDebit), \"48\" for card (then supply payment.card), \"97\" for clearing between partners — but note each of those brings its own mandatory group.",
  "example": "\"payment\": { \"meansCode\": \"58\", \"iban\": \"DE02120300000000202051\", \"accountName\": \"Acme GmbH\" }",
  "xpath": "/ubl:Invoice/cac:PaymentMeans/cac:PayeeFinancialAccount",
  "docsUrl": "https://attestwire.com/rules/BR-DE-23-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": "58", "iban": "DE02120300000000202051", "accountName": "Acme GmbH" }

The fix

Set payment.iban to the account the buyer should transfer to. If you did not intend a credit transfer, change payment.meansCode — "59" for SEPA direct debit (then supply payment.directDebit), "48" for card (then supply payment.card), "97" for clearing between partners — but note each of those brings its own mandatory group.

All 292 rules →

Nearby: 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-22 — Two embedded attachments carry the same filename "a.pdf" — supportingDocuments[0] and supportingDocuments[1]; 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.

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.