In unserem FAQ-Bereich finden Sie Antworten auf häufig gestellte Fragen rund um das Thema XRechnung.

Auf unserer Informationsseite zur B2B‑Verpflichtung finden Sie Informationen zur technischen und fachlichen Umsetzung mit dem Standard XRechnung.

Informationen zum Betrieb und Support von XRechnung finden Sie hier.

Wie Sie Änderungsanträge zur XRechnung einreichen können, finden Sie hier. Im GitLab finden Sie alle aktuelle Änderungsanträge zur XRechnung.

Der Standard XRechnung wird von der Koordinierungsstelle für IT-Standards (KoSIT) im Auftrag des IT-Planungsrats betrieben. Bei Fragen zur XRechnung wenden Sie sich bitte an:

Koordinierungsstelle für IT-Standards (KoSIT)

Freie Hansestadt Bremen
Senator für Finanzen

Rudolf-Hilferding-Platz 1
28195 Bremen

xrechnung@finanzen.bremen.de

Die mit den Versionen 1.3.11 und 1.3.12 der EN 16931 Validation artefacts neu hinzugefügten Regeln CII-SR-452, CII-SR-453 und CII-SR-454 wurden in den Versionen 2023-11-15 und 2024-06-20 der Validator Konfiguration XRechnung vom Fehlerlevel „Warning“ auf „Error“ verschärft. Daher kann es jetzt zu Ablehnungen von XRechnungen kommen, die mit früheren Prüfkonfigurationen angenommen wurden.

Im Zuge der Harmonisierung der CIUSe XRechnung und Peppol BIS Billing 3.0 wurden die betreffenden fachlichen Regeln aus dem Regelwerk von Peppol BIS Billing 3.0 als Geschäftsregeln in die CIUS XRechnung 3.0 übernommen. Die Peppol-Regeln wurden originär auf die Syntax UBL angepasst. Eine offizielle Veröffentlichung für CII seitens Peppol
existiert bislang nicht. Daher wurden die Regeln mit der Veröffentlichung von XRechnung 3.0.0 für CII angepasst. Für eine Übergangszeit wird das Severity-Level „error“/“fatal“ in der Syntax CII zunächst auf „warning“ abgeschwächt. Im Bugfix Release im Herbst 2024 werden die Severity-Level in CII wieder auf „error“/“fatal“ verschärft werden.

Die Version XRechnung 3.0 ist seit dem 1. Februar 2024 in Kraft. Gegenüber den vorherigen Versionen von XRechnung 3.0 enthält die Version XRechnung 3.0.2 keine normativen, sondern lediglich editorielle Änderungen und wurde daher mit dem aktuellen Bugfix Release veröffentlicht.
Die Änderungen am Spezifikationsdokument sind in Anhang C (Versionshistorie) aufgeführt. Änderungen an den technischen Komponenten sind in der Readme.md des Bundle und in den Changelog.md Dateien der technischen Komponenten dokumentiert.

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.

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).

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 sowie in den Informationen zu den rechtlichen Grundlagen.

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.

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.

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.

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

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.

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.

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.

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.

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.

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:

1. „CREDIT TRANSFER“ (BG-17),
2. „PAYMENT CARD INFORMATION“ (BG-18) oder
3. „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.

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).

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 Beispiele mit negativen Rechnungsbeträgen in der Testsuite (Bsp. 01.20, 02.06, 03.06).

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).

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.

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

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.

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.

§ 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).

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.

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.

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.

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.

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.

Nein, die Leitweg-ID wurde zur Adressierung von öffentlichen Rechnungsempfängern geschaffen. Rechnungssteller benötigen daher keine eigene Leitweg-ID.

Die Leitweg-ID wird vorab (bspw. im Rahmen der Vergaben oder der Bestellung) an den die Rechnungssteller übermittelt.

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.

Bei der Verwendung von XRechnung im B2B ist keine Leitweg-ID zur Adressierung von XRechnungen notwendig. Im Element „Buyer reference (BT-10)“ kann jeder andere geeignete Bezeichner für interne Lenkungszwecke genutzt werden. Das Element „Buyer reference (BT-10)“ ist lediglich ein Textfeld und verwendet keine Schema-Definitionen.

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.

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.

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.

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.

Nein, der Standard XRechnung wird mitsamt seinen Bestandteilen (technische Artefakte) von der KoSIT kostenfrei bereitgestellt.

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.

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.

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.

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 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 im Unterordner „resources“ unter ubl und cii.

Nein.

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.

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

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.

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.

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.

Um bei der Verwendung der Codeliste UN/ECE Recommendation N°21 Verwechselungen mit der Codeliste UN/ECE Recommendation N°20 zu vermeiden, soll im Kontext der elektronischen Rechnungsstellung gem. EN 16931-1 (und damit auch mit XRechnung) das Präfix „X“ verwendet werden (also bspw. statt CT für Carton XCT). Dieser Umsetzungshinweis befindet sich im Annex A der jeweiligen Syntaxbinding-Dokumente.

Rechnungen für Vergütungen von Rechtsanwältinnen und Rechtsanwälten sowie Steuerberatern, Steuerbevollmächtigten und Steuerberatungsgesellschaften fallen grundsätzlich unter den Geltungsbereich der E-RechV und unterliegen somit der Verpflichtung zur elektronischen Rechnungsstellung.

Gemäß §9 Abs. 1 StBVV und §10 Abs. 1 RVG ist die mitgeteilte Berechnung über die Vergütung grundsätzlich durch Rechtsanwältinnen und Rechtsanwälte sowie Steuerberater zu unterzeichnen. Um dieser Unterschriftserfordernis nachzukommen, wird empfohlen, die Berechnungsgrundlage als rechnungsbegründende Unterlage in die XRechnung in Form einer im PDF integrierten Signatur einzubetten, wobei dieses der Form des § 126a Abs. 1 BGB zu entsprechen hat, d. h. eine qualifizierte elektronische Signatur aufweisen muss.

Im Fall von Self-Billing ist es nicht möglich, Pflichtangaben wie gewohnt über das Feld BT-33 (Seller additional legal information) zu übermitteln. Stattdessen sollten diese Informationen über eine Invoice Note mit dem Qualifier „AIQ Party Information“ bereitgestellt werden.
Der Qualifier „AIQ“ ist dafür vorgesehen, parteibezogene Zusatzinformationen bereitzustellen und ermöglicht es, die erforderlichen rechtlichen Angaben des Rechnungsausstellers auch im Self-Billing-Szenario korrekt und konform zu den Self-Billing-Regeln zu übertragen.

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.

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.

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.

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.

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

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.

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.

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.

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).

Ja, nach den Bestimmungen der §§14 und 16 VOB/B müssen Rechnungen in Abschlagsrechnungen, Teilschlussrechnungen und Schlussrechnungen unterschieden werden.

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.

Die dem Standard XRechnung zugrunde liegende EN 16931 erlaubt in einer elektronischen Rechnung keine Einbettung von zusätzlichen XML (vgl. die aktuelle 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.

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).

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.

Siehe Abschnitt Steuer- und handelsrechtliche Fragen zur XRechnung.

Zuschläge und Nachlässe im Rahmen der Stoffpreisklausel sollten auf Zeilenebene als INVOICE LINE CHARGES (BG-28) oder als INVOICE LINE ALLOWANCES (BG-27) übermittelt werden. Die zugrundeliegende Berechnung kann im entsprechenden Begründungsfeld („Invoice line charge reason“ (BT-144) bzw. „Invoice line allowance reason“ (BT-139)) übermittelt werden.

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.

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.

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.

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.