E-Rechnung ins ERP integrieren — der praktische Leitfaden per API

Das Problem: Daten ja, Format nein

Viele ERP-, Shop- und Buchhaltungssysteme erzeugen Rechnungen als PDF oder als Druckdatei. Ein strukturiertes XML nach EN 16931 geben sie nicht aus — genau das aber verlangt die E-Rechnungspflicht. Die eingebauten E-Rechnungs-Funktionen sind zudem oft unvollständig (etwa nur ein Format oder nur ein Profil).

Der naheliegende, aber teure Reflex ist ein Systemwechsel. Das ist selten nötig: Die Lücke liegt nur am Ausgang, nicht im ganzen System.

Der API-Ansatz in einem Satz

Eine REST-API schließt die Lücke: Ihr System sendet die vorhandenen Rechnungsdaten als einfaches JSON an einen Endpunkt und erhält das fertige Format zurück — XRechnung, ZUGFeRD oder Peppol BIS. Kein XML-Mapping in Ihrem Code, kein Formatzwang im ERP.

Weil es eine standardmäßige HTTP-Schnittstelle ist, spielt es keine Rolle, welches System Sie einsetzen: Alles, was einen HTTP-Aufruf machen kann, kann sie anbinden.

Schritt 1: Rechnungsdaten als JSON senden

Sie schicken die Rechnung als kanonisches JSON. Das folgende Beispiel erzeugt eine XRechnung; für ZUGFeRD ändern Sie nur das Feld "format".

curl -X POST https://api.invoapi.de/api/v1/generate \
  -H "Authorization: Bearer inv_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "format": "xrechnung",
    "invoice": {
      "invoice_number": "RE-2026-0001",
      "issue_date": "2026-09-08",
      "currency": "EUR",
      "buyer_reference": "04011000-12345-34",
      "seller": { "name": "Muster GmbH", "vat_id": "DE123456789" },
      "buyer":  { "name": "Kunde AG" },
      "lines": [
        { "description": "Beratung", "quantity": 10,
          "unit_price": "95.00", "tax_percent": 19 }
      ]
    }
  }'

Schritt 2: Konformes Format zurückerhalten

Die API berechnet Summen und Umsatzsteuer serverseitig mit exakter Dezimalarithmetik und gibt das fertige Dokument zurück — als reines XML (XRechnung), als hybrides PDF (ZUGFeRD) oder als Peppol-BIS-Dokument. Dieselben Eingabedaten liefern so jedes gewünschte Format, ohne dass Sie in Ihrem System etwas umbauen.

Schritt 3: Vor dem Versand prüfen

Ein abgelehntes Dokument beim Empfänger kostet Zeit. Deshalb sollte jede erzeugte Rechnung gegen die amtlichen Regelwerke geprüft werden — den offiziellen KoSIT-Validator, das CEN-EN-16931-Schematron und die Peppol-BIS-Regeln. Ein „gültig“ ist damit belastbar, und jeder Befund nennt Regel-ID, Bedeutung, betroffenes Feld und erwarteten Wert.

In der Praxis lässt sich die Prüfung direkt in den Erzeugungsschritt integrieren, sodass ein nicht konformes Dokument Ihr Haus gar nicht erst verlässt.

Schritt 4: Ausliefern und archivieren

Das fertige Dokument geben Sie aus Ihrem ERP an den Empfänger weiter — per E-Mail, Portal oder, bei Peppol, über einen Access Point. Zur Aufbewahrung gilt: Das strukturierte Original (das XML bzw. das hybride PDF) ist GoBD-gerecht und unverändert zu archivieren.

Für welche Systeme sich das eignet

Weil die Anbindung nur ein HTTP-Aufruf ist, passt sie zu praktisch jedem Setup:

• Große ERP wie SAP oder Microsoft Dynamics 365 Business Central.
• DACH-Warenwirtschaft und Shops wie JTL-Wawi, Shopware oder WooCommerce.
• Eigenentwicklungen und individuelle Fakturierung — hier ist der Bedarf am größten.
• Automatisierungs-Plattformen (z. B. Make, n8n, Zapier), wenn Sie ohne Code arbeiten möchten.

Datenschutz: ein oft übersehener Vorteil

Weil die Umwandlung während der Anfrage geschieht und die Rechnungsinhalte danach verworfen werden, muss kein externer Dienst Ihre Rechnungsdaten dauerhaft speichern. Für einen Datenverarbeitungs-sensiblen Vorgang wie die Rechnungsstellung ist das ein echter Pluspunkt — und lässt sich mit einem Auftragsverarbeitungsvertrag (AVV) sauber absichern.