Attestwire › Rule reference › BR-DE-2

`BR-DE-2` XRechnung requires seller contact details, all three of them

noun · XRechnung · fatal · BG-6

a seller you cannot phone, email or name.

A German public body has refused your invoice because it has no contact details for you, the seller. German public-sector invoices must carry a contact point, a telephone number and an email address, and all three are needed: two out of three still fails. A shared departmental contact such as “Buchhaltung” with a shared number and mailbox is fine. In the standard the contact group is BG-6, and BR-DE-2 is the XRechnung rule that requires it.

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

Business term: BG-6 — Seller contact
Severity: fatal
Applies to: xrechnung-ubl, xrechnung-cii

The fix

Add a contact to the seller block with all three values: a contact point, a phone number and an email address, in seller.contact.name, seller.contact.phone and seller.contact.email. Put them in your company configuration once, and use a shared departmental contact, a shared number and a shared mailbox rather than an individual’s.

The email address is where invoice queries land, so it needs to be one somebody watches; a noreply@ address satisfies the rule and defeats its purpose.

What the rule requires

Under XRechnung, Germany’s version of the European standard, the seller contact group must be present. In the European standard itself it is optional; this is a German addition. In business-term language the group is BG-6.

“Present” means all three parts. BT-41 contact point, BT-42 telephone number and BT-43 email address are each individually mandatory, under BR-DE-5, BR-DE-6 and BR-DE-7 respectively. Two out of three is a failing invoice.

The contact point does not have to be a named person. A shared departmental contact such as "Buchhaltung" or "Rechnungswesen" is fine, and is usually the better answer: a department outlives an employee, and this value sits in the buyer’s records for years.

Failing and passing

Fails — no contact group on the seller

validateInput({
  profile: "xrechnung-ubl",
  // ...
  seller: {
    name: "Acme GmbH",
    vatId: "DE123456789",
    address: { line1: "Chausseestr. 1", city: "Berlin",
               postalCode: "10115", countryCode: "DE" },
    // contact omitted          <- BR-DE-2
  },
});
// -> { valid: false, errors: [ { rule: "BR-DE-2", field: "BG-6", ... } ] }

Passes — the group, complete

validateInput({
  profile: "xrechnung-ubl",
  // ...
  seller: {
    name: "Acme GmbH",
    vatId: "DE123456789",
    address: { /* ... */ },
    contact: {
      name:  "Buchhaltung",              // BT-41
      phone: "+49 30 1234567",           // BT-42
      email: "rechnungen@acme.example",  // BT-43
    },
  },
});
// -> { valid: true, errors: [] }

Why it exists

A public authority processing your invoice will occasionally need to ask you something: a purchase-order number that does not match, a delivery date that looks wrong, a VAT treatment they want to confirm. Without a route to a person, that query becomes a rejection instead of a question, which costs you a full billing cycle rather than five minutes.

The German rules make the route mandatory because the alternative, in practice, is invoices stalling in an authority’s exception queue.

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-2",
  "field": "BG-6",
  "severity": "fatal",
  "message": "XRechnung requires the seller contact group (BG-6), and requires it complete: contact point (BT-41), telephone number (BT-42) and email address (BT-43) are each individually mandatory under BR-DE-5, BR-DE-6 and BR-DE-7. A public-sector payer must have a named human route to query the invoice.",
  "fix": "Set seller.contact with all three of name, phone and email. A shared departmental identity is fine and usually preferable to a named individual.",
  "example": "\"contact\": { \"name\": \"Buchhaltung\", \"phone\": \"+49 30 1234567\", \"email\": \"rechnungen@example.de\" }",
  "xpath": "/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact",
  "docsUrl": "https://attestwire.com/rules/BR-DE-2"
}

xpath is always a UBL path. On a CII invoice, look for the matching CII field instead.

How our check differs

Which id you get depends on how much of the group is there. No contact block at all comes back as BR-DE-2, naming the group. A contact block with a part missing comes back as BR-DE-5, BR-DE-6 or BR-DE-7, naming the field, one finding per missing part, so an empty-but-present group can produce three.

The values themselves are checked for presence, not for plausibility: a phone number of "x" passes this rule.

There is separate, gentler checking on the shape of the phone number and the email address elsewhere in the library, and neither is BR-DE-2’s business.

See also: BR-DE-6 — the telephone number on its own; BR-DE-7 — the email address on its own; BR-DE-15 — the other XRechnung field people forget.

BR-DE-2 XRechnung requires seller contact details, all three of them