ZUGFeRD-E-Rechnung aus einer SharePoint-Liste: JSON in EN 16931 XML und PDF/A-3 in Power Automate mit PDF4me konvertieren

PDF4me Create ZUGFeRD Invoice ist eine Power Automate-Aktion, die Rechnungsdaten in eine hybride PDF/A-3-E-Rechnung umwandelt. Sie greift auf eine SharePoint-Liste zu, verwendet das von einer Compose-Aktion aus jeder Zeile generierte JSON, schreibt das EN 16931 konforme XML, fügt die lesbare Rechnung in das Basis-PDF ein, speichert das Ergebnis und sendet es per E-Mail an den Käufer.
Sucht man nach ZUGFeRD, landet man entweder auf einer Erklärung des Formats, einem Validator, der die Korrektheit vorhandener Dateien prüft, oder einer Bibliothek in PHP, Java oder C# für Entwickler von Rechnungssoftware. Alle drei setzen voraus, dass die Rechnung bereits existiert. Die Frage, die keine dieser Lösungen beantwortet, ist die, die sich Finanzteams tatsächlich stellen: Die Rechnungsdaten befinden sich in einer Liste, einer Tabelle oder einem anderen System zur Erfassung von Verkäufen und müssen am Ende als konforme E-Rechnung ausgegeben werden. Dieser Workflow schließt diese Lücke, in nur sieben Schritten und ohne Programmierung.
Eine Zeile mit Verkäufer, Käufer, einem Artikel und dem Datum landet in einer SharePoint-Liste. Vier Sekunden später befindet sich eine PDF/A-3 in einer Dokumentbibliothek: eine lesbare Seite mit eingebettetem EN 16931-XML zur Verarbeitung durch die Software des Käufers. Sie müssen diesen XML nicht selbst schreiben. Sie beschreiben die Rechnung als kurzes JSON-Objekt, und PDF4me generiert das Schema. Die Zeile erhält den Status und einen Link, und der Käufer erhält die Datei per E-Mail.
Warum-basierte Fragen und Antworten
Warum sollten Rechnungsdaten in einer SharePoint-Liste gespeichert werden? Weil die Daten in den meisten kleinen Finanzteams bereits in diesem Format vorliegen: eine Zeile pro Rechnung, von einer Person ausgefüllt. Die Spalten entsprechen eins zu eins den Feldern, die der Standard vorgibt. Das bedeutet, dass die Zuordnung für jeden sichtbar ist, der die Liste öffnet, und eine neue Rechnung eine neue Zeile und keine neue Datei in einem überwachten Ordner darstellt.
Warum sollte man die Rechnung als JSON anstatt als XML beschreiben? Weil die Syntax Cross Industry Invoice umständlich und streng ist: verschachtelte Namensräume, Elementnamen, die sich niemand merkt, und Codes, die exakt an der richtigen Stelle stehen müssen. Das JSON-Objekt beschreibt dasselbe in einem Bruchteil der Zeilen, mit Schlüsseln, die sich wie die entsprechenden Geschäftsbegriffe lesen. PDF4me konvertiert es in das Schema, sodass der fehleranfälligste Teil derjenige ist, den Sie nicht pflegen müssen.
Warum wird die Rechnung in ein PDF-Dokument umgewandelt? Weil eine ZUGFeRD-Datei aus zwei Teilen besteht, die übereinstimmen müssen. Die XML-Datei ist für die Software des Käufers, die gedruckte Seite für den Empfänger. Die Render Invoice on PDF zeichnet die Rechnung anhand derselben Daten, die auch die XML-Datei erzeugt haben, auf das PDF-Dokument. So können die beiden Dateien nicht voneinander abweichen, wie es bei separater Layoutverwaltung der Fall sein kann.
Warum PDF/A-3 und nicht ein gewöhnliches PDF? Weil PDF/A-3 der Archivierungscontainer ist, der Anhänge enthalten darf, und das eingebettete XML ist dieser Anhang. Es sorgt auch dafür, dass die Rechnung Jahre später noch lesbar ist: Schriftarten und Farbprofile bleiben in der Datei erhalten, was für ein Dokument, das die meisten Unternehmen ein Jahrzehnt lang aufbewahren müssen, von entscheidender Bedeutung ist.
Was Sie erhalten
Eingabe: Eine Zeile mit Rechnungsnummer, Datum, Währung, Verkäufer- und Käuferblock sowie einer Position. Ausgabe: Eine ZUGFeRD PDF/A-3-Rechnung in der ZUGFeRD Invoices Rechnungsbibliothek, die Zeile mit Status und Link aktualisiert, und eine E-Mail mit der angehängten Rechnung an den Käufer.

