Eine E-Rechnungs-API nimmt strukturierte Rechnungsdaten (Kunde, Positionen, Steuersätze) entgegen und gibt dir daraus EN-16931-konforme Belege zurück — XRechnung als XML und ZUGFeRD/Factur-X als hybrides PDF/A-3. Du schickst die Daten, der Dienst übernimmt Format, Berechnung und Nummernvergabe. So sparst du dir eigene Formatpflege gegen die EN 16931.

Kurz gesagt: Eine E-Rechnungs-API nimmt Rechnungsdaten als JSON entgegen — Kunde, Positionen, Steuersätze — und gibt eine EN-16931-konforme E-Rechnung zurück: XRechnung als reines XML (Syntax CII oder UBL; Fortlauf liefert CII) oder ZUGFeRD/Factur-X als PDF/A-3 mit eingebettetem XML. Summen und Umsatzsteuer rechnet der Server, die Rechnungsnummer vergibt er beim Ausstellen.

Format und VertiefungErgebnisTypischer EinsatzBei Fortlauf
XRechnung per API: Feldzuordnung und Versionreines XML in CII-Syntax (XRechnung 3.0.x)B2G und große Abnehmerlive
ZUGFeRD / Factur-X per API: Profil EN 16931PDF/A-3 mit eingebettetem CII-XMLB2B mit menschenlesbarem Sichtbeleglive
Peppol per API anbinden: der geplante WegVersand als Peppol BIS Billing 3.0 (UBL)Behördenumfeld, größere Partnergeplant, noch nicht verfügbar

live heißt: heute über die API nutzbar, in der Sandbox mit eigenen Test-Keys, im Live-Betrieb mit einem Live-Key aus einem bezahlten Tarif. geplant heißt: noch nicht verfügbar; kommt der Kanal, bleibt dein Erzeugungscode unverändert.

Was eine E-Rechnungs-API übernimmt

Sie nimmt strukturierte Rechnungsdaten entgegen — Kunde, Positionen, Mengen, Einzelpreise, Steuersätze — und liefert daraus die geforderten EN-16931-Ausgabeformate, inklusive serverseitiger Berechnung und lückenloser Nummernvergabe.

Die rechtlich heikle Mathematik (Summen, USt-Aufschlüsselung) und die atomare Nummernlogik liegen damit an genau einer Stelle statt verstreut in jedem Client.

Vertiefen → die zugrundeliegende Norm EN 16931

Sprachspezifisch → XRechnung erstellen mit PHP · XRechnung erstellen mit Node.js · E-Rechnung erstellen mit Python · E-Rechnung erstellen mit Java

Die sinnvolle Grenze: Daten rein, Beleg raus

Der stabilste Integrationsschnitt ist einfach: Dein System kennt den Geschäftsfall, die API kennt das Format.

  • Bei dir bleibt der Geschäftsfall: wer, was, wie viel, zu welchem Steuersatz.
  • Hinter der API bleibt alles Formatspezifische: Codelisten, EN-16931-Geschäftsregeln, Profilversionen, PDF/A-3-Konformität.

Ändert sich eine Profilversion, ziehst du keine eigene XML-Erzeugung nach.

Vertiefen → E-Rechnung selbst bauen oder eine API einbinden?

Idempotenz: Retries ohne Duplikate

Eine belastbare API arbeitet idempotent, damit ein wiederholter Aufruf keine zweite Rechnung erzeugt:

  • Anlegen — ein Idempotency-Key macht einen wiederholten Draft-Create zum Replay statt zum Duplikat.
  • Ausstellen — die Nummer wird atomar vergeben und bleibt am Entwurf haften, wenn die Ausstellung abbricht: Der nächste Versuch stellt denselben Beleg unter derselben Nummer aus. Ein wiederholter Aufruf auf eine bereits ausgestellte Rechnung wird abgewiesen (409) — weder Nummer noch Dokument verdoppeln sich.

So bleibt der Nummernkreis lückenlos, auch wenn dein Client neu sendet.

Erzeugung ist nicht Versand

Erzeugung (das strukturierte Dokument) und Versand (E-Mail, Portal, Peppol) sind zwei getrennte Schritte. Für inländisches B2B ist kein Übertragungsnetz vorgeschrieben — die E-Mail genügt, Peppol ist optional. Du erzeugst den Beleg einmal und entscheidest getrennt über den Weg zum Empfänger. Wie Peppol technisch funktioniert und warum die Anbindung bei uns geplant, aber noch nicht live ist, erklärt Peppol per API anbinden.

Der Rückweg gehört dazu: Wie ein Zahlungseingang auf deinem Bankkonto automatisch der passenden Rechnung zugeordnet wird, zeigt Automatischer Zahlungsabgleich einrichten.

Validierung: sauber erzeugt statt nachträglich repariert

Well-formed ist nicht valide: Eine E-Rechnung muss die Schematron-Geschäftsregeln der EN 16931 bestehen. Entsteht sie aus einem sauberen EN-16931-Datenmodell statt aus einem PDF-zu-XML-Konverter, fallen die häufigsten Regelverstöße gar nicht erst an.

Vertiefen → KoSIT-Validierung: was der Validator prüft

Worauf du bei der Auswahl achtest

  • Echte strukturierte Erzeugung statt PDF-zu-XML-Konverter-Wrapper.
  • Serverseitige Berechnung in Minor-Units, Beträge als DECIMAL-Strings.
  • Idempotenz und atomare Nummernvergabe als Konstruktionsprinzip, nicht als Option.
  • Validierung gegen die EN-16931-Regeln vor dem Versand.
  • Datensouveränität — wo laufen Erzeugung und Ablage?

Wie Fortlauf diese Grenze zieht und was heute schon steht, siehst du im Produkt-Einstieg für Entwickler. Sandbox und API-Keys sind live — eigene Test-Keys, und du legst dir den Zugang selbst an: kostenlos, ohne Karte. Die API-Referenz ist offen einsehbar.

Selbst ausprobieren? Der Zugang ist kostenlos und ohne Karte — Produkt-Einstieg für Entwickler →

Oder den eigenen Abrechnungsfluss konkret durchsprechen: 30 Min, technisch, mit dem Gründer →

Häufige Fragen

Was macht eine E-Rechnungs-API konkret?
Sie wandelt strukturierte Rechnungsdaten in EN-16931-konforme Ausgabeformate um: XRechnung (XML nach UBL oder CII) und ZUGFeRD/Factur-X (PDF/A-3 mit eingebettetem XML). Zusätzlich übernimmt sie meist die serverseitige Summen- und Steuerberechnung sowie die lückenlose Nummernvergabe.
Warum nicht selbst XRechnung-XML generieren?
Weil die EN 16931 und ihre nationalen Profile (XRechnung, ZUGFeRD) ein bewegliches Ziel sind: Codelisten, Geschäftsregeln und Profilversionen ändern sich. Eine API kapselt diese Pflege, sodass deine Integration stabil bleibt, während der Dienst die Formatstände nachzieht.
Brauche ich Peppol, um E-Rechnungen zu verschicken?
Nein. Für inländisches B2B ist kein Übertragungsnetz vorgeschrieben; die E-Mail ist ein zulässiger Weg. Peppol ist ein optionaler Kanal, der an Bedeutung gewinnt, aber nicht Pflicht ist. Eine API trennt sauber zwischen Erzeugung und Versand.