docxGenerator meets XRECHNUNG meets ZUGFeRD (allgemeines)

Die Europäische Union plant, die Rechnungsstellung im Laufe der nächsten Jahre vollständig zu digitalisieren. Sie hat eine Norm EN16931 geschaffen, die die Anforderungen an elektronische Rechnungen definiert.

Derzeit werden zwei Formate für Rechnungen akzeptiert, die der Norm EN16931 entsprechen. Das eine ist UBL (Universal Business Language), das andere CII (Cross-Industry Invoice). Beides sind XML-Formate.

Eine weitere Variante ist Factur-X bzw. ZUGFeRD. Factur-X wurde in Frankreich entwickelt, während ZUGFeRD das deutsche Pendant ist. Heute sind die beiden Formate identisch. Intern verwendet das Format CII, aber das XML-Dokument wird nicht direkt mit dem Kunden ausgetauscht, sondern an ein PDF-Dokument angehängt.

Viele Leser werden nicht wissen, dass es möglich ist, Dokumente an ein PDF anzuhängen, und die einzige GUI-Software, die PDF-Anhänge anzeigen oder extrahieren kann, ist Adobe Acrobat Reader.

Diese Funktion verbirgt sich hinter einem Büroklammer-Symbol am rechten Rand des Fensters. Wenn Sie darauf klicken, wird die Liste der Anhänge des Dokuments angezeigt. In diesem Fall ist nicht nur die XML-Rechnungsdatei, sondern auch eine zusätzliche Datei zu Informationszwecken angehängt.

Der Standard verwendet „Geschäftsbegriffe“, um Informationen in einer Rechnung zu beschreiben. Zum Beispiel ist die Rechnungsnummer die Geschäftsbedingung Nummer 1 oder kurz BT-1, der Ländercode der Postanschrift des Verkäufers ist BT-40, usw.

Der Standard enthält auch zahlreiche Geschäftsregeln, die Anforderungen an eine gültige Rechnung definieren. Zum Beispiel legt die Geschäftsregel BR-CO-27 fest, dass die „Summe der Rechnungszeile Nettobetrag (BT-106) = Σ Rechnungszeile Nettobetrag (BT-131)“.

Und hier endet die Standardisierung gewissermaßen. Die Mitgliedsländer können ihre eigenen Geschäftsregeln festlegen. Eine elektronische Rechnung, die in Deutschland gültig ist, ist nicht unbedingt in Dänemark gültig und akzeptiert und umgekehrt. Deutschland hat zum Beispiel seine eigenen Standards XRECHNUNG-UBL und XRECHNUNG-CII definiert. Rechnungen, die an Behörden ausgestellt werden, müssen diesen Standards entsprechen.

PDF-Dokumente gelten nicht als elektronische Rechnungen im Sinne von EN16931, und Word-Dokumente schon gar nicht. Elektronische Rechnungen müssen maschinenlesbar sein. Factur-X/ZUGFeRD-Dokumente gelten als maschinenlesbar, da die Rechnung im XML-Format aus der PDF-Datei extrahiert werden kann.

Der Text der EN16931 ist nicht frei verfügbar, zumindest nicht zum Herunterladen im Internet. Glücklicherweise hat OpenPeppol - eine Organisation, die PEPPOL (Pan-European Public Procurement OnLine) verwaltet - die sogenannten Business Interoperability Specifications (BIS) veröffentlicht. Eine dieser Spezifikationen ist die für UBL-Rechnungen, die unter Peppol BIS Billing 3.0⇑ verfügbar ist.

Diese Dokumentation beschreibt die Struktur und alle Anforderungen an UBL-Rechnungsdaten in einer sehr benutzerfreundlichen Weise. Dies ist ein Grund, warum das Projekt dieses Format als Grundlage für sein internes Format für Rechnungsdaten gewählt hat. Der wichtigste Unterschied ist, dass wir JSON anstelle von XML verwendet, aber die Struktur ist weitgehend identisch.

Um elektronische Rechnungen nicht nur maschinenlesbar, sondern auch maschinenverständlicher zu machen, müssen einige Textinformationen standardisiert werden, indem die Menge der möglichen Werte auf Werte aus Codelisten beschränkt wird.

Zum Beispiel hat die fakturierte Menge /ubl:Invoice/cac:InvoiceLine/cbc:InvoicedQuantity ein Attribut „@unitCode“, das einen standardisierten Einheitencode anstelle von Text wie Stück, pcs, Kilogramm oder Stunde enthalten muss. In der Dokumentation heißt es, dass der Einheitencode gemäß der UN/ECE-Empfehlung 20 mit der Erweiterung Rec 21 kodiert werden MUSS.

Sie finden alle Codelisten auf der PEPPOL-Website unter Peppol BIS Billing 3.0⇑  im Abschnitt „Codelisten“. Wenn Sie auf den Link Recommendation 20, including Recommendation 21 codes - prefixed with X (UN/ECE) klicken, öffnet sich die Seite mit der Codeliste, die alle zulässigen Werte enthält. Sie können auch sehen, für welche Elemente diese Codeliste verwendet wird.

Zum Beispiel werden „Stücke“ als H87 oder XPP kodiert. Viele Einheiten können mit zwei Codes kodiert werden; einer mit und einer ohne führendes X.

Übrigens, die Validierung in docxGenerator erzwingt die Verwendung der richtigen Codelisten.

Mein Unternehmen muss wie viele andere elektronische Rechnungen erstellen. Ich habe mich deshalb dazu entschlossen eine eigene Toolchain zu entwickeln.

Basis stellt das Tool docxGenerator das die Generierung der Rechnungsdokument an Hand von Templates ermöglicht, sowie die Integration von XRechnung und ZUGFeRD um die elektronische Rechnung zu erzeugen.

