Eingehende E-Rechnung auslesen und weitergeben

Aus XML oder ZUGFeRD-PDF werden Felder, die deine Buchhaltung übernehmen kann.

Im Posteingang liegt eine Mischung: XRechnung als XML, ZUGFeRD als PDF, dazwischen weiterhin PDFs ganz ohne Struktur. Der Parse-Endpoint nimmt die Datei Base64-kodiert entgegen, erkennt das Format und gibt die Rechnungsdaten strukturiert zurück — Nummer, Parteien, Positionen, Steuerbeträge. Was danach passiert, entscheidet dein System: Tabelle, ERP oder Freigabe-Workflow.

Was reinkommt

XRechnung als UBL- oder CII-XML

ZUGFeRD- oder Factur-X-PDF mit eingebettetem XML

Der Dateiname, damit das Format sicher erkannt wird

Der E-Mail-Anhang aus dem Posteingang, unverändert

Was das löst

01

Das Format wird erkannt, nicht geraten

Du musst nicht vorher wissen, ob eine XRechnung oder ein ZUGFeRD-PDF ankommt. Der Endpoint nimmt beides entgegen und antwortet mit derselben Struktur.

02

Bei ZUGFeRD zählt das eingebettete XML

Die Wahrheit steht im Anhang, nicht auf dem sichtbaren Blatt. Wer das PDF per Texterkennung liest, übernimmt im Zweifel eine Zahl aus der Layout-Spalte statt aus dem Beleg.

03

Rechnungsdaten kommen als Felder

invoiceNumber, seller, buyer, items, taxSummary, total: benannte Felder statt Textfragmente. Die Übergabe an Tabelle, ERP oder Buchhaltung ist danach eine Abbildung, keine Texterkennung.

04

Keine Verarbeitung durch ein Sprachmodell

Die Auswertung ist eine Abbildung des Dokuments, kein Ratespiel: Rechnungsdaten gehen nicht an ein Sprachmodell. Was der Parser meldet, steht im Beleg.

Ein echtes Beispiel

Ausschnitt aus der XRechnung, die das Rezept „Eingehende E-Rechnung auslesen“ an den Parser schickt.

xml
<cbc:ID>RE-2025-001</cbc:ID>
<cbc:IssueDate>2025-01-15</cbc:IssueDate>
<cbc:Name>Muster GmbH</cbc:Name>
<cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
<cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
<cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount>

POST /api/v1/invoice/parse

Antwort: die Rechnungsdaten als JSON — invoiceNumber RE-2025-001, der Verkäufer Muster GmbH, 1.000,00 € netto plus 190,00 € Steuer, 1.190,00 € zahlbar. Dieselben Werte, die oben im Dokument stehen.

Das vollständige Rezept

Die beteiligten Endpoints

  • Parser

    POST /api/v1/invoice/parse

    Live
  • Formats

    GET /api/v1/invoice/formats

    Live

Gegenüber der Alternative

Die Alternative ist eine Bibliothek im eigenen Betrieb — Mustang etwa. Das geht, kostet aber Pflege bei jeder Formatversion und einen Java-Prozess neben deiner Anwendung.

Zum Vergleich

So läuft es

  1. 1

    Anhang aus dem Posteingang holen und Base64-kodieren.

  2. 2

    POST /api/v1/invoice/parse mit data und filename.

  3. 3

    Felder aus der Antwort in Tabelle, ERP oder Freigabe schreiben.

Was es bei diesem Umfang kostet

Rund 1.000 Rechnungen im Monat liegen im Tarif Starter bei 23 € pro Monat.

Alle Preise netto, zzgl. USt. · 20 % Rabatt bei Jahreszahlung · Free-Tier ohne Kreditkarte

Alle Tarife

Grenzen

  • Ein PDF ohne eingebettetes XML enthält keine strukturierten Daten — der Parser kann daraus keine erfinden.
  • Die Antwort sagt, was im Dokument steht, nicht, ob es zu deiner Bestellung passt. Der fachliche Abgleich bleibt dein Schritt.
  • Revisionssichere Ablage ist nicht Teil der API (Archive API geplant 2027); den Ablage-Weg über einen Workflow zeigt das n8n-Template.

Häufige Fragen

Welche Formate kann der Parser lesen?

XRechnung als UBL und CII sowie ZUGFeRD- und Factur-X-PDFs mit eingebettetem XML. Den jeweils aktuellen Stand gibt die Formats-API aus.

Was passiert mit der Datei?

Sie wird für die Antwort verarbeitet und nicht an ein Sprachmodell weitergereicht. Wie die Verarbeitung im Einzelnen läuft, steht auf der Sicherheitsseite.

Wie komme ich von der Antwort in eine Tabelle?

Das n8n-Template „parse-email-to-sheets“ macht genau diesen Weg: Postfach beobachten, Anhang an den Parser, Zeile in die Tabelle schreiben.

Vom Anhang im Posteingang zu Feldern, mit denen die Buchhaltung arbeiten kann.