Eine Zeile pro Rechnung. Jede Spalte in diesem Bereich wird zu einem Schlüssel im JSON, den der Workflow erstellt.

Eine Datei pro Rechnungsnummer, erstellt vom Flow-Konto.

Die lesbare Hälfte derselben Datei, so wie sie der Käufer sieht.
Was Sie benötigen
- Power Automate. Öffnen Sie Power Automate. Ein automatisierter Cloud-Workflow mit Standardkonnektoren. SharePoint, Office 365 Outlook und PDF4me benötigen keinen Premium-Plan.
- PDF4me-API-Schlüssel. Holen Sie sich Ihren API-Schlüssel. Dieser Ablauf verwendet eine PDF4me-Verbindung, PDF4me PDF.
- Eine SharePoint-Liste für die Anfragen. Die erfasste Liste heißt ZUGFeRD Requests und enthält die InvoiceNumber, InvoiceDate, DueDate, Währung, Seller (Name, Straße, Postleitzahl, Ort, Land, Umsatzsteuer ID), Buyer, ItemDescription, Menge, UnitPrice, VATRate, eine Email Spalte, eine Status und eine OutputLink Spalte, in die der Flow schreibt.
- Eine Basisrechnung im PDF-Format. Der erfasste Workflow speichert
BaseInvoice.pdfin einer Bibliothek namens ZUGFeRD Templates. Auf dieser Seite wird die Rechnung erstellt, daher gehört Ihr Briefkopf hierher. - Eine Bibliothek für die fertigen Rechnungen. Der erfasste Workflow schreibt in ZUGFeRD Invoices.
- Ihre eigenen Verkäuferdaten, einschließlich Ihrer Umsatzsteuer ID. Diese werden in die Listenspalten eingetragen, sodass mit demselben Prozess Rechnungen für mehrere juristische Personen erstellt werden können.
Der Flow auf einen Blick
- When an item is created (SharePoint), wird die Liste mit dem Namen
ZUGFeRD Requestsüberwacht. - Compose erstellt das Rechnungs-JSON aus der Zeile.
- Get file content using path reads
/ZUGFeRD Templates/BaseInvoice.pdf. - Create ZUGFeRD Invoice (PDF4me PDF) konvertiert das JSON in EN 16931 XML und gibt das hybride PDF zurück.
- Create file wird in SharePoint als
ZUGFeRD_<invoice number>.pdfgespeichert. - Update item (SharePoint) setzt Status auf
Generatedund füllt OutputLink aus. - Send an email (V2) (Office 365 Outlook) wird die Rechnung an den Käufer gesendet.
Vollständige Ablaufübersicht

Der gesamte Vorgang dauert etwa viereinhalb Sekunden, wobei die Erstellung der elektronischen Rechnung selbst etwa eine Sekunde in Anspruch nimmt. Der langsamste Schritt ist das Schreiben der Datei durch SharePoint.
Schritt 1: Wie wird eine elektronische Rechnung ausgelöst, wenn eine Anfrage eingeht?
Bisheriger Ablauf: noch nichts, dies ist der Auslöser.
Das Hinzufügen einer Zeile ist der Weg, auf dem eine Rechnung angefordert wird; das ist also das Signal.
- Erstellen Sie einen Automated cloud flow und wählen Sie SharePoint > When an item is created.
- Konfigurieren:
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - List Name:
ZUGFeRD Requests
- Site Address:
When an item is created: Konfiguration

