EN 16931 Entwicklerleitfaden: Business Terms, Regeln und Validierung

EN 16931 definiert eine Rechnung als Liste nummerierter Business Terms (BT-1, BT-2 …), die zu Business Groups (BG-23, BG-25 …) zusammengefasst sind, mit Kardinalitäten und Geschäftsregeln zwischen ihnen. Um eine konforme Datei zu erzeugen, bilden Sie jeden Term auf ein Element einer Syntax ab — UBL 2.1 oder UN/CEFACT CII —, füllen jeden Pflichtterm, sorgen dafür, dass die Summen die Berechnungsregeln (BR-CO-xx) erfüllen, und prüfen das Ergebnis gegen das veröffentlichte Schematron, bevor es Ihr System verlässt. Dieser Leitfaden geht das in der Reihenfolge durch, in der ein Entwickler darauf trifft.

Das Modell, nicht die Datei

Der normative Teil der Norm, EN 16931-1, ist ein semantisches Datenmodell: Er sagt, was eine Rechnung enthält und was jedes Element bedeutet, ohne XML vorzuschreiben. CEN/TS 16931-2 listet die beiden Syntaxen, die akzeptiert werden müssen: UBL 2.1 (Invoice und CreditNote) und UN/CEFACT Cross Industry Invoice (CII) D16B. Die Syntaxbindungen in CEN/TS 16931-3 legen fest, welches Element welchen Term trägt. Die Teile 1 und 2 sind im Rahmen einer Vereinbarung zwischen der Europäischen Kommission und CEN kostenlos bei den nationalen Normungsorganisationen erhältlich; die Bindungen sind kostenpflichtige Dokumente, aber alles, was ein Implementierer zur Validierung braucht — die Schematron-Regeln —, wird vom eInvoicing-Team der Kommission offen auf GitHub veröffentlicht. Hintergrund, Versionen und das CIUS-Konzept der Norm finden Sie unter EN 16931 erklärt.

Drei Konsequenzen prägen die Implementierung:

• Ihr Domänenmodell sollte Business Terms tragen, keine XML-Pfade. Ein einziges internes Rechnungsobjekt, einmal auf UBL und einmal auf CII abgebildet, ist weit weniger Arbeit als zwei handgeschriebene Serialisierer, und dasselbe Objekt dient XRechnung, ZUGFeRD, Factur-X und Peppol BIS, die alle Profile (CIUS) oder Erweiterungen der EN 16931 sind. Siehe die Formate im Vergleich.
• Kardinalität wird durch Schematron erzwungen, nicht nur durch XSD. Eine XSD-gültige UBL-Datei ohne Verkäufernamen ist schema-gültig und EN-16931-ungültig.
• Die Berechnungsregeln sind nach Rundung auf den Cent genau. Gleitkommaarithmetik an irgendeiner Stelle der Pipeline erzeugt früher oder später eine BR-CO-Verletzung.

Die verpflichtenden Business Terms

Das Kernmodell hat einen kleinen Pflichtsatz. Jede EN-16931-Rechnung muss die folgenden Terms tragen; eine CIUS wie XRechnung oder Peppol BIS fügt weitere Anforderungen hinzu (Käuferreferenz, elektronische Adresse des Verkäufers, Zahlungsmittel und so weiter), die von den eigenen Regeln des jeweiligen Profils geprüft werden.

Die vollständige Elementliste mit Kardinalität und Beschreibung für jeden Term steht in EN 16931-1 selbst und ist Element für Element in der Syntaxdokumentation von Peppol BIS wiedergegeben. Die Tabelle oben ist das Arbeitsminimum, kein Ersatz für die Lektüre.

Die Geschäftsregeln

Regeln kommen in Familien, erkennbar am Präfix. Ein Validator meldet die Regelkennung; wer die Familien kennt, versteht die meisten Fehlermeldungen von selbst.

BR-xx

Strukturregeln: Vorhandensein und Kardinalität. BR-01 „An Invoice shall have a Specification identifier (BT-24)“; BR-02 „An Invoice shall have an Invoice number (BT-1)“; BR-03 das Rechnungsdatum; BR-05 die Währung; BR-06 der Verkäufername; BR-07 der Käufername; BR-16 „An Invoice shall have at least one Invoice line (BG-25)“.

BR-CO-xx

Bedingungen und Berechnungen. BR-CO-10: BT-106 = Σ BT-131. BR-CO-13: BT-109 = BT-106 − BT-107 (Nachlässe) + BT-108 (Zuschläge). BR-CO-14: BT-110 = Σ BT-117. BR-CO-15: BT-112 = BT-109 + BT-110. BR-CO-16: BT-115 = BT-112 − BT-113 (bereits gezahlt) + BT-114 (Rundung). BR-CO-17: BT-117 = BT-116 × BT-119 / 100, gerundet auf zwei Dezimalstellen. BR-CO-04 verlangt einen USt-Kategoriecode auf jeder Position.

