Empfangene E-Rechnungen auslesen

Seit 2025 kommen XRechnungen und ZUGFeRD-Rechnungen bei jedem Unternehmen in Deutschland an, und die Software dahinter muss daraus Daten machen: Wer hat die Rechnung gestellt, was wurde gekauft, wie viel Umsatzsteuer, wann ist sie fällig. Hier steht, was in diesen Dateien steckt, woran das Auslesen in eigenem Code scheitert und wie es mit einem API-Aufruf geht.

Stand 21. Oktober 2026 · Zuletzt geprüft 21. Oktober 2026

Warum Software E-Rechnungen jetzt lesen muss

Seit dem 1. Januar 2025 muss jedes Unternehmen in Deutschland E-Rechnungen von anderen Unternehmen empfangen können; ein E-Mail-Postfach reicht für den Empfang (E-Rechnungspflicht). Was ankommt, ist XRechnung oder ZUGFeRD. Buchhaltungs-, Spesen-, Einkaufs- und Kreditorensoftware, die bisher PDFs per OCR gelesen hat, bekommt die Daten jetzt strukturiert mitgeliefert, wenn sie das XML lesen kann. In Frankreich gilt die Empfangspflicht seit dem 1. September 2026, in Belgien laufen Rechnungen zwischen Unternehmen seit dem 1. Januar 2026 über Peppol (Frankreich, Belgien, jeweils auf Englisch).

Was ankommt und wo die Daten stehen

Alle tragen dasselbe europäische Datenmodell, die EN 16931, in einer von zwei XML-Syntaxen: UBL (Wurzelelement Invoice oder CreditNote) und UN/CEFACT CII (CrossIndustryInvoice). Die Spezifikationskennung (BT-24, cbc:CustomizationID in UBL, die Guideline-ID in CII) sagt, welche nationalen Regeln dazukommen.

Woran das Auslesen in eigenem Code scheitert

• Zwei Syntaxen, andere Pfade für alles. Die USt-IdNr. des Verkäufers steht in UBL unter cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID, in CII unter ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID mit schemeID="VA". Das gilt für jedes Feld: Sie schreiben und pflegen zwei Leser.
• Datumsangaben. UBL schreibt 2026-10-21, CII <udt:DateTimeString format="102">20261021</udt:DateTimeString>.
• Befreiungsgründe (Steuerschuldnerschaft des Leistungsempfängers, innergemeinschaftliche Lieferung, Ausfuhr) stehen einmal je USt.-Kategorie in der Aufschlüsselung, nicht an den Positionen.
• Gutschriften haben in UBL ein eigenes Wurzelelement (CreditNote mit CreditNoteLine und CreditedQuantity), in CII den Typcode 381.
• Profile ohne Positionen. ZUGFeRD MINIMUM und BASIC WL enthalten Summen, aber keine Positionen. Sie gelten nicht als E-Rechnung (BMF-FAQ, Frage 7), kommen aber trotzdem an.
• Summen. Die Rundung des Absenders kann um einen Cent von einer Nachrechnung abweichen. Buchen Sie die angegebenen Beträge und melden Sie die Abweichung, statt stillschweigend einen der beiden Werte zu nehmen.
• Sicherheit. Die Dateien kommen von außen. Weisen Sie DOCTYPE-Deklarationen und externe Entitäten vor dem Parsen ab, sonst kann eine Rechnung Dateien von Ihrem Server lesen (OWASP zu XXE).
• Werte ohne Platz im eigenen Datenmodell. Eine zweite Kennung, Warenklassifikationen, Positionshinweise: Wer sie stillschweigend verwirft, verliert Informationen, die später jemand braucht.

Auslesen mit einem API-Aufruf

curl https://validate.invoir.dev/api/v1/parse \
  -H "Authorization: Bearer $INVOIR_API_KEY" \
  -F file=@eingangsrechnung.pdf

Die Antwort, gekürzt:

{
  "status": "valid",
  "format": "PDF · Factur-X / ZUGFeRD EN 16931 (COMFORT)",
  "typeCode": "380",
  "invoice": {
    "profile": "factur-x", "conformance": "en16931", "type": "invoice",
    "number": "RE-2026-0042", "issueDate": "2026-10-19", "dueDate": "2026-11-18", "currency": "EUR",
    "seller": { "name": "Musterbau GmbH", "vatId": "DE123456789", "address": { "city": "München", "country": "DE" } },
    "buyer": { "name": "Beispiel AG", "reference": "PO-4711" },
    "lines": [ { "description": "Beratung Softwarearchitektur", "quantity": 12.5, "unit": "HUR", "unitPrice": 140, "vatRate": 19 } ],
    "payment": { "means": "credit_transfer", "iban": "DE89370400440532013000" }
  },
  "totals": { "currency": "EUR", "taxExclusive": 2912.20, "vat": 538.96, "taxInclusive": 3451.16, "due": 3451.16 },
  "unmapped": [],
  "warnings": [],
  "validation": { "status": "valid", "checks": [ "…" ] }
}