Jede Spalte in der neuen Zeile wird zu einem Token, das von den nächsten sechs Aktionen verwendet werden kann.
Schritt 2: Wie erstellt man die Rechnungs-JSON-Datei aus den Listenspalten?
Bisheriger Ablauf: der SharePoint-Trigger.
Eine einzige Aktion Compose beschreibt die gesamte Rechnung. Hier entsprechen Ihre Spaltennamen den Standardvorgaben und sind kurz genug, um auf einem Bildschirm gelesen zu werden.
- Data Operation > Compose.
- Fügen Sie das unten stehende Objekt in das Feld Eingaben ein und ersetzen Sie jeden Wert durch das entsprechende Token.
{
"InvoiceId": "@{triggerBody()?['InvoiceNumber']}",
"TypeCode": "380",
"InvoiceType": "RECHNUNG",
"IssueDate": "@{triggerBody()?['InvoiceDate']}T00:00:00",
"DeliveryDate": "@{triggerBody()?['InvoiceDate']}T00:00:00",
"IsTest": false,
"Seller": {
"Name": "@{triggerBody()?['SellerName']}",
"VatId": "@{triggerBody()?['SellerVATID']}",
"Address": {
"Street": "@{triggerBody()?['SellerStreet']}",
"PostalCode": "@{triggerBody()?['SellerPostalCode']}",
"City": "@{triggerBody()?['SellerCity']}",
"Country": "@{triggerBody()?['SellerCountry']}"
}
},
"Buyer": {
"Name": "@{triggerBody()?['BuyerName']}",
"Address": {
"Street": "@{triggerBody()?['BuyerStreet']}",
"PostalCode": "@{triggerBody()?['BuyerPostalCode']}",
"City": "@{triggerBody()?['BuyerCity']}",
"Country": "@{triggerBody()?['BuyerCountry']}"
}
},
"LineItems": [
{
"ProductName": "@{triggerBody()?['ItemDescription']}",
"Quantity": @{triggerBody()?['Quantity']},
"UnitCode": "C62",
"UnitPrice": @{triggerBody()?['UnitPrice']},
"LineTotal": @{float(...)}
}
],
"Totals": {
"Currency": "@{triggerBody()?['Currency']?['Value']}",
"LineTotal": @{float(...)},
"TaxBasisTotal": @{float(...)},
"TaxPercent": @{triggerBody()?['VATRate']},
"TaxTotal": @{float(...)},
"GrandTotal": @{float(...)},
"ChargeTotal": 0,
"AllowanceTotal": 0
},
"Payment": {
"Currency": "@{triggerBody()?['Currency']?['Value']}",
"PaymentReference": "@{triggerBody()?['InvoiceNumber']}",
"DueDate": "@{triggerBody()?['DueDate']}T00:00:00"
}
}
Compose: Konfiguration

