So funktioniert invoice-api
Rechnungsdaten rein, konforme E-Rechnung raus – und in Gegenrichtung fremde E-Rechnungen lesen und prüfen.
Die Bausteine
Jeder Baustein ist ein Endpunkt. Der Status steht hier in derselben Form wie überall sonst auf der Seite – geplant heißt geplant, und immer mit Datum.
| Baustein | Was er tut | Wann du ihn brauchst | Endpunkt | Referenz |
|---|---|---|---|---|
VeriFactu Declaración (ES)Live | Gibt die declaración responsable des Software-Herstellers aus — das Dokument, das nach Art. 13.2 RD 1007/2023 im System einsehbar sein muss. | Wenn die AEAT oder ein Prüfer wissen will, wer die Software verantwortet. | GET /api/v1/verifactu/declaracion | Referenz |
VeriFactu Chain Export (ES)Live | Gibt die vollständige registro-Kette einer NIF als ein JSON-Dokument aus, jeden Eintrag mit seiner huella (Art. 14 RD 1007/2023). | Wenn eine Betriebsprüfung die Aufzeichnungen sehen will oder du die Hashes selbst nachrechnest. | GET /api/v1/verifactu/chain/{vatId}/export | Referenz |
Invoice CreatorLive | Erzeugt aus deinen Rechnungsdaten die fertige E-Rechnung im Format des Ziellandes. | Immer, wenn du eine Rechnung verschickst – das ist der Hauptweg. | POST /api/v1/invoice/{countryCode}/{format}/generate | Referenz |
PDF EmbedderLive | Legt das erzeugte XML in dein fertiges Rechnungs-PDF – dein Layout trägt die E-Rechnung. | Wenn das Sichtblatt aus deinem ERP oder deiner Druckerei kommt und genau so beim Empfänger ankommen soll. | POST /api/v1/invoice/{countryCode}/{format}/embed | Referenz |
ValidatorLive | Prüft eine Rechnung gegen die Regeln des Landes (EN 16931, KoSIT, Peppol) und meldet jeden Verstoß mit Regel-ID. | Vor dem Versand, und wenn du über Annahme oder Rückweisung einer eingegangenen Rechnung entscheidest. | POST /api/v1/invoice/{countryCode}/validate | Referenz |
ParserLive | Liest eine fremde E-Rechnung – XML oder ZUGFeRD-PDF – in dieselbe JSON-Struktur, die der Creator entgegennimmt. | Beim Rechnungseingang, wenn die Felder in deine Buchhaltung sollen. | POST /api/v1/invoice/parse | Referenz |
FormatsLive | Listet auf, welche Länder und Formate verfügbar sind — je Format Code, Label und Art (E-Rechnung oder PDF). | Wenn deine Oberfläche die Auswahl selbst aufbauen soll, statt sie fest zu verdrahten. | GET /api/v1/invoice/formats | Referenz |
ConverterLive | Wandelt eine fertige E-Rechnung in ein anderes Format um und meldet, was dabei nicht mitkommt. | Wenn du XRechnung hast, dein Empfänger aber ZUGFeRD verlangt – oder umgekehrt. | POST /api/v1/invoice/convert | Referenz |
AttachmentsLive | Hängt Dateien in ein bestehendes PDF, ohne dessen PDF/A-3-Konformität zu verlieren. | Wenn Stundenzettel, Lieferschein oder Leistungsnachweis mit der Rechnung reisen sollen. | POST /api/v1/invoice/attachments | Referenz |
VeriFactu QR (ES)Live | Erzeugt den QR-Code nach spanischer VeriFactu-Vorgabe, als URL, PNG oder SVG. | Wenn du nach Spanien fakturierst und der Beleg den QR-Code tragen muss. | POST /api/v1/invoice/es/verifactu-qr | Referenz |
VisualizerGeplant Q4/2026 | Rendert eine E-Rechnung als Ansicht für Menschen. | Wenn du XML im eigenen Produkt zeigen willst, ohne selbst ein Layout zu bauen. | POST /api/v1/invoice/render | Referenz |
ArchiveGeplant 2027 | Legt Rechnung und Prüfbericht revisionssicher ab. | Wenn du die gesetzliche Aufbewahrung nicht selbst betreiben willst. | POST /api/v1/invoice/archive | Referenz |
Peppol GatewayGeplant 2027 | Übergibt die Rechnung an das Peppol-Netz und nimmt die Zustellbelege entgegen. | Wenn der Empfänger über Peppol adressiert ist. Bis dahin: Versand per E-Mail oder Portal. | POST /api/v1/peppol/send | Referenz |
DATEV-Zustellung (TRAFFIQX)Geplant Q1/2027 | Übergibt die Rechnung über die TRAFFIQX Invoice API an den Postausgang, fragt den Zustellstatus ab und holt eingehende Rechnungen ab. | Wenn Empfänger oder Steuerkanzlei mit einem DATEV E-Rechnungspostfach arbeiten. Bis dahin: Datei per API erzeugen und über den bestehenden Kanal versenden. | POST /api/v1/traffiqx/send | Referenz |
Drei typische Wege
Fast jede Integration ist einer dieser drei Wege – oder eine Kombination aus zweien.
Ausgang: Rechnung verschicken
- 1Rechnungsdaten aus deinem System als JSON zusammenstellen.
- 2generate aufrufen; Land und Format stehen im Pfad, etwa DE und xrechnung.
- 3Optional attachments: Leistungsnachweis oder Lieferschein in das PDF hängen.
- 4Ergebnis per E-Mail oder Portal an den Empfänger geben.
Eingang: Rechnung lesen und prüfen
- 1Eingegangene Datei – XML oder ZUGFeRD-PDF – an parse geben.
- 2validate liefert den Prüfbericht mit Regel-IDs: die Grundlage für Annahme oder Rückweisung.
- 3Felder aus der Antwort in deine Buchhaltung übernehmen.
Umwandeln: Format wechseln
- 1Quelldatei, etwa eine XRechnung, an convert geben.
- 2Zielformat wählen: zugferd, facturx oder xrechnung.
- 3conversionWarnings lesen – dort steht, was das Zielformat nicht kennt.
Was der Service nicht tut
Drei Grenzen, die man vor der Integration kennen sollte – damit niemand an der falschen Stelle sucht.
Kein OCR für gescannte PDFs
parse liest strukturierte Daten: XML oder das eingebettete XML eines ZUGFeRD-PDFs. Ein eingescanntes Papier-PDF enthält keine, und hier wird auch keine geraten.
Ein PDF mit Textschicht — etwa immer dieselbe Word-Vorlage — lässt sich dagegen auslesen: in der n8n-Vorlage zieht die lokale Node pdf2invoice den Text und baut die Rechnung über ein Regelwerk, ohne OCR und ohne KI. Die Node ist noch nicht auf npm veröffentlicht — der Installationsweg steht in der Vorlage.
n8n-Vorlage: PDF zur E-RechnungKein Peppol-Versand
Der Peppol-Zugang ist geplant für 2027. Bis dahin entsteht hier die Datei, den Transport übernimmst du oder dein Access Point.
Anhängen macht aus einem PDF keine E-Rechnung
attachments hängt Dateien in ein PDF, mehr nicht – das eingebettete XML einer E-Rechnung entsteht daraus nicht. Soll dein eigenes PDF das Sichtblatt einer ZUGFeRD-Rechnung werden, ist embed der Weg: Wir erzeugen das XML aus deinen Daten und legen es in dein PDF. PDF/A-3 wird dabei an deinem Träger deklariert, nicht konvertiert.
Attachments API