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.
A passing value
"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:
{
"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.