What BR-DE-1 checks
BR-DE-1 requires that an XRechnung contain the payment instructions group, BG-16. In UBL that is cac:PaymentMeans; in CII it is the payment means inside the settlement block. The group tells the buyer how to pay: a payment means type code (BT-81), and typically an account, most often an IBAN for SEPA transfers. The European core model leaves all of this optional. The German CIUS reasons that an invoice a public authority cannot pay is not much of an invoice, and makes the group mandatory.
Layer and formats
BR-DE-1 is part of the KoSIT overlay, so the finding carries "layer": "cius" and appears only when the document declares the XRechnung profile: UBL or CII invoices with the XRechnung CustomizationID, and ZUGFeRD or Factur-X hybrids that declare that profile in their embedded XML.
Why it fails in practice
- The generator only maps what the old paper layout showed. Bank details lived in the letter footer, so nobody mapped them into the structured data.
- Payment data lives in another system. The ERP knows the order, the banking details sit in treasury software, and the export in between drops them.
- Credit notes reuse the invoice template. The template author removed the payment block for credit notes; XRechnung still requires it.
How to fix it
In UBL, add a payment means block with at least the type code, and for transfers the account:
<cac:PaymentMeans>
<cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
<cac:PayeeFinancialAccount>
<cbc:ID>DE89370400440532013000</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
In an InvoiceXML create request the group is the invoice.paymentDetails object: set paymentDetails.paymentAccountIdentifier to the IBAN and the API defaults the means code to 58 (SEPA credit transfer) for you.
The raw rejection vs the InvoiceXML finding
A Schematron validator answers in the German of the KoSIT rule text:
<svrl:failed-assert id="BR-DE-1" flag="fatal"
location="/*:Invoice[namespace-uri()='urn:oasis:names:specification:ubl:schema:xsd:Invoice-2'][1]">
<svrl:text>[BR-DE-1] Eine Rechnung (INVOICE) muss Angaben zu
"PAYMENT INSTRUCTIONS" (BG-16) enthalten.</svrl:text>
</svrl:failed-assert>
The InvoiceXML validators return the same failure ready for your UI:
{
"rule": "BR-DE-1",
"layer": "cius",
"line": null,
"message": "An XRechnung invoice must contain payment instructions. Add the payment details (e.g. payment means code and account).",
"btCodes": ["BG-16"],
"fields": ["paymentDetails"],
"raw": "[BR-DE-1] CIUS: Eine Rechnung (INVOICE) muss Angaben zu \"PAYMENT INSTRUCTIONS\" (BG-16) enthalten."
}
No rule-code parsing, no translating German rule prose for your end customers: the message is human-readable, fields points at the exact request object to highlight, and because the message table is keyed by rule code, clients can localize by rule if they want their own wording.
Check or generate XRechnung documents
Run a document through the XRechnung validator to see the full findings list, or generate from JSON with POST /v1/create/xrechnung, where an IBAN in paymentDetails.paymentAccountIdentifier is all BR-DE-1 needs. The XRechnung API toolkit covers the rest of the integration.
Related rules and identifiers
- BR-DE-2, the seller contact group, XRechnung's other famous "optional in the core, mandatory here" rule
- BR-DE-18, the strict format for Skonto entries inside these payment terms
- BR-DE-15, the mandatory buyer reference (Leitweg-ID)
- BR-DE-21, the specification identifier must be the XRechnung one
- The XRechnung 3.0 CustomizationID, the BT-24 value that activates the BR-DE rules