← Back to all articles

EN16931 verstehen: Europas Rechnungsdatenmodell

SealDoc Team · · 7 min read

EN16931 ist der europäische Standard, der definiert, was eine E-Rechnung enthalten muss. Es ist kein XML-Format. Es ist ein semantisches Datenmodell. Jedes wichtige europäische E-Rechnungsformat, ob Peppol BIS Billing 3.0, Factur-X, ZUGFeRD oder XRechnung, ist eine Implementierung von EN16931 in einer bestimmten XML-Syntax.

EN16931 zu verstehen spart Zeit beim Debuggen von Validierungsfehlern, beim Erklären von Integrationsanforderungen an ERP-Anbieter oder beim Implementieren eines neuen Rechnungsprofils von Grund auf.

Was EN16931 tatsächlich spezifiziert

EN16931 besteht aus zwei Teilen:

  • EN 16931-1 definiert das semantische Datenmodell: welche Datenelemente eine Rechnung enthalten kann, welche Pflicht sind und was die Business Rules sind
  • EN 16931-2 definiert die Syntaxbindungen: wie das semantische Modell auf UBL 2.1 XML und UN/CEFACT CII XML abgebildet wird

Das Ergebnis ist, dass eine Peppol-BIS-Billing-3.0-UBL-Rechnung und eine Factur-X-CII-Rechnung dieselbe kaufmännische Rechnung repräsentieren können. Der semantische Inhalt ist identisch. Die XML-Syntax ist vollständig unterschiedlich.

Business Terms und Business Groups

EN16931 organisiert Rechnungsdaten in Business Groups (BG) und Business Terms (BT).

Eine Business Group ist eine Sammlung verwandter Terms. Ein Business Term ist ein einzelnes Datenelement mit einer definierten Kennung, einem Namen, einer Kardinalität und einem Datentyp.

Die wichtigsten Gruppen auf der obersten Ebene:

GruppeInhalt
BG-2 ProzesssteuerungSpezifikationskennung (BT-24), Geschäftsprozesstyp (BT-23)
BG-4 LieferantName, Adresse, USt.-Nummer, Handelsregistereintrag
BG-7 KäuferName, Adresse, Referenzkennung, elektronische Adresse
BG-22 DokumentengesamtbeträgeSteuerbasis, Rechnungsgesamtbetrag, USt.-Betrag, fälliger Betrag
BG-25 RechnungspositionMenge, Einzelpreis, USt.-Satz, Positionsnettobetrag

Das vollständige Modell umfasst über 150 BTs über alle Gruppen. Die meisten Implementierungen benötigen nur eine Teilmenge, aber für die Validierung eines Dokuments ist es erforderlich zu wissen, welche BTs für das Zielprofil Pflicht sind.

Business Terms, über die Entwickler stolpern

Die meisten Validierungsfehler entstehen durch eine kleine Anzahl von BTs, die entweder missverständlich oder in Implementierungsleitfäden schlecht dokumentiert sind.

BT-24: Spezifikationskennung

Dies muss eine spezifische URI sein, die das Profil identifiziert, dem die Rechnung entsprechen soll. Für Peppol BIS Billing 3.0:

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1

Ein falscher Wert führt dazu, dass der Validator des Empfängers die Rechnung ablehnt, bevor er Feldinhalt prüft. Jedes Profil (EN16931-Kern, Peppol BIS 3.0, Peppol BIS 3.0 mit nationaler Erweiterung) hat eine andere URI.

BT-10: Käuferreferenz

Wird in verschiedenen Ländern unterschiedlich verwendet. In Deutschland enthält dieses Feld die Leitweg-ID, eine Pflichtkennung für das Routing bei B2G-Rechnungen. In den meisten anderen Ländern ist es eine interne Bestellreferenz oder bleibt leer. Das Feld ist in EN16931 Basis optional, aber im deutschen nationalen Profil Pflicht.

BT-49: Elektronische Adresse des Käufers

Die Peppol-Teilnehmer-ID des Käufers. Format: Schema:Kennung. Für ein belgisches Unternehmen, das durch Unternehmensnummer identifiziert wird:

<cbc:EndpointID schemeID="0208">0468863455</cbc:EndpointID>

