Einleitung
Ab dem 1. Januar 2025 wird die elektronische Rechnungsstellung für alle B2B-Transaktionen in Deutschland zur Pflicht. Mehrere andere Länder im Europäischen Wirtschaftsraum haben bereits ähnliche Anforderungen eingeführt oder werden bald folgen. Viele Unternehmen in Deutschland bemühen sich daher um die Einführung elektronischer Rechnungslösungen, auch wenn sie auf dem Weg dorthin mit einigen Herausforderungen konfrontiert werden.
In diesem Beitrag möchte ich den Aufbau einer elektronischen Rechnung so wie ich sie in meinem Workflow einsetzte, erläutern.
Generelles
Bevor ich mich die Tiefen des JSON der elektronischen Rechnung begebe, einige grundsätzliche Anmerkungen.
Das beschrieben Layout passt auf mein Unternehmen und mein Kundenumfeld. Es ist nicht allgemein gültig definiert und sollte auch nicht als solches betrachtet werden. Die Wahrscheinlichkeit, dass es auf ihr Unternehmen zutrifft ist dennoch hoch.
Die Implementierung und das Befüllen des JSON erfolgt im Custom-Part der Komponente docxGenerator⇑. Dadurch sind Anpassungen an die eigenen Bedürfnisse in beliebiger Form möglich.
Das JSON ist nur die Vorstufe für das eigentliche XML. Im ZUGFeRD Adapter des docxGenerators erfolgt die Transformation zum XML.
Regel
Um das JSON und dessen Inhalte zu verstehen müssen wir auf ein paar Regeln eingehen. Dieser Abschnitt beschäftigt sich mit den Inhalten, der nächste Abschnitt mit den formalen Anforderungen.
Alle Werte die einem Zweig im JSON zugewiesen werden, werden als Text zugewiesen, das gilt sowohl für Datums- als auch für numerische Werte.
Datumswerte müssen in der Form "MM-DD-YYYY" angegeben werden.
Numerische Werte werden ohne Tausendertrennzeichen und der Dezimaltrenner als "." eingetragen.
Formale Anforderungen
Die Struktur des JSON folgt streng der Basis von UBL-Invoice der Peppol BIS Billing 3.0⇑. Nur so können wir bei Entwicklung und fortschreitenden Harmonisierung der verschiedenen Beschreibungen schritthalten.
Um den Beschreibungen folgen zu können, müssen wir ein paar weitere Dinge betrachten.
Die Norm verwendet „Kardinalitäten“, um auszudrücken, in welchem Umfang ein bestimmtes Element erforderlich ist. Sie besteht aus zwei Zahlen, die durch zwei Punkte getrennt sind, z. B. 0..1. Die erste Zahl ist die Mindestzahl der Vorkommen, die zweite die Höchstzahl. Eine Mindestanzahl von 0 bedeutet, dass das Element optional ist.
Die Maximalzahl kann auch der Buchstabe n sein. Dieser steht für eine beliebige ganze Zahl größer als 0.
Eine Kardinalität von 1..1 bedeutet jedoch nicht unbedingt, dass dieses Element in einem Rechnungsdokument vorhanden sein muss. Es hängt von seinen Elternelementen ab.
Beispiel: Das Element /ubl:Invoice/cac:InvoiceLine/cac:AllowanceCharge/cbc:Amount⇑ hat die Kardinalität 1..1. Das übergeordnete Element /ubl:Invoice/cac:InvoiceLine/cac:AllowanceCharge⇑ hat jedoch die Kardinalität 0..n, was bedeutet, dass es optional ist, aber beliebig oft vorkommen kann. Das bedeutet, dass der cbc:Amount nur dann obligatorisch ist, wenn die Rechnungszeile auch einen cac:AllowanceCharge enthält.
Geschäftsregeln können auch das Vorhandensein eines bestimmten Elements verlangen. Zum Beispiel besagt BR-CO-25: „Wenn der fällige Betrag (BT-115) positiv ist, muss entweder das Fälligkeitsdatum (BT-9) oder die Zahlungsbedingungen (BT-20) vorhanden sein“, siehe https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-PaymentTerms/cbc-Note/⇑.
Das Vorhandensein bestimmter Elemente kann auch gesetzlich vorgeschrieben sein. Die Angabe des Ländercodes für die Adresse des Verkäufers und des Käufers reicht beispielsweise für den Standard aus. Eine solche Rechnung wird jedoch nach den Rechtsvorschriften Ihres Landes nicht gültig sein, weil andere Adressbestandteile wie Straße und Ort fehlen.
Basisaufbau des JSON
AccountingSupplierParty
Im Abschnitt AccountingSupplierParty⇑ werden die Informationen zum Mandanten - Rechnungssteller - beschrieben.
Das PartyTaxSchema⇑ ist notwendig, wenn an irgendeiner anderen Stelle ein Bezug auf die Umsatzsteuer angegeben ist. In der Regel ist das der Knoten InvoiceLine⇑ wo die einzelnen Rechnungspositionen aufgelistet werden.
Die CompanyID⇑ stellt hier bei die Umsatzsteuer Identnummer des Mandanten dar.
Die EndpointID⇑ gibt die elektronische Adresse des Verkäufers an, an die die Antwort auf die Rechnung auf Antragsebene zugestellt werden kann. Für meinen Zweck ist sie nicht notwendig, sie muss aber befüllt werden, deshalb trage ich hier auch die Umsatzsteuer-Identnummer des Mandanten ein.
Die restlichen Felder erklären sich von selbst. Sollten Sie nicht mit mehreren Mandanten arbeiten, kann dieser Bereich komplett mit konstanten Werten befüllt werden.
AccountingCustomerParty
Im Abschnitt AccountingCustomerParty⇑ werden alle Informationen zum Rechnungsempfänger abgelegt.
Im Prinzip, werden hier die gleichen Informationsdetails eingetragen wie beim Mandanten. Die Felder sind soweit sprechend, deshalb gehe ich auf diesen Knoten nicht weiter ein, da es sich nur um Wiederholungen handeln würde.
PaymentMeans
Der Abschnitt PaymentMeans⇑ enthält die Informationen zum Thema Zahlung.
An Hand der Cardinalität 0-n können Sie erkennen, dass mehre Zahlungsarten hinterlegt werden können.
Für meine Zweck nutze ich den Bank Transfer.
Das Feld ID⇑ ist die eindeutige Kennung des Finanzzahlungskontos bei einem Zahlungsdienstleister, auf das die Zahlung erfolgen soll. Zum Beispiel IBAN oder BBAN.
Das Feld Name⇑ ist der Name des Zahlungskontos bei einem Zahlungsdienstleister, auf das die Zahlung erfolgen soll. Diese Feld ist optional.
Je angebotener Zahlungsart kann ein Eintrag erzeugt werden.
LegalMonetaryTotal
Im Abschnitt LegalMonetaryTotal⇑ werden Summen der Rechnung aufgeführt.
Dieser Abschnitt ist ein Pflichtangabe.
LineExtensionAmount⇑ entspricht der Summe der Nettobeträge aller Rechnungszeilen in der Rechnung. Muss auf maximal 2 Dezimalstellen gerundet werden.
TaxExclusiveAmount⇑ ist der Gesamtbetrag der Rechnung ohne Mehrwertsteuer. Muss auf maximal 2 Dezimalstellen gerundet werden.
TaxInclusiveAmount⇑ ist der Gesamtbetrag der Rechnung mit Mehrwertsteuer. Muss auf maximal 2 Dezimalstellen gerundet werden.
PayableAmount⇑ ist der ausstehende Betrag, der gezahlt werden soll. Muss auf maximal 2 Dezimalstellen gerundet werden.
Alle Felder sind Pflichtfelder.
TaxTotal
Als letzten Bereich der Rechnung betrachten wir TaxTotal⇑.
"Wenn der Steuerwährungscode angegeben wird, müssen zwei Instanzen der Steuersumme vorhanden sein, aber nur eine mit der Steuerzwischensumme."
Es hat sich bei der Verifizierung des XML herausgestellt, dass ein Eintrag in diesem Bereich ausreichend ist.
TaxAmount⇑ ist der Gesamtbetrag der Mehrwertsteuer für die Rechnung oder der Gesamtbetrag der Mehrwertsteuer, ausgedrückt in der im Land des Verkäufers akzeptierten oder vorgeschriebenen Rechnungswährung. Muss auf maximal 2 Dezimalstellen gerundet werden.
Der Abschnitt TaxSubtotal⇑ besteht aus:
TaxableAmount⇑ Summe aller steuerpflichtigen Beträge, die einem bestimmten MwSt.-Kategoriecode und MwSt.-Kategoriesatz unterliegen (falls der MwSt.-Kategoriesatz anwendbar ist). Muss auf maximal 2 Dezimalstellen gerundet werden.
Abschließende Bemerkung
Im Grunde ist der Aufbau einer Rechnung auf Basis einer vorgegebenen Struktur recht einfach wenn man in der Materie drinsteckt. Ist das nicht der Fall, helfen nur noch Suchmaschine und Co um weiterzukommen.
Ich hoffe ich konnte Ihnen einen kleinen Einblick in das geben, was ich wie in meinem Unternehmen umgesetzt habe. Vielleicht kann ich Ihnen mit dieser Artikelserie, dem docxGenerator⇑ und der Integration von XRECHNUNG und ZUGFeRD in diesen einen Teil der Arbeit abnehmen.
Sprechen Sie mich einfach mal an und wir werden sehen, was ich für Sie tun kann.