Automation MCP Server Features Blog Pricing Contact
Validation rule XRechnung CIUS

BR-DE-1

EN 16931 lets an invoice stay silent about how it will be paid. XRechnung does not: BR-DE-1 demands the payment instructions group (BG-16), and it is one of the first rules a minimal invoice generator trips over.

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.

  • 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

Frequently asked questions

What is the minimum that satisfies BR-DE-1?

A payment instructions group with a payment means type code (BT-81). In practice you should go further: for a credit transfer, code 58 plus the IBAN the buyer should pay to. A bare group with no usable payment route passes the letter of BR-DE-1 but invites follow-up findings and manual clarification.

Which payment means code should a normal invoice use?

58 (SEPA credit transfer) is the standard choice for German invoices paid by bank transfer, together with the IBAN in BT-84. Use 59 for SEPA direct debit, 30 for non-SEPA credit transfer, or 48 for card. The code list is UNTDID 4461.

Why does the same invoice pass as plain EN 16931?

Payment instructions are optional in the European core; the obligation is added by the German CIUS. Validated under the en16931 profile the document passes, validated as XRechnung it fails with BR-DE-1 in the cius layer.

Does a prepaid or zero-amount invoice still need BG-16?

Yes. BR-DE-1 applies to every XRechnung regardless of the amount due. For an invoice already settled, keep the payment instructions and record the settlement via the paid amount (BT-113).