BR-DE-2

What BR-DE-2 checks

BR-DE-2 requires that an XRechnung contain the seller contact group, BG-6: in UBL cac:Contact inside the supplier party, in CII ram:DefinedTradeContact. The group answers the question every clearing clerk eventually has: who do I call about this invoice? Three sibling rules make its content concrete: BR-DE-5 requires the contact name (BT-41), BR-DE-6 the phone number (BT-42), and BR-DE-7 the email address (BT-43). In the European core all of this is optional; in the German CIUS it is a hard requirement.

Layer and formats

The rule fires in the cius layer, only when the document is validated against the XRechnung profile: UBL and CII invoices carrying the XRechnung CustomizationID, plus ZUGFeRD and Factur-X hybrids declaring that profile. Under the plain en16931 profile the same document passes.

Why it fails in practice

• The master data has a company, not a contact. ERP vendor records rarely include a billing-questions phone number, so the mapping has nothing to emit.
• Privacy caution backfires. Teams strip personal names and direct dials from outbound documents, and the export ends up with an empty contact group or none at all.
• Only one of the three values is mapped. An email-only contact satisfies BR-DE-2 but immediately fails BR-DE-6 for the missing phone number.

How to fix it

Emit the full trio in UBL:

<cac:Contact>
  <cbc:Name>Accounts Receivable</cbc:Name>
  <cbc:Telephone>+49 30 1234567</cbc:Telephone>
  <cbc:ElectronicMail>billing@example.de</cbc:ElectronicMail>
</cac:Contact>

In an InvoiceXML create request the group is invoice.seller.contact with name, phone, and email properties. A shared team inbox and service number are fine.

The raw rejection vs the InvoiceXML finding

The Schematron output states the German rule text at an XPath:

<svrl:failed-assert id="BR-DE-2" flag="fatal"
    location="/*:Invoice[namespace-uri()='urn:oasis:names:specification:ubl:schema:xsd:Invoice-2'][1]">
  <svrl:text>[BR-DE-2] Die Gruppe "SELLER CONTACT" (BG-6)
    muss übermittelt werden.</svrl:text>
</svrl:failed-assert>

The InvoiceXML validators return the failure as a finding mapped to your input fields:

{
  "rule": "BR-DE-2",
  "layer": "cius",
  "line": null,
  "message": "The seller contact group is required for XRechnung. Add SellerContactName, SellerPhone, and SellerEmail.",
  "btCodes": ["BG-6", "BT-41", "BT-42", "BT-43"],
  "fields": ["seller.contact", "seller.contact.name", "seller.contact.phone", "seller.contact.email"],
  "raw": "[BR-DE-2] CIUS: Die Gruppe \"SELLER CONTACT\" (BG-6) muss übermittelt werden."
}

Instead of parsing rule codes and translating KoSIT prose for your end customers, you get a readable message plus the exact dotted paths to mark invalid in your form. Clients that want their own wording or another language can localize by the stable rule key.

Check or generate XRechnung documents

Validate a file in the XRechnung validator, or generate compliant documents from JSON with POST /v1/create/xrechnung. The XRechnung API toolkit shows the whole flow, from request shape to delivery.

Related rules and identifiers

• BR-DE-1, payment instructions required
• 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 identifier that activates the BR-DE rules