Textwerte sind Token in Anführungszeichen. Geldbeträge und Mengen sind einfache Zahlen, weshalb sie über float verarbeitet werden.
Woher die einzelnen Teile der Rechnung stammen
| JSON-Schlüssel | Was es mit sich trägt | Quelle |
|---|---|---|
InvoiceId, TypeCode, InvoiceType | Rechnungsnummer, der Dokumenttypcode 380 für eine Handelsrechnung und das auf der Seite aufgedruckte Etikett | InvoiceNumber, dann feste Werte |
IssueDate, DeliveryDate | Wann die Rechnung ausgestellt wurde und wann die Dienstleistung erbracht wurde | InvoiceDate, gefolgt von T00:00:00 |
Seller | Name, Umsatzsteuer ID und vollständiger Adressblock | SellerName, SellerVATID, SellerStreet, SellerPostalCode, SellerCity, SellerCountry |
Buyer | Name und Anschrift des Kunden | BuyerName, BuyerStreet, BuyerPostalCode, BuyerCity, BuyerCountry |
LineItems | Beschreibung, Menge mit Einheitencode C62, Einzelpreis und Zeilensumme | ItemDescription, Menge, UnitPrice |
Totals | Währung, Nettobetrag, Steuergrundlage, Mehrwertsteuersatz und-betrag, Gesamtbetrag | Währung, VATRate und die berechneten Beträge |
Payment | Währung, Referenznummer, die der Käufer bei der Zahlung angibt, und Fälligkeitsdatum | Währung, InvoiceNumber, DueDate |
Hinweis: Nur die Geldwerte müssen arithmetisch verarbeitet werden und dürfen nicht als Zeichenketten in Anführungszeichen stehen, sondern müssen als reine Zahlen vorliegen. Für float werden Gleitkommaausdrücke verwendet. LineTotal ist die Menge multipliziert mit dem Einzelpreis, TaxBasisTotal die Summe der Zeilensummen, TaxTotal die Steuerbasis multipliziert mit dem Steuersatz geteilt durch 100 und GrandTotal die Summe der beiden. Für die erfasste Zeile sind das 1005, 1005, 190,95 und 1195,95. Eine Zahl in Anführungszeichen "1005" 1005) akzeptiert wird.
Schritt 3: Woher stammt die Basis-PDF-Datei?
Bisheriger Ablauf: der Auslöser plus Compose.
ZUGFeRD-Dateien haben eine lesbare Seite, und hier beginnt es.
- SharePoint hinzufügen > Get file content using path.
- Konfigurieren:
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - File Path:
/ZUGFeRD Templates/BaseInvoice.pdf - Infer content type (erweitert):
Yes
- Site Address:
Get file content using path: Konfiguration

Bewahren Sie Ihr Briefpapier in dieser Datei auf. Es wird bei jedem Durchlauf neu eingelesen, daher wirkt sich eine Änderung auf die nächste Rechnung aus.
Schritt 4: Wie wandelt man das JSON in ein ZUGFeRD PDF/A-3?
Bisheriger Ablauf: Auslöser, Compose und Get file content using path.
Dieser Vorgang erzeugt die elektronische Rechnung. Er liest das JSON-Dokument, schreibt das EN 16931 XML-Dokument selbst und gibt eine Datei zurück, die beide Teile enthält.
- Fügen Sie Create ZUGFeRD Invoice aus der PDF4me PDF Verbindung hinzu.
- Konfigurieren:
- ZUGFeRD version and Input Format:
2.0-JSON - Output Mode:
XmlWithPdf - Invoice JSON Data: der Ausdruck
base64(outputs('Compose')) - Conformance Level:
EN16931 - Render Invoice on PDF:
Yes - File Content: ein
base64()-Ausdruck über den Inhalt von Get file content using path - File Name:
BaseInvoice.pdf
- ZUGFeRD version and Input Format:
Create ZUGFeRD Invoice: Konfiguration

Das Eingabeformat bestimmt, welches Datenfeld angezeigt wird. Wählen Sie 2.0-JSON, werden Invoice JSON Data und nicht Invoice XML Data abgefragt.
Was jede Einstellung entscheidet
| Feld | Wert hier | Was es kontrolliert |
|---|---|---|
| ZUGFeRD version and Input Format | 2.0-JSON | Welcher ZUGFeRD Generation die Ausgabe folgt und dass die Daten als JSON ankommen, ist der Grund dafür, dass das Feld Invoice JSON Data angezeigt wird |
| Output Mode | XmlWithPdf | Es soll eine Hybriddatei zurückgegeben werden, die PDF-Datei mit eingebettetem XML, anstatt nur die XML-Datei |
| Invoice JSON Data | base64(outputs('Compose')) | Das Rechnungsobjekt, base64 kodiert auf dem Weg dorthin |
| Conformance Level | EN16931 | Das Profil, dem die Rechnung angeblich entspricht, und daher die Schlüssel, die das JSON liefern muss |
| Render Invoice on PDF | Yes | Zeichnen Sie die lesbare Rechnung auf die PDF-Vorlage, anstatt die Seite unverändert zu lassen |
| File Content, File Name | Das Basis-PDF | Die Seite, auf der die Rechnung erstellt wurde, und der Name, den die Aktion meldet |
Hinweis: Die Aktion zeigt je nach Format im Dropdown-Menü Invoice XML Data, Invoice JSON Data oder Invoice CSV Data an. Wählen Sie nur das passende Format aus. Das gleichzeitige Ausfüllen zweier Datenfelder ist die häufigste Ursache für Validierungsfehler bei dieser Aktion.
Schritt 5: Wo wird die Rechnung abgelegt?
Bisheriger Ablauf: alles über Create ZUGFeRD Invoice.
Die Rechnungsnummer dient als Dateiname und sorgt dafür, dass die Bibliothek durchsuchbar bleibt.
- SharePoint hinzufügen > Create file.
- Konfigurieren:
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - Folder Path:
/ZUGFeRD Invoices - File Name:
ZUGFeRD_gefolgt vom Token InvoiceNumber und der.pdf - File Content: das Body Token aus Create ZUGFeRD Invoice
- Site Address:
Create file: Konfiguration