Zum Zeitpunkt dieses Beitrages kann die Software Rechnungen in den folgenden Formaten erstellen:

CII
Faktur-X/ZUGFeRD EN16931
Factur-X/ZUGFeRD Erweitert
Factur-X/ZUGFeRD XRechnung
UBL (PEPPOL)
XRECHNUNG-CII
XRECHNUNG-UBL

Anders als ursprünglich geplant, konnte die Erstellung von revisionssicheren PDF/A-Dokumenten für Factur-X/ZUGFeRD mit reinem JavaScript realisiert werden.

Obwohl das Rechnungsdatenformat gut dokumentiert ist, führen einige Felder häufig zu Fragen.

Der /ubl:Invoice/cbc:DocumentTypeCode muss aus der Liste Invoice type code (UNCL1001 subset) stammen. Der gebräuchlichste Typencode ist 380 für Handelsrechnungen.

Für Gutschriftsrechnungen schlägt die Dokumentation zu Factur-X/ZUGFeRD den Typencode 389 vor. Dieser Code ist jedoch nicht in der von PEPPOL bereitgestellten Liste enthalten.

Das gleiche Problem besteht bei Rechnungskorrekturen, wo die Factur-X-Dokumentation den Code 384 vorschlägt, der wiederum nicht in der PEPPOL-Liste enthalten ist.

Wenn Sie weitere Informationen zu diesem Thema haben, hinterlassen Sie bitte einen Kommentar.

Das Feld /ubl:Invoice/cbc:BuyerReference ist eigentlich ein optionales Feld. Die Geschäftsregel PEPPOL-EN16931-R003 verlangt jedoch, dass entweder die Käuferreferenz oder die Bestellreferenz /ubl:Invoice/cac:OrderReference/cbc:ID vorhanden sein muss.

Die Bestellreferenz ist in der Regel eine Bestellnummer, die vom Kunden vergeben wird, wenn er Waren oder Dienstleistungen bei Ihrem Unternehmen bestellt hat.

Die Käuferreferenz hat eine besondere Semantik für Rechnungen, die an deutsche öffentliche Einrichtungen ausgestellt werden. Die deutsche Norm XRECHNUNG verlangt, dass das Feld vorhanden sein und die sogenannte Leitweg-ID enthalten muss. Sie können diese Leitweg-ID oft im Internet nachschlagen oder auch den Kunden fragen, der seine eigene ID kennt.

Sowohl der Lieferant als auch der Kunde müssen durch eine Endpunkt-ID identifiziert werden. Die entsprechenden Felder sind /ubl:Invoice/cac:AccountingSupplierParty/cac:Party/cbc:EndpointID (BT-34) und /ubl:Invoice/cac:AccountingCustomerParty/cac:Party/cbc:EndpointID (BT-49). Eine sichere Wahl ist die jeweilige Umsatzsteuer-Identifikationsnummer, die für deutsche Umsatzsteuer-Identifikationsnummern die @schemeID 9930 hat. Für andere Länder können Sie die @schemeID in der Codeliste CEF Electronic Address Scheme (EAS) nachschlagen. Andere beliebte Wahlmöglichkeiten sind die oben erwähnte Leitweg-ID (@schemeID 0204) oder der EAN-Standortcode (@schemeID 0088), auch bekannt als Global Location Number GLN.

Die Factur-X/ZUGFeRD-Dokumentation erlaubt auch die Verwendung von E-Mail-Adressen mit der @schemeID EM, aber dies ist eine weitere Diskrepanz zwischen dieser Dokumentation und der PEPPOL-Dokumentation, da EM in der PEPPOL-Liste fehlt. Wenn Sie etwas Licht in diese Angelegenheit bringen können, hinterlassen Sie bitte einen Kommentar.

Bei größeren Unternehmen ist es durchaus üblich, dass sie bestimmte Anforderungen an die zu verwendende Endpunkt-ID und @schemeID stellen, und sie werden Sie normalerweise darüber informieren. Die Umsatzsteuer-ID ist jedoch ein guter Standard.

Sowohl Ihre IBAN als auch Ihr BIC/SWIFT-Code sind eigentlich optional. Aber viele Kunden bestehen darauf, sie zu erhalten, damit die Zahlung organisiert werden kann. Sie benötigen auch den Namen des Kontoinhabers und die Zahlungsart. Die entsprechenden Felder sind ubl:Invoice/cac:PaymentMeans/cac:CardAccount/cbc:HolderName für den Namen des Kontoinhabers, ubl:Invoice/cac:PaymentMeans/cbc:PaymentMeansCode für den Code der Zahlungsart (eine Überweisung hat Code 30), ubl: Invoice/cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID für die IBAN, und ubl:Invoice/cac:PaymentMeans/cac:PayeeFinancialAccount/cac:FinancialInstitutionBranch/cbc:ID für den BIC/SWIFT-Code.

Zu- und Abschläge, die im Standard als Gebühren und Nachlässe bezeichnet werden, können auf der Belegebene, der Einzelpostenebene oder der Preisebene angewendet werden. Sie werden innerhalb von cac:AllowanceCharge-Gruppen definiert, zum Beispiel /ubl:Invoice/cac:AllowanceCharge. Anders als bei Papierrechnungen üblich, haben Rabatte in diesem Fall auch einen positiven Wert. Ob es sich um einen Zuschlag oder einen Rabatt handelt, wird durch das Feld cbc:ChargeIndicator innerhalb der Gruppe bestimmt, z. B. /ubl:Invoice/cac:AllowanceCharge/cbc:ChargeIndicator, das für Zuschläge true und für Rabatte false enthalten muss.