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.
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.
| Ausgabe | Form | Typischer Einsatz |
|---|---|---|
| XRechnung | reines XML (UBL oder CII) | B2G und große Abnehmer |
| ZUGFeRD / Factur-X | hybrides PDF/A-3 mit eingebettetem CII-XML | B2B mit menschenlesbarem Sichtbeleg |
Die rechtlich heikle Mathematik (Summen, USt-Aufschlüsselung) und die atomare Nummernlogik liegen damit an genau einer Stelle statt verstreut in jedem Client.
Vertiefen → XRechnung per API erzeugen · ZUGFeRD 2.x / Factur-X per API erzeugen · 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-Keymacht 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.
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 →