Menü
Menü
Das Bundesfinanzministerium hat Mitte Oktober Beispiele für die in Deutschland zulässigen elektronischen Formate veröffentlicht. Was ist der Unterschied zwischen XRechnung und PEPPOL-BIS? Was ist der Unterschied zu ZUGFeRD? Was sind die nationalen Geschäftsregeln? Wir tauchen nochmals tiefer ab.
Die bisherige Blog-Reihe zum Thema E-Rechnung findet ihr hier:
TEIL 1: Was bedeutet die E-Rechnung
TEIL 2: Übergangsregeln und Zeitplan der E-Rechnung
TEIL 3: Formatunterschiede der E-Rechnung
TEIL 4: Voraussetzungen für die Übertragung der E-Rechnung
TEIL 5: Die E-Rechnung in der Praxis
TEIL 6: Verarbeitung der E-Rechnung in Microsoft Dynamics 365 Business Central / Navision
TEIL 7: Häufige Fragen zur E-Rechnung
Im aktuellen Schreiben mit Geschäftszeichen “III C 2 – S 7287-a/23/10001 :007” und Nummer “2024/0883282” werden Beispiele für die in Deutschland zulässigen Formate benannt.
Das BMF definiert, dass die Verwendung von strukturierten Rechnungsformaten, die der Normenreihe EN 16931 (siehe Rn. 28 bis 32) entsprechen, immer zulässig ist. Ebenso können unter bestimmten Voraussetzungen auch von der Normenreihe EN 16931 abweichende strukturierte elektronische Rechnungsformate verwendet werden, z. B. EDI-Verfahren nach Artikel 2 der Empfehlung 94/820/EG der Kommission vom 19. Oktober 1994. Nach Rn. 33 und 34 können somit auch EDIFACT Rechnungen, die mit der EN 16931 kompatibel sind, also die gleichen Inhalte transportieren, auch nach den Übergangsfristen weiter verwendet werden.
Als Beispiele für national zulässige Formate benennt das Bundesfinanzministerium XRechnung und ZUGfERD. Als Beispiele für europäische elektronische Rechnungsformate Factur-X (Frankreich) oder Peppol-BIS Billing.
Auf die Unterschiede möchten wir nochmals detailliert eingehen.
Auf die Unterschiede im Schema sind wir in Teil 3 Die Struktur der E-Rechnung schon eingegangen. Folgende Tabelle stellt die beiden nationalen Formate gegenüber.
XRechnung | ZUGfERD | |
Art der Datei | Reine XML-Datei. Also eine einfache Textdatei, welche die Rechnungsinformationen maschinenlesbar in einer XML-Struktur enthält. Die Datei enthält nur ein maschinenlesbares Format. | Ist eine PDF/A-3 Datei. Dies ist eine menschenlesbare PDF-Datei, in die eine maschinenlesbare XML-Struktur eingebettet ist. Die Datei enthält sowohl ein maschinenlesbares als auch ein menschenlesbares Format. Eine “normale” PDF-Datei enthält nur das menschenlesbare Bild. |
Schema der XML-Struktur | ISO/IEC 19845 Information technology — Universal | UN/CEFACT Cross Industry Invoice in XML Schemas 16B (CII) Es muss die Version ab 2.0.1 sein. Die Profile MINIMUM und BASIC-WL sind ausgenommen. |
Europäische Alternativen | PEPPOL-BIS3 | Factur-X Französisches Format, welches ab dem 18. September 2024 identisch zu ZUGfERD ist. Factur-X EN |
ZUGFeRD und Factur-X
Seit 18. September 2024 ist Factur-X identisch zu ZUGfERD. Ein Unterschied ist nur der Name. Beides sind PDF/A-3 Dateien, die ein XML nach dem gleichen Schema beinhalten.
Beide Formate basieren auf UBL. XRechnung ist im Grunde PEPPOL zuzüglich einer Erweiterung / Anpassung der für XRechnung geltenden Geschäftsregeln um deutsche Besonderheiten.
Somit zählen für XRechnung
Rein vom UBL Schema unterscheiden sich XRechnung und PEPPOL-BIS also nicht voneinander. XRechnung basiert auf PEPPOL-BIS, wendet allerdings zusätzliche Geschäftsregeln an.
Sie definieren zum Beispiel, welche Pflicht-Inhalte angegeben sein müssen, oder welche inhaltlichen Zusammenhänge existieren und übereinstimmen müssen.
Regelherkunft | Beispiele |
Standard-Regeln der EN 16961 | BR-30 BR-CO-15 |
PEPPOL-BIS anwendbaren adaptierten Regeln | PEPPOL-EN16931-R046 PEPPOL-EN16931-R121 |
Zusätzlich ergänzende nationale deutsche Geschäftsregeln | BR-DE-4 BR-DE-19 |
Beispiel: Geschäftsregel BR-DE-18 für Skonto
Nehmen wir eine zusätzliche nationale Regel, die den Skonto betrifft.
Beim Skonto handelt es sich um einen Nachlass aufgrund einer verkürzten Zahlungsfrist. In Deutschland ist die Übermittlung von Skonto-Informationen in vielen Branchen üblich – im restlichen europäischen Ausland geschweige denn Drittland kann man dagegen kaum etwas damit anfangen.
Das Datenmodell der EN 16931 sieht daher derzeit keinen entsprechenden Prozess vor und stellt daher keine strukturierten Informationselemente zur Verfügung, um Skonto-Informationen in entsprechender Form abzubilden. Nach der Standardregel ist es ein Freitext-Feld.
Die zusätzlich ergänzende nationale deutsche Geschäftsregel BR-DE-18 definiert daher
Die Informationen zur Gewährung von Skonto müssen wie folgt im Element „Payment terms“ (BT-20) übermittelt werden:
Anzugeben ist im ersten Segment „SKONTO“, im zweiten „TAGE=n“, im dritten „PROZENT=n“. Prozentzahlen sind ohne Vorzeichen sowie mit Punkt getrennt von zwei Nachkommastellen anzugeben.
Liegt dem zu berechnenden Betrag nicht „Amount due for payment“ (BT-115) zugrunde, sondern nur ein Teil des fälligen Betrags der Rechnung, ist der Grundwert zur Berechnung von Skonto als viertes Segment „BASISBETRAG=n“ gemäß dem semantischen Datentypen Amount anzugeben.
Jeder Eintrag beginnt mit einer #, die Segmente sind mit einer # getrennt und eine Zeile schließt mit einer # ab. Am Ende einer vollständigen Skontoangabe muss ein XML-konformer Zeilenumbruch folgen.
Alle Angaben zur Gewährung von Skonto müssen in Großbuchstaben gemacht werden. Zusätzliches Whitespace (Leerzeichen, Tabulatoren oder Zeilenumbrüche) ist nicht zulässig. Andere Zeichen oder Texte, als in den oberen Vorgaben genannt, sind nicht zulässig.
Bei einer sonstigen Rechnung kann die Information über den Skonto durch den Sachbearbeiter gelesen, verstanden und umgesetzt werden.
Wurde das Skonto bisher mit “14 Tage 2%”, “2% Skonto bei Zahlung innerhalb der nächsten 2 Wochen” oder “98,23 EUR bis 08. November 2024” angegeben, konnte der Sachbearbeiter das Skonto entsprechend anwenden. Er musste es nur lesen und wissen, was er tut.
Für eine maschinenlesbare Verarbeitung ist “14 Tage 2%” oder “2 Prozent innerhalb der nächsten 2 Wochen” ein wesentlicher Unterschied. Daher musste diese Angabe standardisiert werden.
Das Standardisieren erfolgt über eine Geschäftsregel, die
Beispiel: Geschäftsregel BR-DE-17 für Gutschriften
Unter Verwendung des Standards XRechnung können Gutschriften gemäß § 14 Abs. 2 Satz 2 UStG übermittelt werden, d. h. der Leistungsempfänger erstellt die Abrechnung (Gutschriftsverfahren). Dies ist von kaufmännischen Gutschriften und Rechnungsberichtigungen deutlich zu unterscheiden.
Das semantische Datenmodell der XRechnung sieht den „Invoice type code“ (BT-3) zur eindeutigen Identifizierung vor. Dies ist in der Geschäftsregel BR-DE-17 definiert.
Damit werden folgende Szenarien eindeutig gekennzeichnet
Szenario | Code in BT-3 | Wert gem. UNTDID 1001 | Bemerkung |
(Rechnungs)Berichtigung | 384 | Corrected invoice | Bezug auf original vorhergehende Rechnung oder Gutschrift muss gegeben werden (s. „PRECEDING INVOICE REFERENCE“ (BG-3)) |
Gutschein/Gutschrift | 381 | Credit note | Behandlung als kaufmännische Gutschrift. Kein Bezug auf vorhergehende Rechnung notwendig. |
Gutschrift nach UStG | 389 | Self-billed invoice | Behandlung als Gutschrift gemäß § 14 Abs. 2 Satz 2 UStG |
Weitere Beispiele:
Weitere Geschäftsregeln kümmern sich zum Beispiel um die Datenkonsistenz im Dokument. So darf die Summe aller Zeilen nicht von der Gesamtsumme abweichen. Oder sie definieren bestimmte Kennungen, damit das Dokument richtig behandelt werden kann.
Was eine gültige Rechnung ist, definiert das Umsatzsteuergesetz – daran ändert sich im Grunde nichts. Nicht valide heißt daher nicht zwangsweise ungültig.
Bleiben wir beim Skonto. Wenn der Rechnungsaussteller eine Elektronische Rechnung mit Skonto nach PEPPOL-BIS3 erzeugt und die Skontodefinition somit nicht den zusätzlichen nationalen Geschäftsregeln entspricht, wird dadurch die Elektronische Rechnung nicht zu einer ungültigen Rechnung im Sinne des Umsatzsteuergesetzes.
Es wird aller Wahrscheinlichkeit nach zu einer manuellen Nacharbeit kommen müssen.
Die Rechnung ist dann nach Prüfung nicht valide, nach Umsatzsteuergesetz aber dennoch gültig.
Einzige tatsächliche Voraussetzung: das Format muss der Normenreihe EN 16931 entsprechen. Dies ist im BMF-Schreiben “III C 2 – S 7287-a/23/10001 :007” und Nummer “2024/0883282” im Punkt 2.3 und Randnotiz 24ff definiert.
Was bei invaliden Dokumenten passiert, müssen Rechnungsaussteller und Rechnungsempfänger untereinander klären
Die nationalen Geschäftsregeln für Deutschland werden von der Koordinierungsstelle für IT-Standards veröffentlicht.
Die Kosit listet auch die konkreten Geschäftsregeln und Definitionen für CIUS XRechnung und Extension auf.
Infobox
CIUS – Core Invoice Usage Specification.
Es handelt sich dabei um eine spezifizierte, standardisierte Form der elektronischen Rechnung (E-Rechnung), die von der EU entwickelt wurde, um Interoperabilität und Kompatibilität zu gewährleisten. CIUS hilft, bestimmte Anforderungen und Felder für elektronische Rechnungen festzulegen, um den Austausch zwischen Unternehmen und Behörden in verschiedenen Ländern zu erleichtern und zu standardisieren.
Nach XRechnung v.3.0.2 sind das die zusätzlich zu PEPPOL-BIS3 geltenden Regeln
| ID | Beschreibung |
| BR-DE-1 | Eine Rechnung (INVOICE) muss Angaben zu „PAYMENT INSTRUCTIONS“ (BG-16) enthalten. |
| BR-DE-2 | Die Gruppe „SELLER CONTACT“ (BG-6) muss übermittelt werden. |
| BR-DE-3 | Das Element „Seller city“ (BT-37) muss übermittelt werden. |
| BR-DE-4 | Das Element „Seller post code“ (BT-38) muss übermittelt werden. |
| BR-DE-5 | Das Element „Seller contact point“ (BT-41) muss übermittelt werden. |
| BR-DE-6 | Das Element „Seller contact telephone number“ (BT-42) muss übermittelt werden. |
| BR-DE-7 | Das Element „Seller contact email address“ (BT-43) muss übermittelt werden |
| BR-DE-8 | Das Element „Buyer city“ (BT-52) muss übermittelt werden. |
| BR-DE-9 | Das Element „Buyer post code“ (BT-53) muss übermittelt werden. |
| BR-DE-10 | Das Element „Deliver to city“ (BT-77) muss übermittelt werden, wenn die Gruppe „DELIVER TO ADDRESS“ (BG-15) übermittelt wird. |
| BR-DE-11 | Das Element „Deliver to post code“ (BT-78) muss übermittelt werden, wenn die Gruppe „DELIVER TO ADDRESS“ (BG-15) übermittelt wird. |
| BR-DE-12 | Mit dem Element „Deliver to post code“ (BT-78) muss eine Postleitzahl übermittelt werden. |
| BR-DE-13 | Nicht definiert. |
| BR-DE-14 | Das Element „VAT category rate“ (BT-119) muss übermittelt werden. |
| BR_DE_15 | Das Element „Buyer reference“ (BT-10) muss übermittelt werden. |
| BR-DE-16 | Wenn in einer Rechnung die Steuercodes S, Z, E, AE, K, G, L oder M verwendet werden, muss mindestens eines der Elemente „Seller VAT identifier“ (BT-31), „Seller tax registration identifier“ (BT-32) oder „SELLER TAX REPRESENTATIVE PARTY“ (BG-11) übermittelt werden. |
| BR-DE-17 | Mit dem Element „Invoice type code“ (BT-3) sollen folgende Codes aus der Codeliste UNTDID 1001 übermittelt werden:
|
| BR-DE-18 | Die Informationen zur Gewährung von Skonto müssen wie folgt im Element „Payment terms“ (BT-20) übermittelt werden: Anzugeben ist im ersten Segment „SKONTO“, im zweiten „TAGE=n“, im dritten „PROZENT=n“. Prozentzahlen sind ohne Vorzeichen sowie mit Punkt getrennt von zwei Nachkommastellen anzugeben. Liegt dem zu berechnenden Betrag nicht „Amount due for payment“ (BT-115) zugrunde, sondern nur ein Teil des fälligen Betrags der Rechnung, ist der Grundwert zur Berechnung von Skonto als viertes Segment „BASISBETRAG=n“ gemäß dem semantischen Datentypen Amount anzugeben. Jeder Eintrag beginnt mit einer #, die Segmente sind mit einer # getrennt und eine Zeile schließt mit einer # ab. Am Ende einer vollständigen Skontoangabe muss ein XML-konformer Zeilenumbruch folgen. Alle Angaben zur Gewährung von Skonto müssen in Großbuchstaben gemacht werden. Zusätzliches Whitespace (Leerzeichen, Tabulatoren oder Zeilenumbrüche) ist nicht zulässig. Andere Zeichen oder Texte, als in den oberen Vorgaben genannt, sind nicht zulässig. |
| BR-DE-19 | „Payment account identifier“ (BT-84) soll eine korrekte IBAN enthalten, wenn in „Payment means type code“ (BT-81) mit dem Code 58 SEPA als Zahlungsmittel gefordert wird. |
| BR-DE-20 | „Debited account identifier“ (BT-91) soll eine korrekte IBAN enthalten, wenn in „Payment means type code“ (BT-81) mit dem Code 59 SEPA als Zahlungsmittel gefordert wird. |
| BR-DE-21 | Das Element „Specification identifier“ (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen. |
| BR-DE-22 | Die in einer eingereichten Rechnung angehängten Dokumente in „ADDITIONAL SUPPORTING DOCUMENTS“ (BG-24) müssen im Element „Attached document“ (BT-125) einen eindeutigen Dateinamen haben (nicht case-sensitiv). |
| BR-DE-23 | Wenn „Payment means type code“ (BT-81) einen Schlüssel für Überweisungen enthält (30, 58), muss „CREDIT TRANSFER“ (BG-17) übermittelt werden. „PAYMENT CARD INFORMATION“ (BG-18) und „DIRECT DEBIT“ (BG-19) dürfen in diesem Fall nicht übermittelt werden. |
| BR-DE-24 | Wenn „Payment means type code“ (BT-81) einen Schlüssel für Kartenzahlungen enthält (48, 54, 55), muss genau „PAYMENT CARD INFORMATION“ (BG-18) übermittelt werden. „CREDIT TRANSFER“ (BG-17) und „DIRECT DEBIT“ (BG-19) dürfen in diesem Fall nicht übermittelt werden. |
| BR-DE-25 | Wenn „Payment means type code“ (BT-81) einen Schlüssel für Lastschriften enthält (59), muss genau „DIRECT DEBIT“ (BG-19) übermittelt werden. „CREDIT TRANSFER“ (BG-17) und „PAYMENT CARD INFORMATION“ (BG-18) dürfen in diesem Fall nicht übermittelt werden. |
| BR-DE-26 | Wenn im Element „Invoice type code“ (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll „PRECEDING INVOICE REFERENCE“ (BG-3) mind. einmal vorhanden sein. |
| BR-DE-27 | Mit dem Element „Seller contact telephone number“ (BT-42) soll eine gültige Telefonnummer übermittelt werden. Eine gültige Telefonnummer soll mindestens drei Ziffern enthalten. |
| BR-DE-28 | Mit dem Element „Seller contact email address“ (BT-43) soll eine gültige E-Mail-Adresse übermittelt werden. Hinweis: Technische Details zur Umsetzung sind in der XRechnung Schematron Regel BR-DE-28 zu finden. |
| BR-DE-29 | Diese Regel wird seit XRechnung 3.0.0 durch PEPPOL-EN16931-R061 ersetzt. |
| BR-DE-30 | Das Element „Bank assigned creditor identifier“ (BT-90) muss übermittelt werden, wenn die Gruppe „DIRECT DEBIT“ (BG-19) übermittelt wird. |
| BR-DE-31 | Das Element „Debited account identifier“ (BT-91) muss übermittelt werden, wenn die Gruppe „DIRECT DEBIT“ (BG-19) übermittelt wird. |
Zur Abdeckung branchenspezifischer Anwendungsfelder können EU-Mitgliedsstaaten das semantische Datenmodell der EN Norm 16931 mit sog. Extensions (Erweiterungen) ergänzen. Die „Extension XRechnung“ ist durch die Erweiterungen insbesondere für das Baugewerbe von Relevanz, aber auch andere Branchen können von der Nutzung profitieren. Weitere Informationen finden sich auf der Homepage der Koordinierungsstelle für IT-Standards.
Die Kosit hat auf github einige Validatoren als OpenSource veröffentlicht: Koordinierungsstelle für IT-Standards.
Tipp: Der Kosit Validator für XRechnung kann auch ZUGFeRD XMLs nach den nationalen Regeln prüfen.
MARKUS WEILAND
project manager
Das könnte Sie auch interessieren
