Attestwire › Rule reference › BR-DE-1
BR-DE-1 XRechnung requires payment instructions
noun · XRechnung · fatal · BG-16
an invoice that never says how to pay it.
A German public body has refused your invoice because it does not say how it is to be paid. German public-sector invoices must carry payment instructions: at minimum a payment method code, and for a bank transfer the account to pay into. In the standard the payment instructions are group 16, written BG-16, the method code is BT-81, and BR-DE-1 is the XRechnung rule that requires them.
Diese Regel auf Deutsch: BR-DE-1 — auf Deutsch erklärt.
- Business term
BG-16— Payment instructions- Severity
fatal- Applies to
xrechnung-ubl, xrechnung-cii
The fix
Add a payment block to the invoice: the method code in payment.meansCode (for a bank transfer, "58") and, for a transfer, the account in payment.iban. Decide the payment method per customer, not per invoice, and store it on the customer record with the details it needs, so this becomes a lookup rather than a decision at billing time.
If money moves outside the invoice, through netting against a credit note or an intercompany settlement, use "1" rather than inventing a bank transfer that will never happen; a wrong code gets acted on.
What the rule requires
Under XRechnung, Germany’s version of the European standard, the invoice must carry payment instructions with at least a payment method code. In the European standard itself the whole group is optional; the BR-DE- prefix marks a German addition. In business-term language the group is BG-16 and the code is BT-81, taken from the code list UNTDID 4461.
The codes you are most likely to want: 58 SEPA credit transfer, 30 credit transfer, 59 SEPA direct debit, 48 card, 57 standing agreement, 97 clearing between partners. 1 exists for “instrument not defined”, and it is a legitimate answer when settlement happens outside the document.
The code you choose obliges its own group. Pick 30 or 58 and you now need the credit transfer group with an account identifier (BR-DE-23-a). Pick 59 and you need the direct debit group, with a mandate reference and a creditor identifier. Pick 48 and you need the card group. So this is rarely one field.
Failing and passing
validateInput({
profile: "xrechnung-ubl",
invoiceNumber: "2026-000142",
issueDate: "2026-08-09",
currency: "EUR",
buyerReference: "04011000-1234512345-06",
// payment omitted <- BR-DE-1
seller: { /* ... */ },
buyer: { /* ... */ },
lines: [ /* ... */ ],
});
// -> { valid: false, errors: [ { rule: "BR-DE-1", field: "BG-16", ... } ] }validateInput({
profile: "xrechnung-ubl",
// ...
payment: {
meansCode: "58", // BT-81, SEPA credit transfer
iban: "DE02120300000000202051", // BT-84, the group 58 requires
accountName: "Acme GmbH",
},
});
// -> { valid: true, errors: [] }Why it exists
The buyer is a public authority whose payment run is automated end to end. If the invoice does not say how it is to be settled, somebody has to work it out, which means a phone call, a delay, and an invoice sitting in an exception queue while your payment terms run out. Making the group mandatory moves that question from after receipt to before dispatch, where you can answer it in a second.
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-1",
"field": "BG-16",
"severity": "fatal",
"message": "XRechnung requires payment instructions (BG-16) with a payment means type code (BT-81). Core EN 16931 leaves this optional, but the German CIUS makes it mandatory so that a public-sector payer can settle the invoice without a phone call.",
"fix": "Set payment.meansCode to a UNTDID 4461 code: \"58\" SEPA credit transfer, \"30\" credit transfer, \"59\" SEPA direct debit, \"48\" card, \"57\" standing agreement, \"97\" clearing between partners. Each code obliges its own group: for 30/58 set payment.iban (BG-17), for 59 set payment.directDebit (BG-19), for 48/54/55 set payment.card (BG-18).",
"example": "\"payment\": { \"meansCode\": \"58\", \"iban\": \"DE02120300000000202051\", \"accountName\": \"Acme GmbH\" }",
"xpath": "/ubl:Invoice/cac:PaymentMeans",
"docsUrl": "https://attestwire.com/rules/BR-DE-1"
}
xpath is always a UBL path. On a CII invoice, look for the
matching CII field instead.
How our check differs
Our check asks for the group and a code in it, which is what the rule is about. It does not attempt to tell you whether the right code was chosen for your commercial arrangement; nothing could.
The IBAN you supply is checked, but not here and not fatally: BR-DE-19 verifies the check digits and reports a mismatch as a warning, as KoSIT does.
So a green result on an XRechnung means the payment instructions are present and structurally complete. It does not mean the money will arrive.
See also: BR-DE-23-a — code 58 or 30 obliges the credit transfer group; BR-DE-19 — the IBAN’s check digits; BR-49 — the core rule behind the payment means code.