Attestwire › Rule reference › BR-DE-7

BR-DE-7 XRechnung requires a seller email address

noun · XRechnung · fatal · BT-43

a seller with no email address.

A German public body has refused your invoice because the seller contact has no email address. German public-sector invoices must carry an email address the authority can write to about the invoice, and it should be a shared mailbox that somebody reads. In the standard the field is BT-43, and BR-DE-7 is the XRechnung rule that requires it.

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

Business term

BT-43 — Seller contact email address

Severity

fatal

Applies to

xrechnung-ubl, xrechnung-cii

The fix

Add an email address to the seller contact, seller.contact.email. Use a shared mailbox (rechnungen@, ap@, billing@) that more than one person reads, and route it into whatever queue you work. Avoid an individual’s address: people change roles, and this value sits in a public authority’s supplier record long after they have.

What the rule requires

Under XRechnung, Germany’s version of the European standard, the seller contact email address must be present. Like the telephone number, it is separately mandatory: a contact group carrying a name and a phone number still fails, here. In business-term language the field is BT-43.

In this model the field is seller.contact.email.

Two fields get confused here. BT-43 is a human contact address. BT-34, the seller electronic address, is a routing identifier (a Peppol participant ID, or a Leitweg-ID with its scheme) and it is a different field for a different purpose. Putting your accounts mailbox in BT-34 does not route anything.

Das Element „Seller contact email address“ (BT-43) muss übermittelt werden.

Failing and passing

validateInput({
  profile: "xrechnung-ubl",
  // ...
  seller: {
    // ...
    contact: {
      name:  "Buchhaltung",
      phone: "+49 30 1234567",
      // email omitted           <- BR-DE-7
    },
  },
});
// -> { valid: false, errors: [ { rule: "BR-DE-7", field: "BT-43", ... } ] }

validateInput({
  profile: "xrechnung-ubl",
  // ...
  seller: {
    // ...
    contact: {
      name:  "Buchhaltung",
      phone: "+49 30 1234567",
      email: "rechnungen@acme.example",
    },
  },
});
// -> { valid: true, errors: [] }

Why it exists

This is where the query lands. An authority that cannot reconcile your invoice writes to this address, and if it bounces or is not watched, the invoice does not get paid and nobody tells you why. Mandating it is the German rule set accepting that fully automated processing still has an exception path, and insisting that the exception path has somewhere to go.

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-7",
  "field": "BT-43",
  "severity": "fatal",
  "message": "XRechnung requires the element \"Seller contact email address\" (BT-43). The seller contact group is present but incomplete — BR-DE-5, BR-DE-6 and BR-DE-7 each make one part of it mandatory, so supplying two of the three still fails.",
  "fix": "Set seller.contact.email to a monitored mailbox — this is where the authority sends invoice queries.",
  "example": "\"contact\": { \"email\": \"rechnungen@example.de\" }",
  "xpath": "/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:ElectronicMail",
  "docsUrl": "https://attestwire.com/rules/BR-DE-7"
}

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

How our check differs

See also: BR-DE-6 — the telephone number, same rule shape; BR-DE-2 — the group all three belong to.