EN 16931

Kurzdefinition

EN 16931 ist die europäische Norm, die das semantische Datenmodell für elektronische Rechnungen definiert. Herausgegeben vom CEN (European Committee for Standardization) im Jahr 2017, ist sie heute die gemeinsame Grundlage für alle relevanten E-Rechnungs­formate in Europa: XRechnung, Peppol BIS Billing 3.0, ZUGFeRD 2.x, Factur-X.

Die Norm entstand als technische Umsetzung der EU-Richtlinie 2014/55/EU, die die elektronische Rechnungs­stellung im öffentlichen Auftragswesen verpflichtend gemacht hat.

Was EN 16931 regelt

EN 16931 definiert nicht, wie eine Rechnung im XML aussieht — sie definiert, welche Felder eine Rechnung semantisch enthalten muss:

• Core Invoice Model — das Datenmodell mit rund 140 Business Terms (BT) und zusätzlichen Business Groups (BG)
• Syntax-Bindings — erlaubt zwei XML-Realisierungen: UN/CEFACT CII und OASIS UBL
• Business Rules — verpflichtende semantische Konsistenz­regeln (z.B. „Summe der Positionen = Positionen­netto vor Rabatt”)

Die Norm enthält aber keine nationalen Besonderheiten — weder die deutsche Leitweg-ID, noch französische SIRET-Angaben, noch norwegische MVA-Regeln. Dafür gibt es CIUS.

Business Terms (BT) und Business Groups (BG)

Jedes relevante Feld trägt eine BT-Nummer:

• BT-1 — Rechnungsnummer
• BT-2 — Rechnungsdatum
• BT-3 — Rechnungstyp (380 = Rechnung, 381 = Gutschrift, …)
• BT-10 — Buyer reference (Deutschland: Leitweg-ID)
• BT-112 — Rechnungs­endbetrag inkl. Steuer
• BG-25 — Rechnungsposition (Group, enthält BT-126 bis BT-141)

Diese Nummerierung gilt sprachen- und syntax­unabhängig — eine deutsche, eine französische und eine norwegische EN-16931-Rechnung tragen alle im Feld BT-10 dieselbe semantische Bedeutung.

CIUS — Core Invoice Usage Specifications

Weil EN 16931 bewusst neutral ist, erlaubt sie nationale oder branchen­spezifische Einschränkungen über sogenannte CIUS. Eine CIUS macht optionale Felder verpflichtend, schränkt zulässige Codes ein oder setzt Textlängen fester. Sie darf die Norm nicht erweitern — sie verfeinert nur.

Bekannte CIUS:

• XRechnung (Deutschland, KoSIT)
• Peppol BIS Billing 3.0 (OpenPeppol)
• Factur-X / ZUGFeRD Profil EN 16931 (D/F)

Jede CIUS bringt ein eigenes Schematron mit, das die zusätzlichen Regeln prüft.

Validierungs-Kette

Eine EN-16931-Rechnung durchläuft mehrere Ebenen:

1. XSD-Schema der gewählten Syntax (UBL 2.1 oder CII) — rein strukturell
2. EN-16931-Schematron — die knapp 150 Business Rules der Norm
3. CIUS-Schematron — nationale Zusatzregeln (z.B. Leitweg-ID-Format für XRechnung)
4. ggf. Transport-Ebene — Peppol-Schematron, Empfänger­spezifische Regeln

Erst wenn alle Ebenen grün sind, gilt die Rechnung als valide.

EN 16931 mit der Dokmatiq-API

Alle E-Rechnungs-Endpunkte der Dokmatiq-API erzeugen Dokumente, die gegen die volle EN-16931-Validierungs­kette validiert sind:

curl -X POST https://api.dokmatiq.com/v1/einvoice/validate \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -H "Content-Type: application/xml" \
  --data-binary "@rechnung.xml"

Antwort enthält die Trefferliste — welche Regel aus welcher Ebene verletzt ist, mit BT-/BR-Referenz. So lässt sich unterscheiden, ob ein Mangel die Norm selbst betrifft (EN-16931) oder nur die gewählte CIUS.

Häufige Stolpersteine

1. BT-Nummer ≠ XML-Tag — die BT-Nummer ist semantisch, das XML-Tag syntaktisch. Eine BT-10 kann in UBL anders heißen als in CII
2. CIUS-Regeln übersehen — EN-16931-konform heißt nicht automatisch XRechnung-konform
3. Altlasten — ältere ZUGFeRD-1.0-Dokumente folgen der Vorgänger­logik, nicht EN 16931
4. Business Rules unterschätzen — viele Validierer prüfen nur die Schema-Ebene; echte EN-16931-Konformität verlangt auch das Schematron