BR-S, BR-Z, BR-E, BR-AE, BR-IC, BR-G, BR-O, BR-IG, BR-IP

Eine Familie pro USt-Kategoriecode (BT-118/BT-151): S Regelsteuersatz, Z Nullsatz, E steuerfrei, AE Reverse Charge, K innergemeinschaftliche Lieferung, G Ausfuhr, O nicht steuerbar sowie die Steuern der Kanarischen Inseln und von Ceuta/Melilla. Jede Familie legt fest, was die Aufschlüsselung enthalten muss, wenn eine Position dieser Kategorie existiert. BR-AE-01: Eine Rechnung mit einer Reverse-Charge-Position muss genau eine USt-Aufschlüsselung mit Kategorie „AE“ enthalten. BR-S-08: Für jeden Regelsteuersatz entspricht die Bemessungsgrundlage in der Aufschlüsselung der Summe der Positionsnettobeträge (plus Zuschläge, minus Nachlässe) zu diesem Satz.

BR-CL-xx

Codelistenregeln: Der Typcode muss aus UNTDID 1001 stammen (BR-CL-01), die Währung aus ISO 4217, das Land aus ISO 3166-1, Einheiten aus den UN/ECE-Empfehlungen 20 und 21, und so weiter.

UBL-SR-xx, CII-SR-xx

Syntaxregeln: Elemente, die die Bindung nicht verwendet, müssen fehlen, und eingeschränkte Elemente dürfen sich nicht wiederholen.

Regelverletzungen haben eine Kennzeichnung. Ein fataler Fehler bedeutet, dass die Datei keine EN-16931-Rechnung ist und ein Empfänger sie abweisen darf; eine Warnung bedeutet, dass etwas ungewöhnlich, aber erlaubt ist. Behandeln Sie fatale Fehler wie Build-Fehler.

Eine minimale UBL-Rechnung

Die folgende Datei erfüllt die Kernregeln für eine einzelne Position zum Regelsteuersatz von 19 %. Die Namensräume sind die von UBL 2.1; CustomizationID benennt das reine EN-16931-Profil. Eine echte XRechnung- oder Peppol-BIS-Datei braucht zusätzlich ihre eigene CustomizationID, eine ProfileID, eine Käuferreferenz und Zahlungsangaben.

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:CustomizationID>urn:cen.eu:en16931:2017</cbc:CustomizationID>
  <cbc:ID>RE-2026-0142</cbc:ID>
  <cbc:IssueDate>2026-09-03</cbc:IssueDate>
  <cbc:DueDate>2026-10-03</cbc:DueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cac:AccountingSupplierParty><cac:Party>
    <cac:PostalAddress><cbc:StreetName>Beispielstrasse 1</cbc:StreetName>
      <cbc:CityName>Berlin</cbc:CityName><cbc:PostalZone>10115</cbc:PostalZone>
      <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme><cbc:CompanyID>DE123456789</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:PartyTaxScheme>
    <cac:PartyLegalEntity><cbc:RegistrationName>Beispiel GmbH</cbc:RegistrationName></cac:PartyLegalEntity>
  </cac:Party></cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty><cac:Party>
    <cac:PostalAddress><cbc:CityName>Hamburg</cbc:CityName><cbc:PostalZone>20095</cbc:PostalZone>
      <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
    </cac:PostalAddress>
    <cac:PartyLegalEntity><cbc:RegistrationName>Kunde AG</cbc:RegistrationName></cac:PartyLegalEntity>
  </cac:Party></cac:AccountingCustomerParty>
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
      <cac:TaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="HUR">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
    <cac:Item><cbc:Name>Consulting</cbc:Name>
      <cac:ClassifiedTaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price><cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount></cac:Price>
  </cac:InvoiceLine>
</Invoice>

Gehen Sie die Summen gegen die Regeln durch: Positionsnetto 10 × 100,00 = 1000,00 (BT-131); Σ Positionen = 1000,00 (BR-CO-10); keine Nachlässe oder Zuschläge, also BT-109 = 1000,00 (BR-CO-13); eine Aufschlüsselung, S zu 19 %, Bemessungsgrundlage 1000,00, Steuer 190,00 (BR-CO-17); BT-110 = 190,00 (BR-CO-14); BT-112 = 1190,00 (BR-CO-15); nichts vorausgezahlt, BT-115 = 1190,00 (BR-CO-16).

Validierungsartefakte und Werkzeuge

Validieren Sie mit denselben Artefakten, die die Empfänger verwenden. Es gibt keinen Grund, die Regeln neu zu implementieren.

Eine praktische Pipeline führt zuerst XSD aus (billig, fängt fehlerhafte Struktur ab), dann das EN-16931-Schematron, dann das Profil-Schematron (XRechnung oder Peppol) und bei Hybridformaten eine PDF/A-3-Prüfung des Containers. Binden Sie sie mit einem Korpus eigener Dokumente in die Continuous Integration ein: eines pro unterstützter USt-Kategorie, eines mit Nachlässen und Zuschlägen, eine Gutschrift, eines in Fremdwährung mit gesetztem BT-6.

