AttestwireRule referenceBR-DE-16

BR-DE-16 XRechnung requires a seller tax identifier for almost every category

noun · XRechnung · fatal · BT-31 / BT-32

a seller charging tax without a tax number.

A German public body has refused your invoice because it carries no tax identifier for you, the seller. Almost every German public-sector invoice needs your VAT number or your national tax number, because almost every VAT category on a line triggers the requirement, and adding your VAT number is the fix. In the standard those are fields BT-31 and BT-32, and BR-DE-16 is the XRechnung rule that requires one of them.

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

Business term
BT-31 / BT-32 — Seller VAT / tax registration identifier
Severity
fatal
Applies to
xrechnung-ubl, xrechnung-cii

The fix

Put your VAT identification number in seller.vatId if you have one; it is the value that satisfies the most rules at once, here and elsewhere. If you only have a Steuernummer, put it in seller.taxRegistrationId and you are fine for this rule, though a cross-border customer will often want the VAT ID anyway. Either way, this belongs in your company configuration and not in per-invoice code.

What the rule requires

Under XRechnung, Germany’s version of the European standard, if the tax category codes S, Z, E, AE, K, G, L or M appear anywhere on the document, on an invoice line (BT-151), a document-level allowance (BT-95) or a document-level charge (BT-102), the document must carry at least one of the seller VAT identifier (BT-31), the seller tax registration identifier (BT-32), or a seller tax representative party (BG-11).

That is a broader net than the European standard casts. There, each category has its own rule and each asks only about its own category. XRechnung asks once, about the whole document, across eight of the nine categories.

In German terms: seller.vatId is the Umsatzsteuer-Identifikationsnummer and seller.taxRegistrationId is the Steuernummer. Either satisfies the rule. If you sell through a fiscal representative, supplying taxRepresentative satisfies it instead; that block carries its own VAT identifier (BT-63) and address.

Failing and passing

Fails — a standard-rated XRechnung with no seller tax identifier
validateInput({
  profile: "xrechnung-ubl",
  // ...
  seller: {
    name: "Acme GmbH",
    // no vatId, no taxRegistrationId, no taxRepresentative  <- BR-DE-16
    address: { /* ... */ },
    contact: { /* ... */ },
  },
  lines: [{ /* ... */ vatCategory: "S", vatRate: 19 }],
});
// -> { valid: false, errors: [ { rule: "BR-DE-16", ... },
//                              { rule: "BR-S-02", ... },
//                              { rule: "BR-CO-26", ... } ] }
Passes — a Steuernummer is enough, if you have no VAT ID
validateInput({
  profile: "xrechnung-ubl",
  // ...
  seller: {
    name: "Acme GmbH",
    taxRegistrationId: "181/815/08155",   // BT-32
    address: { /* ... */ },
    contact: { /* ... */ },
  },
});
// -> { valid: true, errors: [] }

Why it exists

Every one of those eight categories is a claim about tax: that you charged it, that you did not have to, that the buyer will account for it. Each of those claims is only checkable if the document says who made it, in terms a German tax office can resolve.

Asking once at document level rather than per category closes the gap where an invoice mixes categories and satisfies the rule for one of them by accident.

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-16",
  "field": [
    "BT-31",
    "BT-32"
  ],
  "severity": "fatal",
  "message": "XRechnung requires that, when the tax codes S, Z, E, AE, K, G, L or M are used — on an invoice line (BT-151), a document level allowance (BT-95) or a document level charge (BT-102) — at least one of the seller VAT identifier (BT-31), the seller tax registration identifier (BT-32) or a seller tax representative party (BG-11) is present. This is stricter than core EN 16931, which only imposes it per category.",
  "fix": "Set seller.vatId (Umsatzsteuer-Identifikationsnummer, e.g. \"DE123456789\") or seller.taxRegistrationId (Steuernummer, e.g. \"181/815/08155\"). If you sell through a fiscal representative, supplying taxRepresentative (BG-11) satisfies this rule instead — it carries its own VAT identifier (BT-63) and address.",
  "example": "\"seller\": { \"vatId\": \"DE123456789\" }",
  "docsUrl": "https://attestwire.com/rules/BR-DE-16"
}

How our check differs

A document that fails BR-DE-16 has almost always failed BR-CO-26 and one of the per-category rules such as BR-S-02 at the same time, all for one missing identifier. That is the rule set behaving correctly rather than us over-reporting: a KoSIT report on the same document lists them together too.

We check presence of an identifier, not its validity.

A well-formed VAT ID that was never issued, or was cancelled last year, passes here. BR-CO-09 checks the country prefix; nothing in this library contacts VIES, because the library makes no network calls at all.

See also: BR-CO-26 — the core rule on identifying the seller; BR-S-02 — the per-category version for standard-rated lines; BR-CO-09 — the VAT identifier needs its country prefix.