• invoice ist dasselbe JSON, das POST /invoices annimmt. Übernehmen Sie es in Ihr eigenes Datenmodell oder schicken Sie es zurück, um ein Dokument mit demselben Inhalt zu erzeugen.
• totals sind die Beträge so, wie sie in der Rechnung stehen, mit USt.-Aufschlüsselung: die Zahlen zum Buchen.
• unmapped listet jeden Wert ohne passendes JSON-Feld mit seinem Pfad im XML auf, damit nichts spurlos verschwindet.
• warnings sagen, was beim Lesen auffiel: Summen, die von einer Nachrechnung abweichen, eine Gutschrift, ein Dokument ohne Positionen.

Ein erfolgreicher Aufruf zählt als ein Dokument; der kostenlose Tarif enthält 25 im Monat, Test-Schlüssel sind kostenlos (25 Aufrufe am Tag). Alle Felder und Fehler stehen in der API-Dokumentation (auf Englisch).

Vor dem Buchen prüfen

Jeder Aufruf prüft die Rechnung auch nach den offiziellen Regeln, genau wie der kostenlose Validator: KoSIT-Validator für XRechnung, CEN- und Peppol-Schematron, Mustang für Factur-X und ZUGFeRD, veraPDF für das PDF. status sagt, ob die Rechnung gültig ist, und jeder Befund hat seine Regel-ID, etwa BR-DE-15 für die fehlende Käuferreferenz. Eine ungültige Rechnung wird trotzdem gelesen: Sie können sie ablegen und die Befunde an den Absender zurückschicken. Eine Prüfung ist keine Voraussetzung für den Vorsteuerabzug, das BMF hält sie aber für sinnvoll (BMF-FAQ, Frage 7).

Aus dem E-Mail-Postfach, ohne Code

Die meisten E-Rechnungen kommen weiterhin per E-Mail. In Make oder Zapier verbinden Sie den E-Mail-Auslöser des Werkzeugs mit Invoirs Parse-Aktion: neue E-Mail mit Anhang, dann E-Rechnung auslesen, dann eine Zeile in einer Tabelle oder ein Beleg in Ihrer Buchhaltung. Der n8n-Node bekommt dieselbe Aktion mit dem nächsten Release.

Häufige Fragen

Kann die API eine normale PDF-Rechnung lesen?

Nein. Ein PDF ohne eingebettetes Rechnungs-XML enthält keine strukturierten Daten, und Invoir macht kein OCR. Fragen Sie den Absender nach ZUGFeRD oder XRechnung: Seit 2025 muss ihn jedes Unternehmen in Deutschland empfangen können, ab 2027 bzw. 2028 müssen Unternehmen ihn auch ausstellen.

Welche Formate werden gelesen?

XRechnung (UBL und CII, auch als Hybrid-PDF), ZUGFeRD 2.x und Factur-X in allen Profilen, Peppol BIS Billing 3.0 sowie reine EN 16931 in UBL oder CII. ZUGFeRD 1.0, seit 2019 abgelöst, wird geprüft, aber nicht ausgelesen.

Wird die Rechnung gespeichert?

Nein. Die Datei wird für die Dauer des Aufrufs im Arbeitsspeicher verarbeitet und danach verworfen; weder Inhalt noch Dateiname werden protokolliert.

Was passiert mit einer ungültigen Rechnung?

Sie wird trotzdem gelesen. status ist dann invalid, und der Prüfbericht nennt jeden Fehler mit Regel-ID, damit Sie entscheiden, ob Sie buchen oder zurückschicken.

Was kostet das?

Jeder erfolgreiche Aufruf zählt als ein Dokument Ihres Tarifs: 25 im Monat kostenlos, danach ab 9 € im Monat zzgl. USt. für 300 (Preise). Fehler zählen nicht, Test-Schlüssel auch nicht (sie haben 25 Aufrufe am Tag).

Quellen

• Bundesministerium der Finanzen: Fragen und Antworten zur Einführung der obligatorischen E-Rechnung (Frage 7: welche Formate gelten, Prüfung).
• § 14 UStG.
• CEN/TC 434: Validierungsartefakte der EN 16931 (UBL- und CII-Abbildung).
• OWASP: XML External Entity Prevention Cheat Sheet.

Weitere Ratgeber

• E-Rechnungspflicht 2025–2028
• XRechnung validieren
• XRechnung vs. ZUGFeRD
• ZUGFeRD
• XRechnung
• ZUGFeRD validieren