Erforderlich bei der Übertragung über das Peppol-Netzwerk. Viele Implementierungen lassen es bei B2B-Rechnungen außerhalb von Peppol weg, was bei EN16931-Basis akzeptabel ist, aber bei Peppol-BIS-Profilen ungültig ist.

BT-131: Positionsnettobetrag

Der Nettobetrag für eine einzelne Position, berechnet als Menge mal Einzelpreis minus positionsbezogene Nachlässe. EN16931-Business-Rule BR-CO-10 verlangt, dass die Summe aller BT-131-Werte BT-106 (Summe der Positionsnettbeträge) entspricht.

Rundung ist hier wichtig. Der Standard erwartet, dass Arithmetik mit Rohwerten durchgeführt und auf Aggregatebene gerundet wird, nicht pro Position. Jede Position einzeln zu runden und dann zu summieren führt zu Abweichungen, die bei großen Mengen BR-CO-10 brechen.

BT-110: USt.-Kategoriensteuerbetrag

Der USt.-Betrag pro Steuerkategorie. EN16931-Regel BR-CO-15 verlangt, dass der Rechnungsgesamtbetrag minus die Steuerbasis der Summe aller BT-117 (USt.-Kategoriensteuerbeträge) entspricht. Fehler entstehen hier oft durch Fließkomma-Arithmetik oder vorzeitige Rundung.

Business Rules: die Validierungsschicht

Business Rules (BR) sind formale Einschränkungen, ausgedrückt in Schematron. Es gibt zwei Kategorien.

Strukturregeln erzwingen Feldanwesenheit und -format:

BR-01: An Invoice shall have a Specification identifier (BT-24).
BR-02: An Invoice shall have an Invoice number (BT-1).
BR-04: An Invoice shall have an Invoice currency code (BT-5).

Berechnungsregeln erzwingen arithmetische Konsistenz:

BR-CO-10: Sum of Invoice line net amount (BT-106) = sum of all BT-131 values.
BR-CO-15: Invoice total VAT amount (BT-110) = sum of all BT-117 values.
BR-CO-16: Amount due for payment (BT-115) = Invoice total with VAT (BT-112)
          - Paid amount (BT-113) + Rounding amount (BT-114).

Peppol BIS 3.0 fügt nationale Erweiterungsregeln über EN16931-Basisregeln hinzu. Beispiele:

BR-DE-TMP-32: Delivery date (BT-72) is required for German B2G invoices.
BR-DE-18:     VAT identifier of the seller (BT-31) or tax registration (BT-32)
              shall be present.

Diese Erweiterungsregeln variieren nach Länderprofil und werden mit jedem Peppol-BIS-Release veröffentlicht.

Wie EN16931 auf UBL und CII abgebildet wird

Die zwei XML-Syntaxen behandeln dieselben BTs, verwenden aber vollständig unterschiedliche Elementnamen und -strukturen. Deshalb kann Code, der UBL-Rechnungen parst, keine CII-Rechnungen ohne eine separate Implementierung parsen, auch wenn beide EN16931-konform sind.

Lieferantenname (BT-27) in beiden Syntaxen:

UBL 2.1:

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyName>
      <cbc:Name>Acme GmbH</cbc:Name>
    </cac:PartyName>
  </cac:Party>
</cac:AccountingSupplierParty>

UN/CEFACT CII:

<ram:SellerTradeParty>
  <ram:Name>Acme GmbH</ram:Name>
</ram:SellerTradeParty>

Beide bilden auf BT-27 ab. Der semantische Inhalt ist identisch. Der XML-Pfad unterscheidet sich vollständig.

Peppol BIS 3.0 verwendet UBL. Factur-X und ZUGFeRD verwenden CII. XRechnung unterstützt beide. Das EN16931-2-Abbildungsdokument (kostenlos von CEN/TC 434) listet beide Pfade für jeden BT auf und ist während der Implementierung hilfreich.

Schematron-Validierung

EN16931-Validierung ist als Schematron-Regeln implementiert, die zu XSLT 2.0 vorkompiliert werden. Die offiziellen Regelwerke werden mit jedem Peppol-BIS-Release veröffentlicht:

github.com/OpenPEPPOL/peppol-bis-invoice-3/releases

Die Artefakte enthalten kompilierte XSLT-Dateien:

peppol-en16931-ubl.xsl    (for UBL invoices)
peppol-en16931-cii.xsl    (for CII invoices)

