E-Rechnung, wie du sie als Backend liest.
Du baust die Software, deine Kunden rechnen darin ab. Fortlauf gibt dir die E-Rechnungs-Schicht als API: XRechnung (CII) und ZUGFeRD/Factur-X raus, ohne dass du KoSIT-Updates, Formatpflege und Nummernkreise selbst betreiben musst.
Der Kern-Flow: drei Calls
Drei Schritte: Rechnung anlegen (der Server rechnet Summen und USt), ausstellen (Nummer + Format werden festgezogen), Artefakt abholen.
- 1 Anlegen
POST /invoicesSummen & USt rechnet der Server - 2 Ausstellen
PATCH /invoices/{id}/finalizeNummer atomar, Beleg erzeugt - 3 Abholen
GET /invoices/{id}/pdfZUGFeRD-PDF/A-3, XML eingebettet
# 1) Anlegen — Summen/USt rechnet der Server, Idempotency-Key macht Retries sicher
POST /invoices
Authorization: Bearer sk_test_…
Idempotency-Key: 6f1c2a…
Content-Type: application/json
{
"currency": "EUR",
"buyer": {
"name": "Achsfeld Transporte GmbH",
"addressLine1": "Gewerbestraße 8",
"postalCode": "59192", "city": "Bergkamen", "countryCode": "DE"
},
"buyerElectronicAddress": "rechnung@achsfeld.de",
"invoiceTypeCode": "380",
"lineItems": [
{ "description": "Ladevorgänge Juli 2026", "quantity": "1",
"unitCode": "C62", "unitPriceNet": "420.00", "taxRatePercent": "19" }
]
}
# → 201, Status "draft", Summen serverseitig berechnet # 2) Ausstellen — vergibt die Rechnungsnummer atomar, erzeugt den Beleg
PATCH /invoices/{id}/finalize
Authorization: Bearer sk_test_…
# → Status "issued", ZUGFeRD-PDF/A-3 (EN 16931 CII eingebettet) wird erzeugt # 3) Abholen — das hybride ZUGFeRD-PDF/A-3 (XML im PDF eingebettet)
GET /invoices/{id}/pdf
Authorization: Bearer sk_test_… Geldbeträge und Mengen sind DECIMAL-Strings („420.00"), damit nichts an Float-Rundung verloren geht. Felder gekürzt; jedes Feld steht in der API-Referenz.
Warum das eine Infrastruktur-Entscheidung ist
Deutsche Infrastruktur
Fortlauf läuft auf eigener, in Deutschland gehosteter Infrastruktur — kein Umweg über einen externen Managed-Cloud-Anbieter im Kernpfad.
Formate, die die Pflicht verlangt
XRechnung (CII) und ZUGFeRD/Factur-X (PDF/A-3) — nicht ein Konverter-Wrapper, sondern strukturierte Erzeugung.
Nummernkreise & Unveränderlichkeit
Rechnungsnummern werden atomar und je Unternehmen vergeben; ausgestellte Dokumente sind eingefroren.
Prüfung vor der Ausstellung
Besteht eine Rechnung die KoSIT-Prüfregeln nicht, wird
sie nicht ausgestellt; den Prüfbericht holst du per API ab.
POST /validate prüft auch fremde
Rechnungen, ohne etwas anzulegen.
Signierte Webhooks
Ereignisse zu Ausstellung, Versand und Archivierung kommen signiert bei dir an, mit Wiederholungen, Protokoll und Replay.
Zahlungen zurückmelden
Dein Job meldet Zahlungseingänge signiert an eine Zahlungsquelle, Fortlauf ordnet sie der Rechnung zu. Anleitung: Zahlungsabgleich einrichten
Docs & Sandbox
Die vollständige, aus openapi.yaml generierte Referenz ist bereits online — jede
Ressource und jeder Endpunkt mit Beispiel-Requests und -Responses:
Zur API-Referenz → Zum Quickstart → Leitfaden: E-Rechnung per API erzeugen →
Sandbox und API-Keys sind live: eigene Test-Keys, eine vollständige Sandbox mit Test-Clock und dieselbe API wie im Produktivbetrieb. Du meldest dich selbst an — ohne Karte, ohne Freischaltung, ohne Gespräch.
Aus der Sandbox gehen echte, mit [Sandbox] gekennzeichnete Test-E-Mails raus: über
deinen eigenen Mailserver oder über den Testversand von Fortlauf, dort nur an bestätigte Antwortadressen
und Personen aus deinem Unternehmen und mit einem Tageslimit.
In 15 Minuten zur ersten XRechnung.
Anlegen, ausstellen, abholen — mit deinem eigenen Test-Key gegen dieselbe API, die im Produktivbetrieb läuft. Wenn du lieber erst redest: 30 Minuten, technisch, mit dem Gründer, kein Sales-Deck.
Sandbox mit vollem API-Zugang, Test-Keys und Test-Clock. Keine Karte, kein Checkout.