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

`BR-DE-23-a` A credit transfer code obliges the credit transfer group

noun · XRechnung · fatal · BG-17 / BT-84

a bank transfer with no bank.

A German public body has refused your invoice because it says “pay by bank transfer” but gives no account to pay into. Naming a payment method obliges you to supply the details that method needs; for a transfer, that is the IBAN. In the standard the transfer details are group BG-17, the method code is BT-81, and BR-DE-23-a is the XRechnung rule that ties the two together.

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

Business term: BG-17 / BT-84 — Credit transfer group
Severity: fatal
Applies to: xrechnung-ubl, xrechnung-cii

The fix

Add the account to pay into, payment.iban. If you did not intend a credit transfer, change the code instead, and check what the new code brings with it: 59 SEPA direct debit needs payment.directDebit with a mandate reference and a creditor identifier, 48 card needs payment.card, 97 clearing between partners needs neither. Choosing a code because it looks harmless is how invoices end up failing three rules instead of one.

What the rule requires

When the payment means code (BT-81) is one XRechnung treats as a credit transfer (58 SEPA credit transfer, 30 credit transfer) 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. So in practice the rule reduces to: set payment.iban.

The European standard states the same requirement, under BR-61. BR-DE-23-a is the German add-on restating it against the group rather than the field, and both ids appear in a KoSIT report on the same document.

Failing and passing

Fails — code 58, no account

validateInput({
  profile: "xrechnung-ubl",
  // ...
  payment: { meansCode: "58" },     // <- BR-DE-23-a, and BR-61
});
// -> { valid: false, errors: [ { rule: "BR-61", ... },
//                              { rule: "BR-DE-23-a", ... } ] }

Passes

validateInput({
  profile: "xrechnung-ubl",
  // ...
  payment: {
    meansCode: "58",
    iban: "DE02120300000000202051",
    accountName: "Acme GmbH",
  },
});
// -> { valid: true, errors: [] }

Why it exists

A payment means code is a promise about how this invoice gets settled, and “credit transfer” without an account number is a promise with a hole in it. The buyer’s system reads the code, branches into its credit-transfer path, and finds nothing to transfer to, so the document goes to an exception queue rather than a payment run. Tying the code to its group means the invoice is either fully payable or visibly not.

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:

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 is always a UBL path. On a CII invoice, look for the matching CII field instead.

How our check differs

Two ids for one problem, and that is correct. You get BR-61 and BR-DE-23-a together on an XRechnung, because the European standard and the German add-on both state this requirement and a KoSIT report lists both. We are reporting two rules that a receiving validator will also report.

The group is inferred from the account identifier. This library writes BG-17 only when you give it an account to write, so from a caller’s point of view the rule reduces to one field: a blank or absent payment.iban under code 30 or 58.

A parsed document with the group present but empty reaches the same finding, for the same reason.

The other half of the rule is a different id. BR-DE-23-a is presence. Supplying the wrong group alongside the code (card details on a credit transfer, say) is BR-DE-23-b, exclusivity.

KoSIT reports them separately, so we do too.

Whether the IBAN itself checks out is BR-DE-19, and that one is only a warning.

See also: BR-61 — the core rule behind this one; BR-DE-19 — whether the account number is a real IBAN; BR-DE-25-a — the direct-debit equivalent.

BR-DE-23-a A credit transfer code obliges the credit transfer group