Das Ausführen einer dieser Dateien gegen eine Rechnung gibt SVRL (Schematron Validation Report Language) zurück. Eine fehlgeschlagene Regel sieht so aus:

<svrl:failed-assert test="..." location="/Invoice/...">
  <svrl:text>
    [BR-CO-10]-Sum of Invoice line net amount (BT-106) = 
    sum of Invoice line net amount (BT-131).
  </svrl:text>
</svrl:failed-assert>

Ein XSLT-2.0-Prozessor ist erforderlich. In .NET ist Saxon HE (Open Source, keine Enterprise-Lizenz erforderlich) die Standardwahl. In Java funktionieren Saxon oder Xerces.

Häufige Implementierungsfehler

UBL- und CII-Elementpfade mischen. Entwickler, die mit beiden Formaten arbeiten, kopieren Elementnamen aus der falschen Bindung. Das EN16931-2-Abbildungsdokument verhindert das.

Annehmen, dass Anwesenheitsregeln über Profile hinweg gleich sind. Ein Feld, das in EN16931 Basis optional ist, kann in Peppol BIS 3.0 oder in einer nationalen Erweiterung Pflicht sein. Gegen das Zielprofil validieren, nicht gegen den Basisstandard.

Auf der falschen Ebene runden. Rohwerte über alle Positionen arithmetisch berechnen, dann das Aggregat runden. Jede Position einzeln zu runden und gerundete Werte zu summieren führt zu arithmetischen Inkonsistenzen, die BR-CO-10 brechen, oft um ein paar Cent bei großen Rechnungen mit vielen Positionen.

Falsche BT-24 für das Zielprofil. Jedes Profil hat eine spezifische Spezifikationskennung-URI. Die EN16931-Basis-URI auf einer Peppol-BIS-3.0-Rechnung zu verwenden führt dazu, dass die Profilvalidierung das Dokument sofort ablehnt.

USt.-Kategoriecodes hardcoden. EN16931 definiert spezifische Codewerte für USt.-Kategorien (S, Z, E, AE, K, G, O, L, M). Viele Implementierungen hardcoden “S” (Standardsatz) und brechen bei der Verarbeitung von Reverse-Charge- oder Nullsatzrechnungen.

EN16931 ist Infrastrukturwissen

EN16931 bildet die Grundlage jedes europäischen E-Rechnungsmandats. Mit den Anforderungen, die in Belgien, Frankreich, Deutschland und Polen in Kraft treten, wird das Verständnis des semantischen Modells für Entwickler, die Rechnungspipelines aufbauen oder pflegen, zunehmend wichtig.

Das BT/BG-Struktur-, die Berechnungsregeln und die Syntaxbindungen zu verstehen versetzt Sie in die Lage, Validierungsfehler zu debuggen, die sonst stundenlange Spezifikationslektüre erfordern würden, neue Profile sauber zu implementieren und klar mit ERP-Anbietern und Compliance-Teams zu kommunizieren.

Das praktische Problem liegt nicht darin, EN16931 einmal zu lernen. Es liegt darin, Implementierungen korrekt zu halten, wenn Regelwerke mit jedem Peppol-BIS-Release aktualisiert werden, wenn nationale Erweiterungen neue Pflichtfelder hinzufügen und wenn Rundungs-Sonderfälle in der Produktion mit realen Rechnungsdaten aus realen ERP-Systemen auftauchen.

SealDoc liefert mit Regelwerken aus, die Peppol-BIS-Releases folgen. Wenn Sie eine Rechnung über die SealDoc-API generieren, wird das Dokument gegen das richtige Profil validiert, bevor es das System verlässt. BR-CO-10 und BR-CO-15 werden serverseitig erzwungen, sodass Rundungsfehler Ihre Käufer nicht erreichen. Wenn Sie einen Validierungsfehler von einem Handelspartner erhalten, akzeptiert der öffentliche SealDoc-Validator das Dokument und ordnet jeden Fehler dem spezifischen BT und BR zu, der verletzt wurde, was die Diagnosezeit von Stunden auf Minuten reduziert.

Wenn Sie EN16931 von Grund auf implementieren, ist der Validator ein nützliches Kalibrierungswerkzeug: ein Kandidatendokument generieren, es durchlaufen lassen, was der Bericht identifiziert beheben, wiederholen.

← Back to all articles