Attestwire › Rule reference › BR-DE-28

BR-DE-28 The seller email address must look like an email address

noun · XRechnung · warning · BT-43

Your invoice carries a warning because the contact email address does not have the form of an email address. Usually a display name sits in front of it, or several addresses share one field; give a single, bare address. KoSIT rates this a warning, so the invoice is accepted. In the standard the field is BT-43, and BR-DE-28 is the rule that checks the form.

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

Business term
BT-43 — Seller contact email address
Severity
warning
Applies to
xrechnung-ubl, xrechnung-cii

The fix

Put a single, bare email address into seller.contact.email: no display name, no angle brackets, no list.

What the rule requires

What is checked is the form of BT-43. KoSIT’s rule text asks for exactly one @, at least two characters on each side of it, neither a space nor a dot directly beside it, and no dot at the start or the end.

By far the most common trigger is a display name: Buchhaltung <rechnungen@example.de> is a valid header in an email program, but not a valid value for BT-43. Neither is a comma-separated list of addresses.

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

In BT-43 soll genau ein @-Zeichen enthalten sein, welches nicht von einem Leerzeichen, einem Punkt, aber mindestens zwei Zeichen auf beiden Seiten flankiert werden soll. Ein Punkt sollte nicht am Anfang oder am Ende stehen.

BR-DE-28 — KoSIT XRechnung Schematron 2.6.0 (XRechnung 3.0), XRechnung-UBL-validation.sch

A passing value

the shape this field expects
"email": "rechnungen@example.de"

Why it exists

BT-43 is processed by machine: the authority writes to this address. What a person reads effortlessly as an address with a name in front is, to a mailing system, an invalid string. The check catches it before the first query goes nowhere.

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-28",
  "field": "BT-43",
  "severity": "warning",
  "message": "The seller contact email address (BT-43) must contain exactly one \"@\", flanked by at least two characters on each side and by neither a space nor a dot, and must not begin or end with a dot. \"Buchhaltung <rechnungen@acme.example>\" does not satisfy that shape.",
  "fix": "Supply a single, plain email address — no display name, no angle brackets, no comma-separated list.",
  "example": "\"email\": \"rechnungen@example.de\"",
  "xpath": "/ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cac:Contact/cbc:ElectronicMail",
  "docsUrl": "https://attestwire.com/rules/BR-DE-28"
}

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

How our check differs

We run the expression KoSIT’s validator actually runs ($XR-EMAIL-REGEX in its common.sch), not the rule text quoted above, and the two differ. The expression accepts a one-character local part such as a@example.de, which the text would refuse, and it requires at least one dot in the domain, so user@localhost is reported. The library’s message restates the rule text; the verdict follows the expression, as KoSIT’s does.

See also: BR-DE-7 — the rule that requires the field at all; BR-DE-27 — the same kind of shape check for the telephone number.