Für RE-2026-0007 wird ZUGFeRD_RE-2026-0007.pdf geschrieben.
Schritt 6: Wie wird das Ergebnis der Anfrage erfasst?
Bisheriger Ablauf: Alles über Create file.
In der Zeile, in der die Rechnung angefordert wurde, sollte auch stehen, was mit ihr geschehen ist.
- SharePoint hinzufügen > Update item.
- Konfigurieren:
- Site Address:
PDF4me Support - https://ynoox1.sharepoint.com/sites/PDF4meSupport - List Name:
ZUGFeRD Requests - Id: das ID Token vom Auslöser
- Title: das Title Token aus dem Auslöser
- Status Value (erweitert):
Generated - OutputLink (erweitert): die Bibliotheks-URL gefolgt von
ZUGFeRD_, dem InvoiceNumber Token und.pdf
- Site Address:
Update item: Konfiguration

Der Link wird aus der Bibliotheks-URL und dem gleichen Namensmuster Create file zusammengesetzt, wobei das Leerzeichen im Bibliotheksnamen bereits als %20 codiert ist.
Schritt 7: Wie senden Sie die Rechnung an den Käufer?
Bisheriger Ablauf: alles über Update item.
Eine elektronische Rechnung, die in einer Bibliothek verbleibt, wurde noch nicht ausgestellt; die letzte Aktion führt zu ihrer Zustellung.
- Office 365 Outlook hinzufügen > Send an email (V2).
- Konfigurieren:
- An: das Email Token aus dem Auslöser
- Betreff:
Your ZUGFeRD e-invoicegefolgt vom InvoiceNumber-Token - Body: Eine Zeile mit dem Namen des Käufers und der Rechnung sowie dem Hinweis, dass es sich bei der Datei um ein PDF/A-3 mit eingebettetem EN 16931 XML handelt
- Öffnen Sie Advanced parameters und fügen Sie den Anhang hinzu:
- Attachments, 1:
ZUGFeRD_plus das Token InvoiceNumber plus.pdf - Attachments, 1: Das File Content aus Create ZUGFeRD Invoice
- Importance:
Normal
- Attachments, 1:
Send an email (V2): Konfiguration

