Sie sind hier:

Frequently Asked Questions

Stand: Juli 2021

Die folgende FAQ-Liste wird laufend ergänzt:
Fragen zum aktuellen Release
Aktueller Umsetzungsstand der Einführung der elektronischen Rechnung im öffentlichen Sektor
Verbindlichkeit des Standards
Inhaltliche Fragen zum Standard
Steuer- und handelsrechtliche Fragen zur XRechnung
Technische Umsetzung
Fragen zur Leitweg-ID
Betrieb und Weiterentwicklung
Tests, Erprobung und Qualitätssicherung
Hintergründe zur Entwicklung
Fragen zur elektronischen Rechnungsstellung im Bauwesen
Fragen zur elektronischen Rechnungsstellung in der Energiewirtschaft
Fragen zur Implementierung
Fragen zur Rundung

Fragen zum aktuellen Release

Warum wird eine XRechnung abgelehnt, die mit der vorherigen Prüfkonfiguration angenommen wurde?
Die Validator-Konfiguration besteht immer aus den europäischen Komponenten (EN 16931 Validation artefacts) und dem XRechnungsanteil, d.h. auch wenn sich im XRechnungs-Teil keine gravierenden Änderungen ergeben haben, können Änderungen in den EN 16931 Validation artefacts zu Ablehnungen von Rechnungen führen, die mit einer vorausgehenden Prüfkonfiguration angenommen wurden. In unserem Changelog (https://github.com/itplr-kosit/validator-configuration-xrechnung/blob/master/CHANGELOG.md) verweisen wir auch immer auf die verwendeten europäischen Komponenten.

Warum wird eine XRechnung auf Grund von Syntaxfehlern abgelehnt, die mit der vorherigen Prüfkonfiguration angenommen wurde?
In den EN16931 Validation artefacts v.1.3.3 wurde das severity-Level für die UBL-SR-xxx Regeln von warning auf fatal gesetzt. Daher kann es jetzt zu Ablehnungen von XRechnungen kommen, die mit früheren Prüfkonfigurationen angenommen wurden. Details dazu in den CEN Release notes (https://github.com/ConnectingEurope/eInvoicing-EN16931/releases/tag/validation-1.3.3) und im zugehörigen CEN-Ticket (https://github.com/ConnectingEurope/eInvoicing-EN16931/issues/214).

Warum wird eine XRechnung mit Skontoangaben in BT-20 Payment terms abgelehnt, die mit der vorherigen Prüfkonfiguration angenommen wurde?
Die Überprüfung der Anforderungen an die Abbildung von Skonto, die in BT-20 Payment terms beschrieben und mit BR-DE-18 festgesetzt werden, wurde mit dem letzten Release präzisiert, vgl. Release Notes in https://github.com/itplr-kosit/xrechnung-schematron/releases/tag/release-1.5.0). Häufig ist ein fehlender Zeilenumbruch nach dem schließenden # am Ende der Skontoangaben ursächlich für die Fehlermeldung.

Aktueller Umsetzungsstand der Einführung der elektronischen Rechnung im öffentlichen Sektor

Das hier bereitgestellte Dokument gibt den aktuellen Stand der Umsetzungsvorhaben zu elektronischen Rechnungen bei Bund und Ländern wieder. Es dient als Informationsquelle und wird ständig aktualisiert. Für die Vollständigkeit und Richtigkeit der Angaben sind Bund und Länder verantwortlich, die Koordinierungsstelle für IT-Standards übernimmt keine Gewähr für Richtigkeit und Vollständigkeit der Informationen.

Aktueller Umsetzungsstand der Einführung der elektronischen Rechnung im öffentlichen Sektor (Fassung vom 24.07.2020) (pdf, 244.8 KB)

Gibt es eine Übersicht, wie viele bzw. welche Behörden in Deutschland bereits über via Peppol elektronische Rechnungen empfangen können?
Die Länder werden regelmäßig zum Stand der Umsetzung abgefragt. Die Ergebnisse werden in der Ländersynopse festgehalten. Hierzu gehört auch, ob und wie sie sich an Peppol anschließen.

Verbindlichkeit des Standards

Ist der Standard XRechnung bereits vom IT-Planungsrat beschlossen worden?
Ja. Der Standard XRechnung ist vom IT-Planungsrat in der 23. Sitzung beschlossen worden. Mit dem Beschluss hat der IT-Planungsrat festgestellt, dass XRechnung die jeweils gültige Fassung der europäischen Norm für die elektronische Rechnungsstellung EN 16931 konkretisiert, und hat den Standard XRechnung als maßgeblich für die Umsetzung der Richtlinie 2014/55/EU des europäischen Parlaments und des Rates vom 16. April 2014 in Deutschland beschlossen.

Setzt XRechnung die Verpflichtungen der Europäischen Richtlinie 2014/55/EU verbindlich um?
Ja, XRechnung wird immer in Abhängigkeit zur Europäischen Norm entwickelt. Der Standard konkretisiert die jeweils gültige Fassung der europäischen Norm für die elektronische Rechnungsstellung EN 16931 als Core Invoice Usage Specification (CIUS).

Nehmen öffentliche Auftraggeber ausschließlich Rechnungen im XRechnungs-Format an?
Die EU-Richtlinie 2014/55/EU verpflichtet öffentliche Auftraggeber, elektronische Rechnungen, die der EN 16931 entsprechen, anzunehmen und zu verarbeiten. Dies gilt für alle Rechnungen, die aus einer EU-weiten Vergabe (oberschwelliger Bereich) resultieren. XRechnung setzt die EN 16931 verbindlich für öffentliche Auftraggeber in Deutschland um. Weitere Informationen zur Annahme von elektronischen Rechnungen in anderen Formaten finden sich im aktuellen Umsetzungsstand (siehe oben) sowie in den Informationen zu den rechtlichen Grundlagen.

Gilt XRechnung auch zwingend für Gebührenbescheide?
Nein, Gebührenbescheide basieren auf Rechtsgrundlagen, welche nicht dem Geltungsbereich der Europäischen Richtlinie 2014/55/EU unterliegen. Von daher muss XRechnung nicht für Gebührenbescheide verwendet werden.

Gilt XRechnung auch für Auslandsvertretungen wie die deutsche Botschaften?
Die ERechnungs-Verordnung des Bundes regelt den Geltungsbereich für Auslandsvertretungen im §9. In den meisten Fällen wird die Rechnungsadresse aber das Auswärtige Amt sein.

Gilt XRechnung auch für ausländische Lieferanten?
Die Verpflichtung findet Anwendung auf alle Rechnungssender, die unter § 14 BGB fallen und im Rahmen öffentlicher Aufträge mit der öffentlichen Verwaltung in Deutschland interagieren.

nach oben

Inhaltliche Fragen zum Standard

Was ist die Rechnung?
Im Sinne der EU-Richtlinie handelt es sich bei der Rechnung um einen strukturierten Datensatz (in den bei Bedarf rechnungsbegleitende Unterlagen eingebunden werden können). Eine bildhafte Darstellung der Rechnung (beispielsweise als PDF) entspricht nicht den Anforderungen der Europäischen Kommission an eine elektronische Rechnung. Das bedeutet, dass der strukturierte Datensatz das Rechnungsoriginal ist.

Unter welchen Voraussetzungen ist eine Rechnung konform zum Standard XRechnung?
Die Konformitätskriterien sind Teil des Standards XRechnung.

Das Trägerdokument der Rechnungsinformationen ist im Sinne der Richtlinie ausschließlich ein XML-Dokument. Können trotzdem Anhänge (z.B. als rechnungsbegründende Unterlagen) mit der Rechnung übermittelt werden?
Ja, die Europäische Norm (und damit auch XRechnung als CIUS) erlauben das Übermitteln beigefügter Dokumente als rechnungsbegründende Unterlagen. Die Details sind im Standard beschrieben.

XRechnung bezieht sich nur auf die auszutauschenden Rechnungsdaten. Gibt es auch Vorgaben für die Verarbeitung der Rechnungen?
Nein. Das Kooperationsprojekt des Bundes und der Freien Hansestadt Bremen hat aber ein Architekturkonzept entwickelt; hier werden vollständige Lösungen zum Empfang und zur Bearbeitung elektronischer Rechnungen im Format XRechnung implementiert. Dieses Architekturkonzept dient als Blaupause und kann von öffentlichen Auftraggebern genutzt werden. Die weiteren Partner des Kooperationsprojekts, Nordrhein-Westfalen und Rheinland-Pfalz, prüfen die Umsetzung Architekturkonzeptes für elektronische Rechnungsstellung für das Land unter Einbindung der Kommunen. Damit wird die Praxistauglichkeit für alle föderalen Ebenen gewährleistet.

XRechnung bezieht sich nur auf die auszutauschenden Rechnungsdaten. Gibt es auch Vorgaben für die Übertragung der Rechnungen?
Der Standard XRechnung formalisiert ausschließlich die Rechnung selber (Format, Datenstruktur und Semantik), der Übermittlungsweg der Rechnung wird im Standard XRechnung nicht betrachtet. Um dennoch zu ermöglichen, dass alle öffentlichen Auftraggeber als Rechnungsempfänger über mindestens einen einheitlichen Weg Rechnungen empfangen könnten, hat der IT-Planungsrat den Anschluss an die PEPPOL-Infrastruktur als einheitlichen sicheren Webservice auf Basis eines Prüfauftrags beschlossen. Er verpflichtet Bund und Länder, mit Ablauf der Umsetzungsfrist der Richtlinie 2014/55/EU mindestens PEPPOL anzubieten, wenn sie einen Webservice zur Einlieferung von elektronischen Rechnungen zur Verfügung stellen (weitere Informationen zur Übertragung von Rechnungen hier).

Wie können Angaben zum Skonto übermittelt werden?
Die strukturierte Übertragung von Skontoinformationen ist in der zugrundeliegenden EN 16931 nicht vorgesehen. XRechnung hat daher eine Möglichkeit zur strukturierten Übermittlung von Skonto in BT-20 Payment terms geschaffen. Details dazu sind im Standard XRechnung beschrieben. Zusätzlich zu der strukturierten Übermittlung von Skonto können auch unstrukturierte Zahlungsbedingungen (wie bspw. Verzugszinsen) übermittelt werden. Gleichzeitige strukturierte und unstrukturierte Übermittlung von Zahlungsbedingungen in BT-20 schließen sich nicht aus.

Wie können weitere Angaben zu den Zahlungsbedingungen übermittelt werden?
Zahlungsbedingungen können in BT-20 Payment terms übermittelt werden. Gleichzeitige strukturierte (siehe Skonto) und unstrukturierte Übermittlung von Zahlungsbedingungen in BT-20 schließen sich nicht aus.

Wie können Informationen zum Zahlungsweg übermittelt werden?
Mit XRechnung sollen detaillierte Angaben zum Zahlungsweg im Falle der Überweisung, der Kartenzahlung und bei Nutzung des Lastschriftverfahrens gemacht werden. Dafür stehen die drei Gruppen von Elementen BG-17, BG-18 und BG-19 zur Verfügung. Je nach Auswahl des Zahlungsweges soll nur eine der drei Gruppen mit den erforderlichen Angaben befüllt werden (BR-DE-13: In der Rechnung müssen Angaben zu genau einer der drei Gruppen „CREDIT TRANSFER“ (BG-17),
„PAYMENT CARD INFORMATION“ (BG-18) oder „DIRECT DEBIT“ (BG-19) übermittelt werden.).

Im Falle der Überweisung müssen Informationen über Bankkonten, auf die die Überweisung erfolgen soll, übermittelt werden. Dazu werden die Elemente der BG-17 genutzt. Hierbei kann BG-17 mehrfach vorkommen, wenn Angaben zu mehreren Konten gemacht werden sollen.

Im Falle der Kartenzahlung müssen Angaben zu einer für die Zahlung genutzten Karte übermittelt werden. Dazu wird BG-18 verwendet. Die Gruppe darf nur einmal verwendet werden, da bei einer Zahlung immer nur eine Karte belastet wird.

Im Falle der Lastschrift müssen Angaben zum ausgewählten Konto übermittelt werden. Dazu wird die Gruppe BG-19 DIRECT DEBIT genutzt. Die Gruppe darf nur einmal verwendet werden, weil mit der Lastschrift ein bestimmtes Konto belastet werden soll, dessen Angabe mit der BG-19 erfolgt.

Zum Sommerrelease von XRechnung mit Wirkung zum 1.2.2022 wird die Regel BR-DE-13 durch drei neue Regeln abgelöst werden, die die gewünschte Befüllung der entsprechenden Elemente in je einer separaten Regel genauer beschreiben. Eine inhaltliche Änderung ergibt sich daraus jedoch nicht.

Es fehlt ein Grund für die Ausnahme von der Umsatzsteuerpflicht in der Codeliste VATEX. Wie kann eine Ausnahme dennoch angegeben werden?
Die Codeliste VATEX ist noch recht neu und noch nicht vollständig. Dies ist aber unproblematisch, da entweder BT-120 (eine textueller Grund für die Ausnahme) oder BT-121 (der VATEX Code für die Ausnahme) zu nutzen ist.
Wenn eine Ausnahmeregel in der Codeliste VATEX nicht zu finden ist, kann in BT-120 eine textuelle Beschreibung angegeben werden, vgl. BR-E-10, BR-AE-10, BR-IC-10, BR-G-10, BR-O-10, BR-IG-10, BR-IP-10).

Wie können negative Rechnungszeilen übermittelt werden?
Negative Rechnungszeilen können auch in XRechnung übermittelt werden. Wichtig zu verstehen ist aber, dass ein Preis nicht negativ sein darf, die angerechnete Menge aber schon. Dadurch ergeben sich dann negative Beträge auf Ebene einer Rechnungszeile. Dazu gibt es ein Beispiel mit negativen Rechnungsbetrag in der Testsuite (Bsp. 03.01).

Welche SchemeID kann für eine Lieferantennummer (BT-29, seller identifier, vom Erwerber vergebene Kennung des Verkäufers) genutzt werden?
Eine vom Erwerber vergebene Kennung des Verkäufers soll ohne SchemeID übermittelt werden, wenn keines der in der Codeliste ISO/IEC 6523 aufgeführten Bildungsschemata verwendet wird. Ein passendes Beispiel dazu findet sich in der Testsuite (Bsp. 03.01).

nach oben

Steuer- und handelsrechtliche Fragen zur XRechnung

Wie werden Pflichtangaben nach Handels- und/oder Umsatzsteuerrecht übertragen?
Viele Pflichtangaben auf Rechnungen, wie Geschäftsführer oder Gerichtsstand, sind gesetzlich vorgeschrieben, werden für die automatisierte Rechnungsverarbeitung nicht benötigt. Daher ist hierfür auch keine strukturierte Übertragung vorgesehen. Diese Angaben können jedoch im Freitextfeld BT-33 Seller Additional Legal Information übertragen werden.

Welche Kennung muss bei ausländischen Rechnungen mit regulären ausländischen Umsatzsteuersätzen verwendet werden?
Für die Kennzeichnung der Umsatzsteuersätze wird die Codeliste UNTDID 5305 verwendet. Dabei ist für die Codierung des Umsatzsteuersatzes unerheblich, ob es sich um inländische oder ausländische Rechnungen handelt. Die konkrete Höhe der Umsatzsteuer wird in einem anderen Element übermittelt.

Wie können andere Verkehrssteuern, bspw. Versicherungsteuern, in einer XRechnung abgebildet werden?
Andere Steuerarten können auf mehreren Wegen abgebildet werden:

  • Als separate Invoice Line
  • Auf Zeilenebene in BG-28 INOICE LINE CHARGES
  • Auf Rechnungsebene in BG-21 DOCUMENT LEVEL CHARGES

Dabei können u.a. folgende Umsatzsteuerkonstellationen auftreten:

  • Wenn die Steuer umsatzsteuerbefreit ist, ist für die jeweilige Steuer aus der Codeliste UNTDID 5305 unter zusätzlicher Beachtung der entsprechenden Geschäftsregeln (BR-E-1 bis BR-E-10) das Umsatzsteuermerkmal E zu wählen
  • Wenn die Steuer umsatzsteuerpflichtig ist, ist für die jeweilige Steuer aus der Codeliste UNTDID 5305 das Umsatzsteuermerkmal S zu wählen
  • Wenn die vollständige Rechnung nicht Gegenstand des Umsatzsteuerrechts ist, dann ist für die Steuer unter zusätzlicher Beachtung der entsprechenden Geschäftsregeln (BR-O-1 bis BR-O-14) das Umsatzsteuermerkmal O zu wählen

Wie kann die Steuer auf Altteile in XRechnung abgebildet werden?
Aktuell kann die Steuer auf Altteile wie folgt abgebildet werden:

  • Eine Rechnungsposition mit Austauschteil und Besteuerung Steuercode S für das Austauschteil.
  • Eine Rechnungsposition mit Bemessungsgrundlage (10% Wertes des Austauschteils) und Besteuerung Steuercode S für die (Umsatz)Steuer auf Altteile.
  • Eine Rechnungsposition mit negativer Bemessungsgrundlage und Besteuerung Steuercode Z für die Korrektur der Bemessungsgrundlage.
  • Einfügen einer Invoice Note mit dem Hinweis auf die Steuer auf Altteile: „Rechnung enthält XX EUR (Umsatz)Steuer auf Altteile gem. Abschn. 10.5 Abs. 3 UStAE“

Zum Sommerrelease 2021 wird auch ein Testfall in der Testsuite zur Verfügung stehen.

Wie lassen sich bereits gezahlte Umsatzsteuerbeträge in einer XRechnung abbilden?
Hierbei handelt es sich lediglich um einen Hinweis, um den Rechnungssteller rechtlich abzusichern und nicht um eine Information, die automatisiert verarbeitet werden muss. Daher ist es ausreichend, einen entsprechenden Hinweis in der BG-1 INVOICE NOTE zu platzieren.

Wie wird mit Pflichtangaben nach § 22c UStG (Fiskalvertretung) in einer XRechnung umgegangen?
§ 22c UStG verlangt im Falle der Fiskalvertretung den Hinweis auf die Fiskalvertretung, Namen und Anschrift des Fiskalvertreters sowie dessen USt-ID. Für Name, Anschrift und USt-ID sind entsprechende Elemente in XRechnung vorgesehen (Name in BG-11 und Adresse in BG-12 (Ist ein Pflichtelement in BG-11), geregelt in BR-18 und BR-56; Umsatzsteuer-Identifikationsnummer: in BG-11 enthalten, geregelt in BR-19). Ein Element für den „Hinweis auf die Fiskalvertretung“ existiert nicht, weil die Befüllung der BG-11 und BG-12 selbst den Hinweis darstellt (die BG bleiben leer, wenn keine Fiskalvertretung vorliegt).

Können Abschlagspläne in einer XRechnung abgebildet werden?
Eine strukturierte Übermittlung von Abschlagsplänen ist zum aktuellen Zeitpunkt nicht vorgesehen. Informationen für zukünftige Zahlungen können in BG-1 übertragen werden, hier gibt es im BT-21 Invoice note subject code die Möglichkeit aus der Codeliste 4451 den Code AGN für Future Plans zu nutzen. Alternativ ist ebenfalls denkbar, einen Abschlagsplan als Anhang in BG-24 zu übermitteln.

Unterstützt XRechnung die von der Bundesregierung beschlossene und zeitlich begrenzte Umsatzsteuerreduzierung?
XRechnung unterstützt auch die zeitlich begrenzte Umsatzsteuerreduzierung, da keine festen Steuersätze in XRechnung definiert werden. Bei Verwendung der Steuerkategorie S (Standard rate/Standard rate and reduced rate items) sind in den entsprechenden BTs zum Umsatzsteuersatz die verwendeten Steuersätze durch den Rechnungssteller einzutragen.

Können auch mehrere Umsatzsteuersätze in einer XRechnung ausgewiesen werden?
Ja, dies ist möglich, bspw. bei gleichzeitiger Berechnung von Waren und Dienstleistungen mit normalen und reduzierten Umsatzsteuersatz. Gem. BR-S-8 ist für jeden verwendeten Umsatzsteuersatz ein separater Ausweis erforderlich.

Wie ist mit eienr Veränderung des Umsatzsteuersatzes innerhalb eines Abrechnungszeitraumes umzugehen, bspw. bei einer Schlussrechnung?
Die alleinstehende Differenzbetrachtung bei Umsatzsteueränderungen ist in der europäischen Norm EN 16931 (und damit auch in der XRechnung) gegenwärtig nicht möglich. Vielmehr resultiert die Umsatzsteuerberechnung in einer elektronischen Rechnung immer aus der zusammenfassenden Darstellung der Rechnungspositionen. Eine Erweiterung ist zwar in Diskussion, muss aber den Vorgaben des Normenwerks EN 16931 genügen. Ob und wann eine solche Anpassung erfolgen wird, ist daher gegenwärtig nicht absehbar.

Bis auf Weiteres müssen Umsatzsteuerkorrekturaufstellungen als rechnungsbegründende Unterlage (bspw. eingebettetes PDF-Dokument) mitgereicht werden.

Wie können Informationen zum Auftraggeber übermittelt werden?
In einigen Konstellationen ist der Rechnungsempfänger nicht der eigentliche Auftraggeber. Aktuell sieht aber das semantische Datenmodell der EN 16931-1 und somit auch XRechnung keine strukturiere Übermittlung von Informationen zum Auftraggeber vor. Die Informationen zum Auftraggeber können aber unstrukturiert in BG-1 Invoice Note übermittelt werden, bspw. unter Verwendung des Codes „AGE“ (für Contract information).

Auf europäischer Ebene gibt es aktuell Bestrebungen, Informationen zum Auftraggeber auch strukturiert zu übermitteln. Dazu finden aktuell Beratungen statt, von einer kurzfristigen Implementierung ist aber nicht auszugehen.

nach oben

Fragen zur Leitweg-ID

Wie bekomme ich als öffentlicher Rechnungsempfänger eine Leitweg-ID?
Die Vergabe der Leitweg-IDs wird auf Ebene von Bund und Ländern geregelt. Für Bundesbehörden und auf Ebene des Bundes angebundene öffentliche Auftraggeber ist das KKR zuständig, die ausgebenden Stellen auf Länderebene können der laufend aktualisierten Ländersynopse entnommen werden.

Benötige ich als Rechnungssteller eine eigene Leitweg-ID?
Nein, die Leitweg-ID wurde zur Adressierung von öffentlichen Rechnungsempfängern geschaffen. Rechnungssteller benötigen daher keine eigene Leitweg-ID.

Wie erfahre ich die Leitweg-ID des Rechnungsempfängers?
Die Leitweg-ID wird vorab (bspw. im Rahmen der Vergaben oder der Bestellung) an den die Rechnungssteller übermittelt.

Gibt es eine bundesweite Datenbank mit allen verfügbaren Leitweg-IDs?
Die Leitweg-IDs werden dezentral von Bund und Ländern vergeben. Daher existiert aktuell auch keine bundesweite Datenbank, in der alle Leitweg-IDs eingetragen sind.

nach oben

Technische Umsetzung

Welche Hilfestellung gibt es bei der technischen Umsetzung von XRechnung?
Die KoSIT stellt im Auftrag des IT-Planungsrats verschiedene Hilfsmittel zur Verfügung. Diese Hilfsmittel sind keine fertigen Softwareprogramme sondern stellen nur Bausteine dar, die in eigene Software integriert werden kann. Die Veröffentlichungen dieser Hilfsmittel finden grundsätzlich jeweils zur aktuell geltenden Spezifikation statt.

Müssen Unternehmen mit einem Umstellungsaufwand rechnen, die bereits ein anderes elektronisches Rechnungsformat im Einsatz und Rechnungen gemäß XRechnung an die Verwaltungen übermitteln wollen?
Die europäische Norm ist maßgeblich für die elektronische Rechnungsstellung in Europa. Insofern ist ein Umstellungsaufwand für alle Softwarehersteller und Unternehmen vorhanden, die normkonform agieren wollen. Dies trifft insbesondere Wirtschaftsteilnehmer, die europaweit agieren. Auch Unternehmen, die bereits andere Rechnungsformate einsetzen, sind von dem Umstellungsaufwand betroffen, um normkonform zu werden.

Wie lässt sich prüfen, ob eine Rechnung valide zur Spezifikation XRechnung ist?
Hierfür hat der IT-Planungsrat ein Prüfmodul bei der KoSIT beauftragt, das öffentlich zur Verfügung gestellt ist. So können Unternehmen, Softwareanbieter oder Dritte, die elektronische Rechnungen im Auftrag für Rechnungssteller an öffentliche Auftraggeber übermitteln, das Prüfmodul samt Prüfregeln sowie die Referenzimplementierung nutzen. Diese verdeutlicht den Mechanismus und kann Entwicklern als Vorbild für ihre eigenen Umsetzungen dienen. Sie ist als open source-Lösung veröffentlicht und kann so IT-Dienstleister von Entwicklungsaufgaben entlasten.

Während der Planung des EU-Standards wurden fünf mögliche Syntaxen in Betracht gezogen. In dem vorliegenden Standard XRechnung sind nur zwei davon berücksichtigt (UBL, UN/CEFACT). Werden die anderen drei Syntaxen perspektivisch dem Standard hinzugefügt?
Nein. XRechnung ist eine Core Invoice Usage Specification (CIUS) der Europäischen Norm EN 16931. Daher stellt die KoSIT die entsprechenden Artefakte stets in Abhängigkeit von der Europäischen Norm bereit. Sollte sich auf der europäischen Ebene bezüglich der bereitzustellenden Syntaxen eine Änderung ergeben, wird XRechnung als CIUS diese auch abbilden. Sollte dies nicht der Fall sein, wird es bei der Berücksichtigung der o.g. Syntaxen bleiben.

Müssen Rechnungssteller in der Lage sein, elektronische Rechnungen in beide Syntaxen zu erzeugen?
Nein, Rechnungssteller können sich eine der erlaubten Syntax aussuchen. Rechnungsempfänger der öffentlichen Verwaltung müssen hingegen in der Lage sein, elektronische Rechnungen in beiden Syntaxen zu empfangen.

Müssen sowohl die Ausgestaltung des Standards XRechnung als Core Invoice Usage Specification (CIUS) als auch die technischen Artefakte der elektronischen Rechnung von Softwareanbietern gekauft werden?
Nein, der Standard XRechnung wird mitsamt seinen Bestandteilen (technische Artefakte) von der KoSIT kostenfrei bereitgestellt.

Wie kann ein XRechnungs-Datensatz visualisiert werden?
Komponenten zur Unterstützung der Visualisierung sind öffentlich im XRechnungs-GitHub verfügbar. Eine elektronsiche Rechnung im Standard XRechnung wird jeweils im Verantwortungsbereich des Rechnungsstellers oder -empfängers visualisiert. So werden mögliche Inkonsistenzen zwischen zwei Dokumenten (PDF und strukturierter Datensatz) sowie Zusatzaufwände bei der Identifikation und Extraktion des Rechnungsdokuments aus einem PDF, in das verschiedenste Dokumente eingebettet werden können, vermieden.

Was sind die Gründe für die zweistufige Transformation im Rahmen der Visualisierung?
Hierfür gibt es hauptsächlich organisatorische Gründe. Die Visualisierungskomponente wird gemeinsam von KoSIT und KKR entwickelt und die zweistufige Transformation bildet die jeweiligen Verantwortlichkeiten ab.

Welche Dokumente und Bestandteile werden für die technische Umsetzung des Standards XRechnung benötigt? Gibt es hierbei Unterstützung?
Wir haben eine Übersicht erstellt, die alle Bestandteile darstellt, die zur Umsetzung von XRechnung benötigt werden bzw. die die Umsetzung unterstützen können.

Wo finde ich das XRechnung Schema (XSD)?
Es gibt keine XSD speziell für XRechnung. Die EU-Norm und die darauf basierende XRechnung formulieren Regeln (technisch als Schematron umgesetzt) in Bezug auf verschiedene, bereits existierende Syntaxen. Dies sind UBL und UNCEFACT/CII. Diese Syntaxen haben XSDs. Die von der KoSIT herausgegebene Validator Konfiguration XRechnung (https://github.com/itplr-kosit/validator-configuration-xrechnung) hilft nicht nur bei der Validierung von XRechnungen, sondern beinhaltet auch alle wichtigen Artefakte und somit XSDs, die in der Kombination die XRechnung umsetzen. Diese finden sich z.B. in den jeweils aktuellen Releases https://github.com/itplr-kosit/validator-configuration-xrechnung/releases im Unterordner „resources“ unter ubl und cii.

Gibt es von der KoSIT ein Konvertierungswerkzeug aus gängigen Office-Formaten oder anderen Rechnungsformaten in XRechnung?
Nein.

Warum kann in der UN/CEFACT-Syntax maximal nur ein BG-3 (Preceding Invoice Reference) angegeben werden, in der XRechnung-Syntax aber mehrfach?
Das Problem ist bekannt und liegt zunächst nicht im Standard XRechnung begründet. Vielmehr ist es so, dass das der XRechnung zugrunde liegende Normenwerk EN16931 in den entsprechenden Syntaxmapping (CEN/TS 16931-3-3 - Electronic invoicing - Part 3-3: Syntax binding for UN/CEFACT XML Industry Invoice D16B) für die BG-3 PRECEDING INVOICE REFERENCE die Kardinalität normativ auf 0..1 festlegt. Aktuell wird der Fehler auf CEN-Ebene thematisiert, allerdings ist nicht von einer kurzfristigen Lösung auszugehen. Das Referenzieren von mehreren vorangegangenen Rechnungen ist in UBL-Syntax möglich.

Welche Kodierung wird für eingebettete Dateianhänge verwendet?
Für die Kodierung von eingebetteten Dateianhängen (ADDITIONAL SUPPORTING DOCUMENTS) wird immer base64 verwendet.

Warum gibt es eine Fehlermeldung oder Warnung bei der Verwendung von Werten aus einer aktualisierten Codelistenversion?
Codelisten werden von verschiedenen Organisationen veröffentlicht und unterliegen einem anderen Releasezyklus als XRechnung. Es ist also möglich, dass eine Codeliste aktualisiert wird und eine neue Version der XRechnung gerade veröffentlicht wurde. In diesem Falle dauert es ein wenig bis auch die aktuellsten Codelisten in die XRechnungsartefakte integriert sind. Zudem werden die verwendeten Werte in einer elektronischen Rechnung nicht von den XRechnungsartefakten validiert werden, sondern vom CEN-Bestandteil der Validierungskomponente. Die CEN-Artefakte unterliegen ebenfalls einem anderen Releasezykus, sodass es auch hier zu weiteren Verzögerungen kommen kann.

Welche XSLT-Version wird von den KoSIT-Artefakten unterstützt?
Die KoSIT-Artefakte nutzen XSLT 2.0. XSLT 2.0 ist die am weitesten verbreitete Version. Die von CEN zur Verfügung gestellten Artefakte werden ebenfalls in XSLT 2.0 veröffentlicht. Daher unterstützen die KoSIT-Artefakte ebenfalls nur XSLT 2.0. Für C# gibt es ebenfalls Bibliotheken, welche XSLT 2.0 unterstützen.

Zur Beschreibung der Umsatzsteuermerkmale wird auf die Codeliste 5305 verwiesen. Warum werden in der Beschreibung der Informationselemente andere Codenamen verwendet als in der Beschreibung der Geschäftsregeln? Und welche Codenamen sind die korrekten Codenamen?
Entscheidend bei der Verwendung der Codeliste UNTDID 5305 ist der eigentliche Code und nicht der Namen des Codes. Die verwendeten Codes und Codenmanen in der Beschreibung der Informationselemten sind hier korrekt. Die Abweichung kommt zustande, weil in der zugrundeliegenden EN 16931 ebenfalls abweichende Beschreibungen verwendet werden. Die folgende tabellarische Darstellung gibt eine entsprechende Übersicht.












CodeCodenameAlternativer Name
SStandard rateStandard rate and reduced rate items
ZZero rated goodsZero rated sale
EExempt from taxExempted from VAT
AEVAT Reverse ChargeReverse Charge
KVAT exempt for EEA intra-community supply of goods and servicesIntra-Community Supply
GFree export item, tax not chargedExports
OServices outside scope of taxNot subject to VAT
LCanary Islands general indirect taxCanary Islands tax
MTax for production, services and importation in Ceuta and MelillaCeuta and Melilla tax

nach oben

Betrieb und Weiterentwicklung

Gibt es Informationen zum Release-Management?
Der Betrieb von XRechnung erfolgt auf Basis des Betriebskonzepts, das der IT-Planungsrat in seiner 26. Sitzung beschlossen hat und welches die Releasezeitpunkte definiert. Im Juni 2021 wurde das Betriebskonzept überarbeitet und die möglichen Releasezeitpunkte auf 31.07. und 31.01. eines jeden Jahres verschoben.

Wie wird der Standard XRechnung betrieben und weiterentwickelt?
Die Weiterentwicklung des Standards XRechnung wird durch den dauerhaften Betrieb bei der KoSIT sichergestellt. Das vom IT-Planungsrat beschlossene Betriebskonzept für den Standard XRechnung stellt den dauerhaften und verlässlichen Betrieb inklusive des transparenten Änderungsmanagements für alle Stakeholder aus Wirtschaft und Verwaltung sicher. Dadurch wird auch gewährleistet, dass XRechnung die jeweils gültige Fassung der europäischen Norm abbildet. Die Weiterentwicklung erfolgt stets in Abhängigkeit zur europäischen Norm für die elektronische Rechnungsstellung EN 16931.

Wie sind Wirtschaftsteilnehmer eingebunden?
Die Zusammenarbeit mit der Wirtschaft war von Beginn an ein deutlicher Auftrag des IT-Planungsrates, dem das Steuerungsprojekt auf vielfältige Weise nachgekommen ist und noch nachkommt: Zu nennen sind hier insbesondere die Zusammenarbeit mit der Handels- und Handwerkskammer, dem Erprobungsraum Nordwest des nationalen IT-Gipfels sowie dem Verband elektronische Rechnung (VeR) für ein Planspiel zur Einführung des Standards XRechnung.

nach oben

Tests, Erprobung und Qualitätssicherung

Werden Testnachrichten bereitgestellt?
Ja, die Veröffentlichungen finden jeweils zur aktuell geltenden Spezifikation statt und sind unter XRechnung-Versionen zu finden. Eine Übersicht der verfügbaren Testrechnungen ist unter Übersicht Testrechnungen abrufbar.

Fand eine Erprobung des Standards XRechnung statt?
Ja. Die Erprobung von XRechnung hat in Zusammenarbeit mit dem Erprobungsraum des IT-Planungsrats, der Virtuellen Region Nordwest, sowie dem Verband elektronischer Rechnungen (VeR) begonnen. Die Ergebnisse sind in den Standard XRechnung und die weiteren Komponenten eingeflossen.

Findet eine Qualitätssicherung des Standards XRechnung statt?
Ja. Der Standard XRechnung wird aus fachlicher Sicht vom Expertengremium XRechnung und KoSIT dauerhaft qualitätsgesichert. Die KoSIT pflegt den Standard XRechnung und alle zugehörigen Artefakte zudem dauerhaft aus technischer Sicht und adaptiert dabei auch Änderungen, die sich aus CEN-Ebene ergeben.

nach oben

Hintergründe zur Entwicklung

Wer hat den Standard XRechnung erarbeitet?
Der Standard XRechnung ist im Auftrag des IT-Planungsrats im Steuerungsprojekt eRechnung als nationale Ausgestaltung des semantischen Datenmodells der Europäischen Norm gemeinsam mit Vertretern von Bund, Ländern und Kommunen erarbeitet worden. Mehr als 50 Fachexperten aus Bund, Ländern und Kommunen haben die geforderten Ausgestaltungen auf rechtlicher, semantischer und technischer Ebene vorgenommen.

Welche Behörden setzen den Standard XRechnung ein?
Alle öffentlichen Auftraggeber, die von der Umsetzungsverpflichtung der EU-Richtlinie betroffen sind, werden von Auftragnehmern bundesweit über den Standard XRechnung angesprochen werden können.

Warum wurde Anfang 2016 mit der Entwicklung von XRechnung begonnen, wenn es in der Wirtschaft andere Formate bereits vorher gab?
Ausgangspunkt für das Steuerungsprojekt war und ist die europäische Norm und die damit einhergehende Umsetzungsverpflichtung. Bereits zu Projektbeginn war bekannt, dass am Markt eine Vielzahl weiterer z.T. branchenspezifischer Formate existiert. Die Problematik der Vielzahl dieser Formate wurde von der Europäischen Kommission erkannt, sodass die EU-Richtlinie folgende Erwägungsgründe benennt: „Es bestehen mehrere weltweite, nationale, regionale und unternehmensspezifische Normen für elektronische Rechnungen, und sie werden derzeit in den Mitgliedstaaten verwendet. Es gibt keine vorherrschende Norm, und die meisten Normen sind nicht interoperabel. […] Die Vielzahl nicht interoperabler Normen führt zu übermäßiger Komplexität, Rechtsunsicherheit und zusätzlichen Betriebskosten für Wirtschaftsteilnehmer, die elektronische Rechnungen grenzübergreifend in verschiedenen Mitgliedstaaten verwenden.“ (Richtlinie 2014/55/EU des Europäischen Parlaments und des Rates vom 16. April 2014 über die elektronische Rechnungsstellung bei öffentlichen Aufträgen)
Auf Basis der EU-Richtlinie wurde ein Normungsauftrag an das CEN erteilt, das eine gemeinsame europäische Norm für die elektronische Rechnungsstellung entwickeln sollte. Die europäischen Mitgliedsstaaten haben entsprechende Vertreter für die Mitarbeit im CEN benannt. In Deutschland wurde dies federführend für die Verwaltung durch die Koordinierungsstelle für IT-Standards (KoSIT) im Auftrag des Bundesministeriums des Innern wahrgenommen.
Der Standard XRechnung stellt die deutsche CIUS (Core Invoice User Specification, eine von der Europäischen Kommission vorgesehene Methode zur Anpassung der europäischen Norm für die elektronische Rechnungsstellung an Bedingungen des jeweiligen Mitgliedstaats) dar. Ziel von XRechnung war und ist die Überführung der europäischen Norm in einen zwischen Bund, Ländern und Kommunen abgestimmten nationalen Standard.

Was ist der Vorteil einer deutschen CIUS XRechnung?
Durch die CIUS XRechnung soll die Interoperabilität auf allen Ebenen (Semantik, Syntax, Recht, Technik) gewährleistet werden. Mit XRechnung wurde kein neuer, losgelöster Standard erarbeitet, sondern unter Einbeziehung der Experten aus Bund, Ländern und Kommunen Eindeutigkeit für Rechnungssteller und –empfänger im Rahmen der europäischen Vorgaben hergestellt. Durch die Vorgabe von XRechnung kann sichergestellt werden, dass einerseits alle betroffenen öffentlichen Auftraggeber sich nicht eigenständig mit den europäischen Vorgaben auseinandersetzen müssen (und dann ggf. zahlreiche unterschiedliche Interpretationen umgesetzt werden), andererseits können Auftragnehmer trotz heterogener IT-Systeme zur elektronischen Rechnungsstellung auf Basis eines einheitlichen, verlässlichen und durch die Verwaltung betriebenen Standards mit Auftraggebern strukturierte Rechnungsdaten austauschen. Da XRechnung als einheitlicher, produkt- und herstellerneutraler Standard allen kostenfrei und vollständig dokumentiert zur Verfügung gestellt wird, können IT-Anbieter XRechnung in ihre entsprechenden Lösungen integrieren.

Wie rechtfertigt sich die Entwicklung und Pflege mehrerer Formate zur elektronischen Rechnungsstellung?
Durch den Beschluss des IT-Planungsrates wird es für die öffentlichen Auftraggeber in Deutschland nur einen Standard geben (XRechnung). Weitere Formate spielen für die deutsche Verwaltung nur eine untergeordnete Rolle. Sofern fachlich erforderlich, können auch weitere bestehende Formate akzeptiert werden, sofern die Länder dies in ihren Rechtsverordnungen zulassen. Maßgeblich wird jedoch der durch den IT-Planungsrat beschlossene Standard XRechnung sein.

nach oben

Fragen zu elektronischen Rechnungsstellung im Bauwesen

Nach welcher konkreter Definition handelt es sich bei einer ausgestellten Rechnung um eine Bauleistung?
Die Abrechnung einer Bauleistung liegt im öffentlichen Auftragswesen in der BRD genau dann vor, wenn die ursprüngliche Beauftragung nach VOB/A bzw. VOB/A-EU erfolgte.

Wie können die bauspezifischen Rechnungstypen übermittelt werden?
Die spezifischen Baurechnungstypen Abschlags-, Teilschluss- und Schlussrechnungen können im Element „Invoice type code“ (BT-3) codiert werden. Dazu gibt es in der Codeliste UNTDID 1001 die Codes 875 (Partial construction invoice), 876 (Partial final construction invoice) und 877 (Final construction invoice).

Müssen die bauspezifischen Rechnungstypen verpflichtend verwendet werden, wenn es sich um eine Bauleistung handelt?
Ja, nach den Bestimmungen der §§ 14 und 16 VOB/B müssen Rechnungen in Abschlagsrechnungen, Teilschlussrechnungen und Schlussrechnungen unterschieden werden.

Hat der verwendete InvoiceTyeCode eine Auswirkung auf die weitere Verarbeitung der Rechnung?
Ja, der InvoiceTypeCode besitzt u. a. folgende Auswirkungen:

  • Die Fälligkeit der Rechnung wird nach VOB/B in Abhängigkeit des Rechnungstyps geregelt. (s. § 16 Abs. 1 Nr. 3 VOB/B bzw. § 16 Abs. 3 Nr. 1 VOB/B)
  • Baurechnung sollen regelmäßig als kumulierte Rechnungen aufgestellt werden.
  • Im Allgemeinen legt der InvoiceTypeCode auch fest, ob es sich beim Rechnungsbeleg um einen Eigenbeleg (s. insbesondere Type-Code 389), eine Forderung (s. insbesondere Type-Code 381) oder Verbindlichkeit handelt.

Können zusätzliche XML-Dateien in die XRechnung eingebettet werden?
Die dem Standard XRechnung zu Grunde liegende EN 16931 erlaubt in einer elektronischen Rechnung keine Einbettung von zusätzlichen XML (vgl. die aktuellen Beschreibung von BT-125 in der XRechnung). Im Rahmen der Extension XRechnung können aber XML-Dateien eingebettet übermittelt werden (xrechnung#59). XML-Dateien können zudem extern referenziert werden.

Gibt es eine Größenbeschränkung im Standard XRechnungen?
Der Standard XRechnung gibt es ausdrücklich keine Größenbeschränkungen für XRechnungen und deren Anhänge vor. Jedoch können bei den Portalbetreibern durchaus Größenbeschränkungen existieren. Auskunft dazu erteilen die Portalbetreiber. Im Falle großer Dateianhänge kann auch von externen Anlagen zurückgegriffen werden (BG-24 ADDITIONAL SUPPORTING DOCUMENTS).

Wie können Sicherheitseinbehalte in der XRechnung abgebildet werden?
Sicherheitseinbehalte mindern den Forderungsbetrag einer Rechnung nicht und zielen auf eine von der Rechnungsfälligkeit unabhängige Auszahlung ab. In XRechnung können sie daher nicht als Nachlass auf Dokumenten- (BG-20) oder Positionsebene (BG-27/BG-DEX-03) ausgedrückt werden.

Bürgschaften oder Sicherheitseinbehalte werden im Rahmen der Vertragsschließung zwischen Auftraggeber und Auftragnehmer vereinbart und sind daher von der Rechnungsabwicklung unabhängig zu sehen. Eine explizite Abbildung ist im semantischen Modell der XRechnung nicht vorgesehen. Sie können jedoch nachrichtlich - bspw. unter Verwendung des Betreffcodes „PMT“ (für Payment information) aus der Codeliste 4451 – als Invoice Note (BT-21/BT-22) in den Rechnungen aufgeführt werden.

Wie ist mit eienr Veränderung des Umsatzsteuersatzes innerhalb eines Abrechnungszeitraumes umzugehen, bspw. bei einer Schlussrechnung?

Siehe Abschnitt Steuer- und handelsrechtliche Fragen zur XRechnung

nach oben

Fragen zu elektronischen Rechnungsstellung in der Energiewirtschaft

Ist es möglich die Pflichtangaben nach Energiewirtschaftsgesetz (EnWG) rechtsfonform abzubilden?
Eine strukturierte Übermittlung von Pflichtangaben nach Energiewirtschaftsgesetz (EnWG) ist zum aktuellen Zeitpunkt nicht vorgesehen. Für Pflichtangaben nach EnWG können bspw. die BG-1 INVOICE NOTE oder angehängte Dokumente in BG-24 ADDITIONAL SUPPORTING DOCUMENTS genutzt werden.

nach oben

Fragen zu Implementierung

Warum definieren EN 16931 und somit XRechnung kein eigenes XML?
Die KoSIT liefert das semantische Datenmodell auf Basis der EN 16931-1 aus. Dieses ist zunächst erst einmal kein reines XML, sondern ein Datenmodell. Die EN 16931-1 wird auf Grund des License Agreement zwischen EC und CEN kostenfrei durch die nationalen Normungsorganisationen wie DIN zur Verfügung gestellt. Die kostenfreie Bereitstellung von XRechnung ist auf Grund dieses License Agreements ebenfalls möglich.

Warum stellt KoSIT die Syntaxen nicht zur Verfügung?
Das semantische Datenmodell ist kein XML und muss daher in eine Syntax gemappt werden. Die Syntaxen sind dann erst die eigentlichen XMLs. In CEN/TS 16931-2 werden die Syntaxen identifiziert, die den Anforderungen an EN 16931-1 genügen. Dies sind UBL und CII. Damit klar ist, welches Element aus dem semantischen Modell in welches Feld in UBL bzw. CII gemappt wird, benötigen Sie die jeweiligen Syntaxmappings (CEN TS 16931-3-2 Electronic invoicing - Part 3-2: Syntax binding for ISO/IEC 19845 (UBL 2.1) invoice and credit note; CEN TS 16931-3-3 Electronic invoicing - Part 3-3: Syntax binding for UN/CEFACT XML Industry Invoice D16B). Da die Syntaxmappings nicht Bestandteil des License Agreements zwischen Europäischer Kommission und CEN sind (Details dazu hier), müssen diese käuflich erworben werden.

Warum gibt es zur Extension XRechnung kein Syntax-Binding für UN/CEFACT XML Industry Invoice D16B?
Das Syntax-Binding zur Syntax UN/CEFACT XML Industry Invoice D16B kann erst veröffentlicht werden, wenn auf Seiten des Syntaxbetreibers die notwendigen technischen Voraussetzungen geschaffen sind. Dies Arbeiten finden aktuell statt, Syntaxbetreiber und KoSIT stimmen sich zu einer technischen Lösung ab. Die Veröffentlichung geschieht dann im Rahmen des regulären Releasezyklus von XRechnung.

Es gibt aktuell kein Syntax-Binding für UN/CEFACT XML Industry Invoice D16B für die Extension XRechnung. Stellt dies eine Benachteiligung von UN/CEFACT dar?
Die hierarchischen Sub Invoice Lines sind nicht Bestandteil des Kernmodelles der EN 16931-1 und somit auch nicht des Standards XRechnung. Es wurde der Wunsch an die KoSIT herangetragen, Sub Invoice Lines in XRechnung nutzbar zu machen. Die Nutzung von zusätzlichen Elementen ist möglich, aber nur im Rahmen einer sogenannten Extension (vgl. EN 16931-5). EN 16931-5 besagt, dass diese zusätzlichen Elemente in mind. einer der unterstützten Syntaxen UBL oder CII unterstützt werden müssen. Im Zuge der technischen Vorarbeiten hat die KoSIT festgestellt, dass die Sub Invoice Lines in der benötigten Form in der Syntax UBL abbildbar sind, aber noch nicht in der Syntax CII.

Daher hat sich die KoSIT entschlossen, wenigstens das Syntaxmapping UBL zu veröffentlichen, um zumindest in einer Syntax die hierarchischen Rechnungszeilen nutzbar zu machen. Dieses Vorgehen ist wie beschrieben durch EN 16931-5 gedeckt. Die Arbeiten am Syntax-Binding für UN/CEFACT XML Industry Invoice D16B finden derzeit statt.

nach oben

Fragen zur Rundung

Wie kommt es zu Rundungsdifferenzen?
Durch die Norm EN 16931 erfolgt keine Vorgabe der Runderegel, d.h. der Umgang mit der Rundung positiver und reeller Zahlen, das Ab- und Aufrunden, Runden zu Null hin und von der Null weg können im Rahmen der geltenden Rechtsnormen frei gestaltet werden. Dabei kann es zu kleineren Abweichungen der Ergebnisse je nach angewandter Runderegel kommen.

Das BMF verweist als Grundlage der Rundungsregelung auf den Umsatzsteuer-Anwendungserlass (UStAE). In Abschnitt 14.5. Abs. 20 S. 1 bis 3 heißt es dort "Nach § 14 Abs. 4 Satz 1 Nr. 8 UStG ist in der Rechnung der Steuersatz sowie der auf das Entgelt entfallende Steuerbetrag oder im Fall der Steuerbefreiung ein Hinweis auf die Steuerbefreiung anzubringen. Der Steuerbetrag muss vom Unternehmer für die von ihm ausgeführte steuerpflichtige Leistung nach Cent genau berechnet werden.Ergibt sich bei der Steuerberechnung kein voller Centbetrag, ist der Centbetrag abzurunden, wenn die nachfolgende Ziffer höchstens 4 ist, bzw. aufzurunden, wenn die unmittelbar folgende Ziffer größer als 4 ist." Dies betrifft die Rundung bei der Steuerberechnung.

Von den angewendeten Runderegeln unabhängig kann als technische Ursache die Art der Verarbeitung von Gleitkommazahlen im System eine Rolle spielen. Hierbei werden für den Nutzer mit zwei Nachkommastellen ausgestattete Zahlen tatsächlich mit erheblich mehr Nachkommastellen und einer rechnerisch minimalen Abweichung verarbeitet. In der Summe kommt es so zu Differenzen, die je nach Menge der beteiligten Elemente mehrere Cent betragen können.

Tests haben gezeigt, dass die Problematik der Gleitkommaverarbeitung unter Umständen durch den Einsatz der aktuellen XSL Version 2.0 behoben werden kann. Abweichungen durch Positions- oder Rechnungsorientiertes Runden sind davon (natürlich) unberührt.

Wie kommt es zu Problemen bei der Validierung?
Die Prüfung der rechnerischen Richtigkeit erfolgt anhand von CEN-Regeln. Die Wahl des Rechenweges ist in der aktuellen Form der EN 16931-1 eingeschränkt, sie geht von Netto + USt = Brutto auf Dokumentenebene aus. Der umgekehrte Weg (Brutto – USt = Netto) oder eine Berechnung auf Zeilenebene wird im Modell nicht unterstützt. Er kann daher nur genutzt werden, wenn außerhalb des semantischen Datenmodells der EN 16931-1 gerechnet wird.

Da bei der Validierung die vom Rechnungssteller genutzten Runderegeln noch seine Wahl des Rechenwegs bekannt sind, können diese auch nicht individuell berücksichtigt werden.

Die Validierung basiert auf dem durch die Rechenregeln der EN 16931-1 vorgegebenen Rechenweg (siehe BR-CO-10 bis BR-CO-17) sowie den Regeln zur Berechnung der Umsatzsteuerbeträge.

Aufgrund der Anwendung unterschiedlicher Runderegeln und/oder Rechenwege bei Rechnungserstellung und Validierung kann es zu Abweichungen zwischen dem Rechenergebnis des Rechnungsstellers und dem des Rechnungsempfängers kommen.

In den beiden Syntaxen UBL und CII können die CEN-Regeln für Berechnungen unterschiedlich umgesetzt sein, so dass die Ergebnisse der Validierung je nach Syntax abweichen können.

Was kann getan werden, um Validierungsprobleme durch Rundungsabweichungen zu verringern?
Nutzen Rechnungsersteller vor dem Versand der Rechnung die Möglichkeit zur Validierung, können dabei auftretende Fehler oder Warnungen vor Versand erkannt und behoben werden. Wenn möglich, können die Systeme an die bei der Validierung genutzten Regeln und den Rechenweg angepasst werden.

Entwicklerseitig ist in Betracht zu ziehen, BT-114 rounding amount zu nutzen, um Rundungsdifferenzen unabhängig von ihrem Entstehungsgrund auszugleichen und so rechnerisch valide Rechnungen zu erzeugen. Der Inhalt des BT-114 darf dabei nicht den Wert „Null“ haben, dies führt aktuell noch zu Validierungsfehlern in den CEN-Regeln. Sofern kein Rundungsbetrag vorliegt, sollte das Element leer gelassen werden.

Die KoSIT strebt derzeit eine europäische einheitliche Lösung für den Umgang mit dem Problem an. In der CEN wird derzeit die Einführung von Toleranzen für Rundungsdifferenzen diskutiert.

Probleme, die auf der Verarbeitung von Gleitkommazahlen beruhen, können u .U. durch den Einsatz der aktuellen XSL Version 2.0 behoben werden.

nach oben