E-Rechnungen automatisch mit n8n erzeugen: der komplette Workflow
Eine E-Rechnung mit n8n zu erzeugen ist weniger Arbeit, als die meisten erwarten: Die Rechnungsdaten liegen ohnehin schon in einer Tabelle, im CRM oder im eigenen System. Was fehlt, ist der Schritt von diesen Daten zur normkonformen ZUGFeRD-Rechnung nach EN 16931. Genau diesen Schritt übernimmt ein einziger HTTP-Request-Node: PDF und Rechnungsdaten gehen an finisma, die geprüfte E-Rechnung kommt zurück. Dieser Artikel zeigt den Workflow von Trigger bis Versand, mit kopierbarem Payload.
1. Wann sich der n8n-Weg lohnt
Wer im Monat drei Rechnungen schreibt, ist mit der Weboberfläche schneller: Dort können Sie kostenlos PDF in E-Rechnung umwandeln, ohne Konto und ohne Setup. Der n8n-Workflow spielt seine Stärke aus, sobald Rechnungen regelmäßig und nach demselben Muster entstehen:
- Abrechnungslauf am Monatsende: Ein Schedule-Trigger liest alle offenen Posten aus einer Tabelle oder Datenbank und erzeugt die Rechnungen in einem Durchgang.
- Rechnung nach Abschluss: Ein gewonnener Deal im CRM oder eine abgeschlossene Bestellung im Shop stößt die Rechnung automatisch an.
- Bestandssysteme ohne E-Rechnungs-Export: Das Faktura-Tool erzeugt weiterhin die gewohnte PDF, n8n reicht sie mit den Daten an finisma weiter und macht daraus die gültige E-Rechnung.
Der Zeitdruck dahinter ist real: Mit der E-Rechnungspflicht ab 2027 müssen größere Unternehmen im B2B-Geschäft strukturierte Rechnungen ausstellen, ab 2028 gilt das für alle. Eine PDF allein erfüllt die Pflicht nicht. Wer seine Rechnungserstellung ohnehin automatisiert hat, sollte die E-Rechnung gleich in denselben Workflow einbauen.
2. Was Sie brauchen
Eine n8n-Instanz
n8n Cloud oder selbst gehostet, beides funktioniert. Der Workflow nutzt nur Standard-Nodes (Trigger, Set/Code, HTTP Request), eine Community-Node ist nicht nötig.
Ein finisma-API-Key
Den Key erstellen Sie im finisma-Konto unter „API-Zugang". Er wird genau einmal angezeigt; finisma speichert nur einen Hash. Das Erzeugen von Rechnungen ist Teil des Abos für 8 € zzgl. MwSt. im Monat, ohne Kosten pro Aufruf. Das Prüfen ist kostenlos.
Rechnungsdaten und die visuelle PDF
finisma erwartet beides: die strukturierten Rechnungsdaten als JSON und die PDF, die der Kunde zu sehen bekommt. Die PDF kann aus dem Bestandssystem stammen, als E-Mail-Anhang eintreffen oder im Workflow selbst aus einer HTML-Vorlage erzeugt werden. Wichtig ist nur: Zahlen in der PDF und Zahlen im JSON müssen übereinstimmen, es ist dieselbe Rechnung in zwei Darstellungen.
3. Der n8n-Workflow in fünf Schritten
Das Grundgerüst besteht aus vier Nodes plus Ablage. In n8n sieht das so aus wie in der Grafik oben: Trigger, Daten-Mapping, HTTP-Request, Weiterverarbeitung.
API-Key anlegen
Im finisma-Konto unter 'API-Zugang' einen Key erstellen. Er wird genau einmal angezeigt und dient in n8n als Bearer-Token in einer Header-Auth-Credential.
Trigger einrichten
Der Workflow startet dort, wo die Rechnungsdaten entstehen: neue Zeile in Google Sheets, neuer Deal im CRM, ein Webhook aus dem eigenen System oder ein Schedule-Trigger für den monatlichen Abrechnungslauf.
Rechnungsdaten als JSON aufbereiten
Ein Set- oder Code-Node mappt die Felder aus dem Trigger auf die EN-16931-Struktur: Rechnungsnummer, Verkäufer, Käufer, Positionen, Steueraufschlüsselung und Summen.
HTTP-Request-Node an finisma konfigurieren
POST auf https://finisma.de/api/v1/invoices, Body als multipart-form-data: die PDF als Binary-Feld, die Rechnungsdaten als JSON-Feld. Die Antwort ist die fertige ZUGFeRD-PDF.
Ergebnis ablegen oder versenden
Die zurückgelieferte Datei geht als Binary weiter an den nächsten Node: E-Mail-Versand an den Kunden, Ablage in Google Drive oder S3, Übergabe an die Buchhaltung.
Für den API-Key legen Sie in n8n eine Credential vom Typ Header Auth an: Name Authorization, Wert Bearer fnsm_IHR_KEY. So bleibt der Key aus dem Workflow-JSON heraus und taucht in Exporten nicht auf.
4. Der HTTP-Request-Node im Detail
Das Herzstück ist ein einziger HTTP-Request-Node. Die Konfiguration:
| Einstellung | Wert |
|---|---|
| Method | POST |
| URL | https://finisma.de/api/v1/invoices |
| Authentication | Generic Credential Type → Header Auth (der Bearer-Key von oben) |
| Body Content Type | Form-Data (multipart) |
Body-Feld pdf | Typ „n8n Binary File", Input Data Field Name: das Binary-Feld des vorherigen Nodes (meist data) |
Body-Feld invoice | Typ „Form Data", Wert: die Rechnungsdaten als JSON-String (Beispiel unten) |
| Response | Format „File". Die fertige ZUGFeRD-PDF landet als Binary im Output und geht direkt an den nächsten Node. |
Das Feld invoice enthält die Rechnungsdaten nach EN 16931. Ein vollständiges Minimalbeispiel zum Kopieren:
{
"invoiceNumber": "RE-2026-107",
"issueDate": "2026-07-22",
"currency": "EUR",
"seller": {
"name": "Muster GmbH",
"vatId": "DE123456789",
"address": { "line1": "Hauptstr. 1", "city": "Hamburg",
"postalCode": "20095", "countryCode": "DE" }
},
"buyer": {
"name": "Kunde AG",
"address": { "line1": "Marktplatz 5", "city": "Berlin",
"postalCode": "10115", "countryCode": "DE" }
},
"lines": [
{ "name": "Beratung Juli", "quantity": 10, "unitCode": "HUR",
"unitPriceNet": 100, "vatRatePercent": 19, "lineNetAmount": 1000 }
],
"vatBreakdown": [
{ "ratePercent": 19, "basisAmount": 1000,
"taxAmount": 190, "categoryCode": "S" }
],
"totalNet": 1000,
"totalVat": 190,
"totalGross": 1190
}In der Praxis füllen n8n-Expressions die Felder aus dem Trigger, etwa "invoiceNumber": "={{ $json.Rechnungsnummer }}" für eine Spalte aus Google Sheets. Das vollständige Schema mit allen optionalen Feldern steht in der OpenAPI-Spezifikation.
Zwei optionale Felder sind im Alltag besonders nützlich: Über weitere attachments-Felder betten Sie Belege wie Stundenzettel direkt in die Rechnung ein (wie das normseitig funktioniert, zeigt der Artikel Dokumente an E-Rechnung anhängen). Und wer an Behörden fakturiert, übergibt in buyerReference die Leitweg-ID, finisma schreibt sie normkonform in das Feld BT-10.
5. Ergebnis automatisch gegenprüfen
Ein Workflow, der Rechnungen unbeaufsichtigt verschickt, braucht eine Qualitätsschranke. Dafür hängen Sie hinter die Erzeugung einen zweiten HTTP-Request-Node:
POST https://finisma.de/api/v1/verify Authorization: Bearer fnsm_IHR_KEY Body: multipart, Feld "pdf" = Binary aus dem vorherigen Node
Zurück kommt ein JSON-Prüfbericht: Ist das XML korrekt eingebettet, halten die Daten die EN-16931-Geschäftsregeln ein, stimmt die PDF/A-3-Struktur? Ein IF-Node dahinter entscheidet: Bericht sauber, dann E-Mail an den Kunden. Bericht mit Befunden, dann Nachricht an Sie statt an den Kunden. Diese Prüfung ist kostenlos und nutzt dieselbe Validierung wie der ZUGFeRD-Viewer im Browser.
6. Fehler und Rate-Limits sauber behandeln
Die API antwortet bei Problemen mit sprechenden Fehlercodes. Für den Workflow sind vier Fälle relevant:
| Status | Bedeutung | Reaktion in n8n |
|---|---|---|
400 | Rechnungsdaten fehlerhaft (Details mit Feldpfad im JSON) | Fehlerzweig: Datensatz zur manuellen Korrektur melden, nicht erneut senden |
401 | Key fehlt, ist ungültig oder widerrufen | Workflow stoppen und Credential prüfen |
403 | Erzeugen ohne aktives Abo | Abo im Konto prüfen |
429 | Rate-Limit erreicht (20 Erzeugungen/Minute) | „Retry on Fail" aktivieren; die Wartezeit steht im Header Retry-After |
Zum Datenschutz: finisma speichert die Rechnungen aus API-Aufrufen nicht. PDF und Daten kommen herein, die ZUGFeRD-Datei geht in derselben Antwort zurück, danach ist serverseitig nichts mehr vorhanden. Ihre Rechnungen liegen genau dort, wo Ihr n8n-Workflow sie ablegt.
Jetzt direkt ausprobieren
PDF-Rechnung in ZUGFeRD umwandeln
Erst manuell testen, dann automatisieren: kostenlos, ohne Anmeldung. Dateien werden nach 5 Minuten automatisch gelöscht.
PDF hierher ziehen oder klicken
Nur PDF-Dateien · max. 20 MB
7. Häufige Fragen zu E-Rechnungen mit n8n
Die wichtigsten Antworten kompakt, für alle, die schnell eine Einschätzung brauchen.
Brauche ich für den n8n-Workflow ein finisma-Abo?+
Für das Erzeugen von ZUGFeRD-Rechnungen (POST /api/v1/invoices) ja: Der API-Key setzt ein aktives Abo für 8 € zzgl. MwSt. im Monat voraus, monatlich kündbar und ohne Kosten pro Aufruf. Das Prüfen vorhandener Rechnungen (POST /api/v1/verify) ist kostenlos, benötigt aber ebenfalls einen API-Key.
Funktioniert der Workflow auch mit n8n Cloud?+
Ja. Der Workflow nutzt ausschließlich den eingebauten HTTP-Request-Node, eine Community-Node oder Selbst-Hosting ist nicht nötig. Er funktioniert in n8n Cloud genauso wie in einer selbst gehosteten Instanz.
Woher kommt die PDF-Datei im Workflow?+
Aus jedem Node, der Binärdaten liefert: ein E-Mail-Anhang, ein Download aus Google Drive oder S3, oder eine im Workflow erzeugte PDF (etwa aus einer HTML-Vorlage). Die Datei wird als Binary-Feld an den HTTP-Request-Node durchgereicht und dort als multipart-Feld pdf übergeben.
Was passiert, wenn die Rechnungsdaten fehlerhaft sind?+
finisma prüft die Daten vor der Erzeugung gegen das EN-16931-Schema und die Geschäftsregeln (Summen, Steuersätze, Pflichtfelder). Bei Fehlern antwortet die API mit Status 400 und einem JSON, das Feldpfad und Meldung enthält. In n8n lässt sich darauf ein Fehlerzweig bauen, der die Rechnung zur manuellen Korrektur meldet statt sie zu versenden.
Gibt es Rate-Limits?+
Ja, pro API-Key: 30 Prüfungen und 20 Erzeugungen pro Minute. Für typische Rechnungsläufe reicht das deutlich aus. Bei einer Ablehnung (Status 429) steht die Wartezeit im Header Retry-After, in n8n fängt das die Retry-Einstellung des HTTP-Request-Nodes ab.
Speichert finisma die Rechnungen aus dem Workflow?+
Nein. Die Verarbeitung läuft im Speicher: PDF und Rechnungsdaten kommen herein, die fertige ZUGFeRD-Datei geht in derselben Antwort zurück, danach ist auf dem Server nichts mehr davon vorhanden.
Kann n8n die erzeugte Rechnung auch prüfen?+
Ja. Ein zweiter HTTP-Request-Node schickt die erzeugte Datei an POST /api/v1/verify und bekommt einen strukturierten Prüfbericht zurück: Einbettung, EN-16931-Geschäftsregeln und PDF/A-3-Konformität. Erst wenn der Bericht sauber ist, gibt der Workflow die Rechnung zum Versand frei.
Quellen und weiterführende Informationen
- n8n-Dokumentation: HTTP Request Node
- finisma REST-API: Referenz für Entwickler
- Forum elektronische Rechnung Deutschland (FeRD): ZUGFeRD-Spezifikation
- EN 16931-1: Semantisches Datenmodell der elektronischen Rechnung