Was ist die Europäische Kernrechnung?
Erfahren Sie alles über die Europäische Kernrechnung (EN-16931) – von ihrer Definition und Bedeutung über die historischen und rechtlichen Grundlagen bis hin zu den technischen Aspekten und Vorteilen der Standardisierung in der EU.
1. Executive Summary: Europäische Kernrechnung
Die Europäische Kernrechnung, oft auch als "European Core Invoice" oder "EN-16931" bezeichnet, stellt einen wichtigen Standard für elektronische Rechnungen innerhalb der Europäischen Union dar. Durch sie soll eine einheitliche und maschinenlesbare Struktur für Rechnungsdaten geschaffen werden, um grenzüberschreitende Geschäftstransaktionen zu vereinfachen und Prozesse zu automatisieren. Hierdurch wird die Anpassung an nationale Rechnungsformate deutlich effizienter, einfacher und kostengünstiger.
Die Einführung der Europäischen Kernrechnung ist eng mit den Bestrebungen der EU verknüpft, den digitalen Binnenmarkt zu stärken und administrative Hürden im internationalen Handel zu minimieren. Durch die Standardisierung auf europäischer Ebene profitieren Unternehmen, besonders kleine und mittelständische Betriebe, von einer höheren Wettbewerbsfähigkeit und Transparenz, während gleichzeitig die Anforderungen an Rechtssicherheit und Compliance erfüllt werden.
Die folgenden Abschnitte geben einen detaillierten Überblick über die historische Entwicklung, den rechtlichen Rahmen sowie die konkreten Vorteile der Einführung der Europäischen Kernrechnung und erläutern die wesentlichen technischen Spezifikationen.
2. Einführung in die Europäische Kernrechnung
Definition und Bedeutung der Europäischen Kernrechnung
Die Europäische Kernrechnung, auch "European Core Invoice" oder "EN-16931" genannt, ist ein Standardformat für elektronische Rechnungen, das von der Europäischen Kommission eingeführt wurde. Ziel dieses Standards ist es, eine einheitliche und interoperable Struktur für elektronische Rechnungen innerhalb der Europäischen Union zu schaffen. Die Europäische Kernrechnung gewährleistet, dass alle relevanten Rechnungsdaten in einer strukturierten und maschinenlesbaren Form vorliegen, um die Automatisierung und Effizienz von Rechnungsprozessen zu erhöhen.
Die Bedeutung der Europäischen Kernrechnung liegt in ihrer Fähigkeit, grenzüberschreitende Handelsbeziehungen zu erleichtern, indem sie eine gemeinsame Sprache für Rechnungsdaten bereitstellt. Dies reduziert die Komplexität und die Kosten, die mit der Anpassung an verschiedene nationale Rechnungsformate verbunden sind, und verbessert die Transparenz und Nachvollziehbarkeit von Geschäftstransaktionen.
Historische Entwicklung und rechtlicher Rahmen der Europäischen Kernrechnung
Die Einführung der Europäischen Kernrechnung geht auf die Bemühungen der Europäischen Kommission zurück, den digitalen Binnenmarkt zu fördern und administrative Hürden im grenzüberschreitenden Handel zu verringern. Ein wichtiger Meilenstein war die Veröffentlichung der Richtlinie 2014/55/EU im April 2014, die die Nutzung elektronischer Rechnungen im öffentlichen Auftragswesen vorschrieb. Diese Richtlinie forderte die Entwicklung eines gemeinsamen europäischen Standards für elektronische Rechnungen.
Als Reaktion darauf entwickelte das Europäische Komitee für Normung (CEN) den Standard EN-16931, der im Juni 2017 offiziell veröffentlicht wurde. Seitdem sind alle öffentlichen Auftraggeber in der EU verpflichtet, elektronische Rechnungen im EN-16931-Format zu akzeptieren. Diese Verpflichtung trat am 18. April 2019 in Kraft.
Der rechtliche Rahmen für die Europäische Kernrechnung umfasst neben der Richtlinie 2014/55/EU auch nationale Gesetzgebungen, die die Umsetzung und Einhaltung des Standards in den einzelnen EU-Mitgliedstaaten sicherstellen.
Ziele und Vorteile der Standardisierung von Rechnungen in der EU
Die Standardisierung von Rechnungen in der EU verfolgt sechs wesentliche Ziele:
3. Was ist EN-16931?
Die europäische Richtlinie 2014/55/EU verpflichtet die öffentlichen Auftraggeber innerhalb der EU dazu, Rechnungen in elektronischem Format von Auftragnehmern anzunehmen und zu verarbeiten. Die Europäische Kommission hat das CEN (Comité Européen de Normalisation) damit beauftragt, eine europäische Norm (EN) für ein semantisches Datenmodell einer europäischen Kernrechnung zu erstellen.
Die vom CEN veröffentlichte Norm EN-16931 wurde von den nationalen Normungsgremien, wie z. B. der DIN in Deutschland, übernommen. Das CEN Committee CEN/TC 434 hat zuerst die Anforderungen an eine Rechnung definiert und diese mit einer Anforderungskennung versehen. Diese wurden in das semantische Datenmodell der Kernrechnung übertragen.
Bei der Bewertung und Selektion geeigneter Syntaxen wurden mehrere Syntaxen nach festgelegten Kriterien untersucht und das Ergebnis in dem technischen Anhang EN-169321-2 (CEN/TS 16931-2:2017, Elektronische Rechnungsstellung – Teil 2: Liste der Syntaxen, die die EN-16931-1 erfüllen) veröffentlicht. Nachstehend die Syntaxen, die mit der Norm EN-16931 übereinstimmen:
- UBL (Universal Business Language):
UBL ist ein standardisiertes XML-Format für den elektronischen Geschäftsdatenaustausch, das eine breite Palette von Dokumenttypen abdeckt, einschließlich Rechnungen. Die UBL-Rechnung enthält alle in EN-16931 geforderten Informationen und ist weit verbreitet in der EU. - CII (Cross Industry Invoice):
CII ist ein weiteres XML-basiertes Format, das von der UN/CEFACT entwickelt wurde. Es unterstützt ebenfalls die Anforderungen von EN-16931 und bietet eine alternative Implementierungsmöglichkeit.
Für beide werden sogenannte Syntaxbindings bereitgestellt. Global bzw. EU-weit betrachtet, hat sich dabei die Syntax UBL 2.1 in der Nutzung durchgesetzt. Die Syntax CII wird vor allem bei ZUGFeRD bzw. Factur-X (DE und FR) und in Deutschland bei er XRechnung als zweite zulässige Syntax verwendet. Andere Länder haben sich meistens auf die Verwendung einer einzigen Syntax (UBL 2.1 invoice und credit note) festgelegt.
Die technische Umsetzung der Europäischen Kernrechnung erfordert die Einhaltung bestimmter Spezifikationen und Validierungsregeln, um sicherzustellen, dass die Rechnungen den Standardvorgaben entsprechen und korrekt verarbeitet werden können. Dazu gehören:
- Schematron-Regeln:
Diese XML-Schemata definieren die Struktur und die Validierungsregeln für die Rechnungsdaten. - Syntaxregeln:
Vorgaben zur korrekten Syntax der Rechnungsdaten, um eine fehlerfreie Verarbeitung sicherzustellen.
Was ist der Unterschied zwischen „Semantik“ und „Syntax“?
Die Bedeutung von „Semantik“
Semantik (von altgriechisch σημαίνειν sēmaínein, deutsch ‚bezeichnen, ein Zeichen geben‘) ist die wissenschaftliche Beschäftigung mit Bedeutung und den verschiedenen Beziehungen zwischen einem Zeichen und dem Bezeichneten. (Quelle: https://de.wikipedia.org/wiki/Semantik (abgerufen am 20.9.2024)).
Die europäische Kernrechnung basiert auf einer klaren Definition der Inhalte und ihrer Bedeutung. Die Inhalte und ihre Bedeutung sind in der EN-16931 beschrieben. Zusätzlich zum inhaltlichen Umfang werden auch Geschäftsregeln definiert, die die allgemeinen Compliance-Kriterien für eine gültige Rechnung beschreiben. Daraus lässt sich ableiten, ob Inhalte einer Verpflichtung optional sind oder einer Bedingung unterliegen, also in den Geschäftsregeln definierten Abhängigkeiten unterliegen. Werden Inhalte nicht in Textform angegeben, sondern codiert, ist in der semantischen Definition auch festgelegt, welche Codelisten verwendet werden.
Die semantische Definition schafft ein allgemeines Verständnis der Inhalte und deren Bedeutung in einer elektronischen Rechnung.
Diese Informationen sind von entscheidender Bedeutung für die Fachbereiche, denn sie bestimmen, welche Informationen erforderlich sind, um eine korrekte Rechnung zu erstellen.
Beispiel-Auszug aus dem semantischen Datenmodell:
ID | Ebene | Kardinalität | Betriebswirtschaftlicher Begriff | Beschreibung | Hinweis zur Nutzung | Anforderungskennung | Semantischer Datentyp3 |
BT-1 | + | 1..1 | Rechnungsnummer | Eine eindeutige Kennung der Rechnung | Die nach Artikel 226 (2) der Richtlinie 2006/112/EG [2] geforderte fortlaufende Nummer, die zur Identifizierung der Rechnung innerhalb des Geschäftskontextes, des Zeitrahmens, der Betriebssysteme und der Aufzeichnungen des Verkäufers einmalig vergeben wird. Sie kann auf einer oder mehreren Reihen von Nummern basieren, die alphanummerische Zeichen enthalten dürfen. Es ist kein Identifikationsschema zu verwenden. | R56 | Kennung |
BT-2 | + | 1..1 | Rechnungsdatum | Das Datum, an dem die Rechnung ausgestellt wurde | - | R56 | Datum |
BT-3 | + | 1..1 | Code für den Rechnungstyp | Ein Code, der den Funktionstyp der Rechnung angibt | Handelsrechnungen und Gutschriften sind nach den Einträgen in UNTDID 1001 [6] definiert. Andere Einträge aus UNTDID 1001 [6] mit spezifischen Rechnungen oder Gutschriften dürfen, falls zutreffend, verwendet werden. | R44 | Code |
BT-5 | + | 1..1 | Code für die Rechnungswährung | Die Währung, in der alle Rechnungsbeträge angegeben werden, ausgenommen ist Steuergesamtbetrag in Buchungswährung | Die Rechnung ist nur in einer Währung auszustellen, ausgenommen hiervon ist nach Artikel 230 der Richtlinie 2006/112/EG über Umsatzsteuer der Steuergesamtbetrag in Buchungswährung (BT-111). Die Listen der zugelassenen Währungen werden von der ISO 4217 Maintenance Agency „Codes for the representation of currencies and funds“ geführt. | R54, R47 | Code |
Abbildung 1: Semantisches Datenmodell der Kernelemente von elektronischen Rechnungen (Quelle: EN-16931-1)
Die Bedeutung von „Syntax“
Die Syntax hingegen legt fest, wie die Angaben zu erfolgen haben. Man kann dies auch als Sprache oder Schrift definieren. Die Syntax legt fest, wie Inhalte wiedergegeben werden. Dabei gelten je nach Syntax unterschiedliche Regeln. Es ist durchaus vergleichbar mit der Kommunikation in Deutsch oder Englisch oder dem Einsatz des lateinischen oder griechischen Alphabets.
Diese Informationen sind in erster Linie für die IT-Spezialisten, die die technische Umsetzung realisieren, von Bedeutung.
Die Bedeutung von „Syntaxbinding“
Die Syntaxbindings sorgen dafür, dass die semantischen Inhalte auf die Strukturen der Syntaxen (Pfade) gemappt werden. Die Verwendung der semantischen Inhalte wird somit exakt auf die Informationselemente der jeweiligen Syntax zugewiesen. Das Syntaxbinding ist eine Schnittstelle, die zwischen Fachlichkeit und technischer Umsetzung vermittelt. Hier finden beide Parteien zueinander.
Beispiel-Auszug aus dem Syntaxbinding für UBL 2.1 Invoice:
ID | Ebene | Kardinalität | BT | Beschreibung | DT | Pfad | Typ | Kardinalität | Zuordnung | Regeln |
BT-1 | 1 | 1..1 | Rechnungsnummer | Eine eindeutige Identifizierung der Rechnung. | I | /Invoice/cbc:ID | I | 1..1 | ||
BT-2 | 1 | 1..1 | Rechnungsdatum | Das Datum, an dem die Rechnung ausgestellt wurde. | D | /Invoice/cbc:IssueDate | D | 1..1 | ||
BT-3 | 1 | 1..1 | Code des Rechnungstyp | Ein Code, der den Funktionstyp der Rechnung angibt. | C | /Invoice/cbc:InvoiceTypeCode | C | 0..1 | CAR-2 | |
BT-5 | 1 | 1..1 | Code für die Rechnungswährungs | Die Währung, in der alle Rechnungsbeträge angegeben werden, ausgenommen ist Steuergesamtbetrag in Buchungswährung. | C | /Invoice/cbc:DocumentCurrencyCode | C | 0..1 | CAR-2 | |
BT-6 | 1 | 0..1 | Code für die Wäh-rung der Umsatzsteuerbuchung | Für die Umsatzsteuerbuchung- und -Meldezwecke verwendete Währung, die im Land des Verkäufers gültig ist oder verlangt wird. | C | /Invoice/cbc:TaxCurrencyCode | C | 0..1 | SEM-2 | |
BT-7 | 1 | 1..1 | Datum der Steuerfälligkeit | Angabe eines Datums, in Übereinstimmung mit der Umsatzsteuerrichtlinie, an dem die Umsatzsteuer für den Verkäufer und für den Käufer abrechnungsrelevant wird, insoweit als dieses Datum bestimmt werden kann und vom Rechnungsdatum abweicht… | D | /Invoice/cbc:TaxPointDate | D | 0..1 | SEM-2 |
Abbildung 2: Auszug aus dem Mapping des Semantischen Modells auf die UBL Rechnungssyntaxelemente (Quelle: EN 16931-3-2_DE_UBL)
Welche Inhalte umfasst die EN-16931?
Das europäische Kernrechnungsmodell in der aktuellen Fassung wurde unter Berücksichtigung der Bedürfnisse der öffentlichen Verwaltungen als Rechnungsempfänger entwickelt. Im Fokus standen dabei die Anforderungen der Umsatzsteuergesetzgebung und die Anforderungen aus den Beschaffungsprozessen der Verwaltung. Diese Aspekte haben den semantischen Umfang maßgeblich beeinflusst.
Die definierten Inhalte lassen sich grob in mehrere Gruppen unterteilen:
- Angaben zur Prozesssteuerung (BG-2)
- Angaben zum Verkäufer (BG-4)
- Angaben zum Käufer (BG-8)
- Angaben zum Zahlungsempfänger (BG-10)
- Angaben zum Steuerbevollmächtigen des Verkäufers (BG-11)
- Lieferinformationen und Anschrift (BG-13 + BG-15)
- Angaben zu den Rechnungspositionen (BG-25)
- Zahlungsanweisungen und Informationen (BG-16 + ff)
- Umsatzsteueraufschlüsselung (BG-23)
- Gesamtsummen (BG-22)
- Referenzen und Rechnungsbegründende Unterlagen / Anhänge (BG-24)
Die einzelnen Gruppen beinhalten selbstverständlich die Informationselemente, die zu den jeweiligen Gruppen gehören. In der EN-16931 wurden sowohl den Gruppen als auch den Informationselementen selbst eindeutige Kennungen zugewiesen.
- Gruppe = Business-Terms-Group bzw. Gruppe betriebswirtschaftlicher Begriffe kurz BG.
- Informationselement = Business-Term bzw. Betriebswirtschaftlicher Begriff kurz BT.
Die Kennungen der Gruppen und Informationselemente sind wie folgt aufgebaut:
- Gruppe (Business-Terms-Group bzw. Gruppe betriebswirtschaftlicher Begriffe) = BG-x*
- Informationselement (Business-Term bzw. Betriebswirtschaftlicher Begriff) = BT-x*
*x steht für eine Ziffer (derzeit ein- bis zweistellig)
Können alle Geschäftsvorfälle mit der EN-16931 abgebildet werden?
Es ist nicht möglich, alle Arten von Geschäftsvorfällen abzubilden. Der Auftrag für die derzeitige Normung wurde in erster Linie für den Bedarf der öffentlichen Verwaltung erteilt. Die Unterstützung wurde daher auf einen einfachen Purchase-to-Pay-Prozess (P2P) beschränkt. Die Kernrechnung unterstützt keine komplexen P2P-Prozesse wie beispielsweise die lieferantengesteuerte Lagerverwaltung, die Rechnungsstellung im Namen mehrerer Geschäftspartner auf derselben Rechnung oder die Rechnungsstellung für komplexe Produkte. Diese Prozesse werden nicht durch die Kernrechnung unterstützt. Die Erweiterungsmechanismen bieten jedoch die Möglichkeit, die Kernrechnung auch für diese Zwecke zu erweitern.
Was ist eine CIUS und was ist eine Extension?
Für landes- oder branchenspezifische Erweiterungen gibt es zwei Methoden in der Norm, nämlich die Core Invoice Usage Specification (CIUS) und die Extension.
Eine CIUS ist eine Anwendungsspezifikation zur europäischen Kernrechnung. Diese muss selbstverständlich der europäischen Norm „compliant“ sein. Das bedeutet, dass für eine bestimmte Region/Land oder Geschäftssituation weitergehende Anwendungsempfehlungen, Geschäftsregeln oder Einschränkungen zu den in der EN-16931 vorgegebenen definiert werden müssen. Eine CIUS muss immer vollständig compliant zur EN-16931 sein. Das bedeutet, dass ein Empfänger weiterhin in der Lage ist, die Rechnung in Übereinstimmung mit dem Kernrechnungsmodell zu empfangen. Es besteht die Möglichkeit, Inhalte einzuschränken, beispielsweise indem optionale Angaben zu Pflichtangaben gemacht werden oder Einschränkungen in den verwendeten Codelisten vorgenommen werden. Zusätzlich können Beschreibungen zur Erläuterung gemacht werden, welche Angaben in einem bestimmten Feld erwartet werden.
Beispiel XRechnung in Deutschland
- Die PLZ in den Adressangaben ist in der Kernrechnung optional, in der XRechnung ist dieses eine MUSS-Angabe. Andernfalls wären die Adressangaben unvollständig.
- Das Feld BT-10 „Buyer-Reference“ ist im Kernrechnungsmodell optional. Bei Empfängern in der öffentlichen Verwaltung ist diese Angabe zur Identifizierung des unmittelbaren Empfängers „Abteilung“ verpflichtend. Die Verwendung der sogenannten Leitweg-ID ist dabei verpflichtend.
Im Gegensatz zu einer CIUS bietet eine Extension die Möglichkeit zur Erweiterung des vorgegebenen Umfangs. Eine Extension muss „conformant“ zur Kernrechnung sein. Das bedeutet, dass alle Merkmale des Kernrechnungsmodells verwendet werden und eine Erweiterung um zusätzliche Funktionen stattfindet.
Beispiele hierfür sind:
- Es werden Erweiterungen in einer Codeliste durchgeführt, wie die Erweiterung der Codeliste für die „Mime type codes“ um code application/xml für die Typen der möglichen Anhänge (vgl. XRechnung Extended Regel BRDEX-01 für BT-125 „Attached document“).
- Es wird eine Erweiterung des semantischen und damit syntaktischen Umfangs gemacht (vgl. XRechnung Extended – SUB INVOICE LINE [BG-DEX-01] Informationen über einzelne untergeordnete Rechnungspositionen).
Die Regeln für die Erstellung einer Extension werden in den technischen Anhängen der EN-16931 Teil 5 (CEN/TR 16931-5:2017, Elektronische Rechnungsstellung – Teil 5: Leitfaden über die Verwendung von branchen- oder länderspezifischen Erweiterungen der EN-16931-1 einschließlich einer im realen Umfeld einzusetzenden Methodik) beschrieben.
Welche CIUS oder Extensions gibt es zur EN-16931?
Im Folgenden einige prominente Beispiele:
- Deutschland: XRechnung und XRechnung Extended
- Deutschland, Frankreich, Schweiz: ZUGFeRD/FacturX 2.0, 2.1, 2.2, 2.3 Profil Comfort/EN-16931 und Profil Extended
- Niederlande: SIUBL 2.0 (Niederlande)
Einige Länder haben keine eigene CIUS oder Extension definiert, sondern nutzen im Peppol-Netzwerk die Spezifikation Peppol BIS Billing 3.0 von Open Peppol.
Sind spezielle Kenntnisse erforderlich, um eine E-Rechnung gemäß EN-16931 zu erstellen?
Diese Frage lässt sich weder mit „Ja” noch mit „Nein” beantworten, sondern muss unter verschiedenen Gesichtspunkten betrachtet werden:
- Technische Ausführung: Erstellung der Rechnung in einer der vorgegebenen Syntaxen
- Inhaltliche Ausführung
Für die technische Ausführung sind spezielle Kenntnisse zum Aufbau der Strukturen erforderlich. Diese Kenntnisse sind entweder in der eigenen IT-Abteilung vorhanden oder werden durch externe Dienstleister bereitgestellt.
Die Inhalte des semantischen Modells sollten dem Aussteller einer Rechnung im Wesentlichen bekannt sein. Dies ist unabhängig davon, ob die Rechnung digital oder in Papierform vorliegt. Diese Inhalte unterscheiden sich nicht wesentlich von den Informationen, die auch eine analoge Rechnung enthalten muss, um den Anforderungen der Umsatzsteuergesetzgebung oder allgemeiner Regeln der Rechnungsprüfung zu entsprechen. Die inhaltliche Ausführung muss den Vorgaben der europäischen Kernrechnung und den hier definierten Geschäfts- und Prüfregeln entsprechen. Nur so lässt sich eine einheitliche und automatisierte Prüfung diverser Bestandteile der Rechnung gewährleisten. Abweichungen zu diesen Regeln werden im Verarbeitungsprozess einer E-Rechnung nicht toleriert. Deshalb sind keine speziellen Kenntnisse erforderlich, aber die semantische Definition und die damit verbundenen Geschäftsregeln sollten auch einem Fachbereich bekannt sein. Nur so kann er seine inhaltlichen Anforderungen in dieses Umfeld einbetten.
Ein in der Praxis immer wieder auftauchendes Problem sind z. B. Rundungsdifferenzen, die u. a. durch die Übernahme bereits gerundeter Werte in der Verarbeitung bzw. Datenfortschreibung in den ERP Systemen entstehen können. Die Regeln der europäischen Kernrechnung sehen in den Prüfungen keine Toleranzen gegenüber Rundungsdifferenzen vor. Die in der bestehenden Rechnungspraxis gängige Art, sei es analog oder auch im Bereich EDI (EDIFACT INVOICE), geringe Differenzen aus der Rundung zu tolerieren, kann aufgrund der vorhandenen allgemeinen Prüfregeln aus der EN-16931 nicht allgemein auf die elektronische Rechnung angewendet werden. Grade die öffentlichen Portale lehnen Rechnungen die nicht den Regeln entsprechen üblicherweise direkt ab.
Können Rundungsdifferenzen nicht komplett vermieden werden, hat die KoSIT eine Handlungsempfehlung herausgegeben. Diese basiert auf der Nutzung der BT-114 (Rounding Amount) in den Rechnungssummen (BG-22 „Document Totals“).