Häufige Validierungsfehler und ihre Ursachen

Die meisten Fehlschläge haben eine Handvoll Ursachen. Sie an der Regelkennung zu erkennen spart Stunden.

• BR-CO-10, BR-CO-13, BR-CO-15 — Summen weichen um 0,01 ab. Die Positionsbeträge wurden einzeln gerundet und die Summen aus ungerundeten Werten berechnet, oder umgekehrt. Legen Sie einen Rundungspunkt fest (pro Position, zwei Dezimalstellen, kaufmännisch, sofern das Profil nichts anderes sagt) und leiten Sie jede Summe aus den gerundeten Positionsbeträgen ab.
• BR-CO-17 — Steuerbetrag der Aufschlüsselung entspricht nicht Bemessungsgrundlage × Satz. Dieselbe Ursache, angewandt auf die USt-Aufschlüsselung. Berechnen Sie BT-117 aus BT-116, nicht durch Summierung der USt auf Positionsebene.
• BR-S-08 / BR-AE-08 / BR-E-08 — die Aufschlüsselung für eine Kategorie existiert, aber ihre Bemessungsgrundlage passt nicht zu den Positionen. Meist wurde ein Nachlass oder Zuschlag auf Dokumentebene in die Summen eingerechnet, aber ohne USt-Kategorie angegeben, oder die Kategorie einer Position und die der Aufschlüsselung stimmen nicht überein.
• BR-AE-02 … BR-AE-04 — Reverse Charge ohne die Kennungen beider Parteien. Für Kategorie AE müssen die USt-IdNr. des Verkäufers und die USt-IdNr. des Käufers (oder dessen Steuerregistrierung) vorhanden sein.
• BR-E-10 / BR-AE-10 — ein Befreiungsgrund ist erforderlich. Eine steuerfreie oder Reverse-Charge-Aufschlüsselung braucht einen Befreiungsgrundtext (BT-120) oder -code (BT-121); eine Nullsatz-Aufschlüsselung (BR-Z-10) darf dagegen keinen tragen.
• BR-CL-xx — ein Code aus der falschen Liste. „PCE“ ist keine gültige Einheit; „C62“ (eins) oder „H87“ (Stück) sind es. „EURO“ ist nicht ISO 4217; „EUR“ ist es. Ländercodes sind zwei Buchstaben, in Großschreibung.
• BR-CO-09 — der USt-IdNr. des Verkäufers fehlt das Länderpräfix („123456789“ statt „DE123456789“).
• BR-01 / unbekannte CustomizationID — die Profilkennung fehlt oder benennt ein Profil, das der Empfänger nicht akzeptiert. Peppol und XRechnung verlangen jeweils ihre eigene exakte Zeichenkette.
• Profilregeln (PEPPOL-EN16931-Rxxx, BR-DE-xx) — der Kern besteht, aber die CIUS scheitert: fehlende Käuferreferenz (BR-DE-15), fehlende elektronische Adresse des Verkäufers, fehlende Zahlungsmittel oder eine falsch formatierte Leitweg-ID. Siehe XRechnung und Peppol.

Um eine einzelne Datei ohne Aufbau einer Toolchain zu prüfen, validiert die kostenlose E-Rechnungsprüfung ein Dokument gegen die Regeln eines Landes und meldet die Regelkennungen, ohne die Datei zu speichern.

Wie KRONENWERK damit umgeht

Unterstützt KRONENWERK erzeugt das strukturierte Dokument in dem Moment, in dem eine Rechnung gestellt wird, und validiert es, bevor die Nummer verbraucht wird: XRechnung und ZUGFeRD für Deutschland, geprüft mit den Schematron-Regeln der KoSIT und gegengeprüft mit der Mustang-Bibliothek; Factur-X für Frankreich; Peppol BIS Billing 3.0 UBL für Belgien; FA(3) für Polen. Die USt-Kategorie jeder Position wird aus einem gespeicherten Steuerurteil abgeleitet (Regelsteuersatz, Nullsatz, steuerfrei, Reverse Charge, nicht steuerbar), nicht eingetippt, und die USt-IdNr. eines Käufers wird bei der Rechnungsstellung gegen VIES geprüft, sodass BR-AE- und BR-CO-09-Fehler nicht aus der Dateneingabe entstehen. Eingehende XRechnung-, ZUGFeRD/Factur-X- und UBL-Dateien werden als Eingangsrechnungen eingelesen. Über die API legt POST /invoices/drafts einen Entwurf an und GET /invoices/{number} liest eine gestellte Rechnung; das Stellen, und damit Erzeugung und Validierung, geschieht im Produkt. Die API akzeptiert kein rohes XML und gibt keines zurück, und sie validiert keine Dateien Dritter — dafür ist die Prüfung da. Siehe die Produktseite zur E-Rechnung und die Rechnungs-API.