EN 16931 Branchenerweiterungen: E-Rechnungen für Bau, Gesundheit und Logistik

Warum EN 16931 allein nicht reicht

EN 16931 definiert ein semantisches Datenmodell für Rechnungen: Verkäufer, Käufer, Positionen, Steuern, Summen. Das Modell ist bewusst generisch — es soll für alle Branchen und alle EU-Länder funktionieren.

In der Praxis fehlen vielen Branchen entscheidende Felder:

• Ein Bauunternehmen stellt Abschlagsrechnungen mit Sicherheitseinbehalten. EN 16931 kennt weder das eine noch das andere.
• Ein Krankenhaus rechnet über DRG-Fallpauschalen mit Kostenträgern ab. Die Fallnummer, ICD-10-Diagnose und der Kostenträger haben kein Feld im Standard.
• Ein Logistikdienstleister referenziert CMR-Frachtbriefe und Zolltarifnummern. Der Standard sieht keine strukturierten Transportdokumentreferenzen vor.

Die Lösung: Branchenerweiterungen nach CEN/TS 16931-5.

Was CEN/TS 16931-5 definiert

Die technische Spezifikation CEN/TS 16931-5 regelt, wie EN 16931 erweitert werden darf, ohne die Interoperabilität zu brechen. Die Kernregeln:

Extension-Regeln

1. Pflichtfelder bleiben Pflicht. Eine Extension darf keine Kernfelder entfernen oder deren Semantik ändern.
2. Neue Felder kommen in Extension Points. EN 16931 definiert explizite Stellen (auf Dokument-, Positions- und Steuerebene), an denen zusätzliche Felder eingefügt werden dürfen.
3. CustomizationID identifiziert die Extension. Jede Erweiterung hat eine eindeutige ID, die im Dokument angegeben wird. Empfänger erkennen daran, welche zusätzlichen Felder zu erwarten sind.
4. Extensions müssen validierbar sein. Zusätzliche Felder brauchen ein eigenes Schema mit Datentypen, Kardinalitäten und Geschäftsregeln.

Das bedeutet: Ein System, das EN 16931 versteht, kann eine erweiterte Rechnung immer noch als gültige Basisrechnung verarbeiten — die zusätzlichen Felder werden ignoriert, wenn der Empfänger die Extension nicht kennt. Die Abwärtskompatibilität bleibt erhalten.

Branchenerweiterung Bauwirtschaft

Die E-Rechnung Bauwirtschaft ist der häufigste Anwendungsfall für Extensions in Deutschland. Bauprojekte arbeiten mit Teilrechnungen, Rückbehalten und normspezifischen Kostengliederungen, die im Standardmodell nicht abbildbar sind.

Typische Zusatzfelder

Ohne diese Felder müssten Bauunternehmen die Informationen in Freitextfelder packen — was die automatische Verarbeitung unmöglich macht. Mit einer strukturierten Extension validiert das System Sicherheitseinbehalte gegen Vertragsbedingungen und ordnet Positionen automatisch DIN-276-Kostengruppen zu.

Branchenerweiterung Gesundheitswesen

Das Gesundheitswesen hat eigene Abrechnungslogiken, die weit über den EN-16931-Standard hinausgehen. Krankenhäuser rechnen über DRG-Fallpauschalen ab, ambulante Leistungen nach EBM oder GOÄ, und der Kostenträger ist nicht der Patient.

Typische Zusatzfelder

Die Herausforderung: Im Gesundheitswesen ist der Rechnungsempfänger (Krankenkasse) nicht der Leistungsempfänger (Patient). Die Extension muss diese Drei-Parteien-Beziehung abbilden und gleichzeitig datenschutzkonform bleiben.

Branchenerweiterung Logistik

In der Logistik sind Rechnungen eng mit Transportdokumenten verknüpft. Ohne strukturierte Referenzen auf Frachtbriefe, Zolldaten und Lieferbedingungen ist keine automatische Zuordnung möglich.

Typische Zusatzfelder

Branchenerweiterung Automotive

Die Automotive-Branche hat spezifische Anforderungen bei Leasing, Flottenmanagement und Ersatzteilhandel.

Typische Zusatzfelder

Wie Extensions technisch funktionieren

Eine Branchenerweiterung besteht aus drei Komponenten:

1. Schema-Definition: Ein JSON- oder XML-Schema beschreibt die zusätzlichen Felder mit Datentypen, Pflicht/Optional-Kennzeichen und erlaubten Werten. Das Schema wird über die CustomizationID referenziert.
2. Validierungsregeln: Geschäftsregeln, die über reine Datentyp-Prüfung hinausgehen. Beispiel: „Wenn Abschlagsrechnung, dann muss Sicherheitseinbehalt angegeben sein."
3. Serialisierung: Die Erweiterungsfelder werden in die UBL- oder CII-XML-Struktur eingebettet — an den definierten Extension Points.

Im UBL-Format sieht eine Extension so aus:

<ext:UBLExtensions>
  <ext:UBLExtension>
    <ext:ExtensionContent>
      <construction:RetentionRate>5.0</construction:RetentionRate>
      <construction:PartialInvoiceNumber>3</construction:PartialInvoiceNumber>
      <construction:ProjectID>BV-2026-Karlstein</construction:ProjectID>
    </ext:ExtensionContent>
  </ext:UBLExtension>
</ext:UBLExtensions>

Ein Empfänger, der die Bau-Extension nicht kennt, ignoriert den UBLExtensions-Block und verarbeitet die Rechnung als Standard-EN-16931-Dokument. Ein Empfänger mit Bau-Extension validiert die zusätzlichen Felder und verarbeitet sie automatisch.

Verfügbare Extensions

• Bauwirtschaft: Abschlagsrechnungen, Sicherheitseinbehalte, DIN 276, GAEB
• Gesundheitswesen: DRG, ICD-10, Kostenträger, Fallnummern
• Logistik: CMR/AWB, Incoterms, Zolltarifnummern, Container-IDs
• Automotive: Leasing, FIN/VIN, OE-Teilenummern

Neue Extensions lassen sich als JSON-Schema-Dateien hinzufügen, ohne den API-Code zu ändern. Das Schema wird beim Start geladen und steht sofort für Validierung und Generierung zur Verfügung.

Fazit: Extensions machen E-Rechnungen branchentauglich

EN 16931 ist das Fundament. Für branchenspezifische Anforderungen brauchen Sie Extensions nach CEN/TS 16931-5. Die gute Nachricht: Der Standard hat das von Anfang an vorgesehen. Extensions sind keine Hacks — sie sind der offizielle Erweiterungsmechanismus.

Entscheidend ist die Wahl eines Systems, das Extensions als Konzept versteht und nicht nur als Freitext-Workaround. Strukturierte Erweiterungen ermöglichen automatische Validierung und Verarbeitung — genau das, was die E-Rechnungspflicht bezweckt.