Der Anhang bezieht seine Bytes aus der Aktion, die sie erzeugt hat, sodass SharePoint niemals zurückgelesen wird.
Führen Sie den Flow aus und überprüfen Sie ihn
- Den Arbeitsablauf Save.
- Fügen Sie in ZUGFeRD Requests eine Zeile mit einem Käufer, einem Positionsartikel, beiden Datumsangaben und einer überprüfbaren Adresse hinzu.
- Öffnen Sie den Ausführungsverlauf. Alle sieben Aktionen sollten grün sein, und der gesamte Ablauf sollte einige Sekunden dauern.
- Öffnen Sie die ZUGFeRD Invoices Rechnungsbibliothek und prüfen Sie, ob die Datei unter der Rechnungsnummer vorhanden ist.
- Gehen Sie zurück zur Zeile: Status sollte Generated lauten und OutputLink sollte die Rechnung öffnen.
- Öffnen Sie den Anhang der E-Mail und überprüfen Sie beide Hälften: Auf der Seite sollten die richtigen Beträge angezeigt werden, und die Datei sollte den XML enthalten.
Der aufgezeichnete Durchlauf dauerte insgesamt etwa vier Sekunden, wobei die elektronische Rechnung in einer Sekunde erstellt wurde. Das Ergebnis, ZUGFeRD_RE-2026-0007.pdf, ist ca. 331 KB groß und wird als deutsche Rechnung angezeigt: Verkäufer Muster GmbH in Berlin mit der USt- ID DE123456789, Kunde Test Kunde AG in Muenchen, Belegart 380, eine Position Consulting zu 19 % MwSt., Nettobetrag 1.005,00 EUR, MwSt. 190,95 EUR und Gesamtbetrag 1.195,95 EUR.
Was genau haben Sie entwickelt? Eine E-Rechnungs-Pipeline, die auf Ihren eigenen Datensätzen basiert. Die Daten bleiben dort, wo die Finanzabteilung sie verwaltet, der Standard wird durch XML erfüllt, das Sie nie selbst schreiben mussten, der Käufer erhält eine Datei, die seine Software automatisch lesen kann und die seine Mitarbeiter am Bildschirm einsehen können, und die Anforderungszeile protokolliert den Versand.
Häufige Variationen, die Sie hinzufügen können, ohne den Aufbau zu wiederholen
Wie sich dies im Vergleich zu den anderen Methoden zur Erstellung einer ZUGFeRD-Rechnung verhält
Jede Zeile beschreibt die Alternative. Die letzte Zeile stellt diesen Ablauf dar.
| Vergleich | Wer leitet es? | Woher die Daten stammen | Was Sie pflegen |
|---|---|---|---|
| Rechnungssoftware mit ZUGFeRD-Export im Vergleich zu diesem Ablauf | Jeder, der sich in diesem Produkt befindet | Die eigenen Aufzeichnungen des Produkts | Ein Abonnement und alles, was das Produkt unterstützt |
| E-Rechnungsplattform im Vergleich zu diesem Ablauf | Finanzen über ein Portal | Uploads oder eine Integration | Ein Vertrag pro Dokument und eine Verbindung dazu |
| Entwicklerbibliothek vs. dieser Ablauf | Ein Entwickler innerhalb einer Anwendung | Ihre Datenbank, durch Code | Der Code, die Schema-Aktualisierungen und die Releases |
| Dieser Fluss | Jeder, der eine Listenzeile hinzufügen kann | Eine SharePoint-Liste, die das Team pflegt | Ein JSON-Objekt und ein Basis-PDF |
Häufig gestellte Fragen
Was ist eine ZUGFeRD-Rechnung?
Eine ZUGFeRD-Rechnung ist eine Datei mit zwei Funktionen. Sie ist eine normale PDF-Datei, die geöffnet und gelesen werden kann. Darin befindet sich ein XML-Anhang mit den strukturierten Rechnungsdaten. Das Buchhaltungssystem des Käufers liest die XML-Datei und bucht die Rechnung automatisch, ohne dass ein manueller Eingriff erforderlich ist. Die Mitarbeiter in der Kreditorenbuchhaltung sehen hingegen weiterhin eine Seite.
Das Format stammt von FeRD, dem deutschen Forum für elektronische Rechnungsstellung, und sein französisches Pendant ist Factur-X, das die gleiche Idee unter einem anderen Namen verfolgt.
Was ist das ZUGFeRD-Format?
Technisch gesehen handelt es sich um einen PDF/A-3 Container mit einer eingebetteten XML-Datei in der Cross Industry Invoice Syntax und einem Profil, das den Vollständigkeitsgrad der Daten angibt. Das hier verwendete Profil ist EN16931, welches dem europäischen semantischen Standard für elektronische Rechnungen entspricht: den Feldern, die EN 16931 als Kern einer Rechnung definiert.
Die praktische Konsequenz für eine Automatisierung ist, dass die Ausgabe anhand des XMLs und nicht anhand der Seite beurteilt wird. Liefert man die vom Profil geforderten Daten, wird die Datei akzeptiert; gestaltet man die Seite ansprechender, ändert sich nichts.
Wie erstelle ich eine ZUGFeRD-Rechnung?
Sie benötigen drei Dinge: die Rechnungsdaten in strukturierter Form, ein Blatt Papier für den menschlichen Teil und etwas, das das XML als PDF/A-3-Anhang in die PDF-Datei schreibt.
In diesem Ablauf handelt es sich bei den Daten um eine SharePoint-Zeile, die in JSON umgewandelt wird. Die Seite ist BaseInvoice.pdf, und Create ZUGFeRD Invoice führt den dritten Teil mit Output Mode XmlWithPdf aus. Falls Ihre Daten bereits als Cross Industry Invoice XML-Datei oder als CSV-Zeile vorliegen, ändern Sie das Eingabeformat und verwenden Sie diese Daten stattdessen. Der restliche Ablauf bleibt unverändert.
Worin besteht der Unterschied zwischen ZUGFeRD und XRechnung?
Beide Formate erfüllen denselben europäischen Standard, der Unterschied liegt in der Verpackung. ZUGFeRD ist ein Hybridformat: eine lesbare PDF-Datei mit eingebettetem XML, ideal für Rechnungen an Kunden, die diese manuell öffnen. XRechnung hingegen ist reines XML und entspricht dem Format, das von deutschen öffentlichen Auftraggebern gefordert wird.
Wenn Sie an Unternehmen senden, ist die Hybriddatei in der Regel die sicherere Wahl, da sie von jedem, der sie öffnet, gelesen werden kann. Wenn Sie einer öffentlichen Stelle eine Rechnung stellen, prüfen Sie vor dem Versand, welches Format diese Stelle verlangt.
Fehlerbehebung
Öffnen Sie die Compose Ausgabe im Ausführungsverlauf und lesen Sie sie als JSON-Datei, bevor Sie weitere Schritte ausführen. Eine leere Spalte führt zu einem leeren Schlüssel, und ein Geldwert, der seine Anführungszeichen beibehalten hat, wird als Text angezeigt, wo eine Zahl erwartet wird. Beides erzeugt ein Objekt, das zwar korrekt aussieht, aber dennoch die Konvertierung nicht besteht.
Conformance Level bestimmt, welche Felder das Profil benötigt. Die Angabe von EN16931, obwohl die JSON-Datei Schlüssel auslässt, die das Profil erwartet, führt zu einem Validierungsfehler, selbst wenn sich die Datei normal öffnen lässt. Entweder Sie ergänzen die fehlenden Schlüssel oder Sie wählen ein niedrigeres Profil.
Render Invoice on PDF ist deaktiviert, daher wurde das XML eingebettet, ohne dass etwas gezeichnet wurde. Die Datei ist weiterhin eine gültige elektronische Rechnung, der lesbare Teil entspricht jedoch dem Inhalt der ursprünglichen PDF-Datei.
Prüfen Sie den Anhangsinhalt im E-Mail-Schritt und den File Content unter Create file. Beide müssen aus Create ZUGFeRD Invoice stammen. Wenn Sie stattdessen die Basis-PDF-Datei anhängen, wird zwar eine Seite gesendet, die korrekt aussieht, aber keine Informationen enthält, die die Software lesen kann.
Nächste Schritte
Das gleiche siebenstufige Muster (eine Zeile trifft ein, eine Rechnung wird als Daten beschrieben, eine Datei wird erstellt, abgelegt, erfasst und versendet) ist das, was jede E-Rechnungs-Vorschrift im Grunde verlangt, unabhängig davon, welches Format Ihre Käufer letztendlich benötigen.