XRechnung ist ein reines XML-Format nach EN 16931 (in Deutschland als CII-Syntax), das Behörden und viele große Abnehmer verlangen. Über eine API erzeugst du es in drei Schritten: Rechnung anlegen (der Server rechnet Summen und USt), ausstellen (Nummer wird atomar vergeben, das XML wird gerendert und validiert), XML abholen.
XRechnung ist das reine XML-Format der E-Rechnung: kein Sichtbeleg, nur strukturierte Daten nach EN 16931. Behörden (B2G) und viele große Abnehmer verlangen genau dieses Format. Hier ist der Flow, wie du eine gültige XRechnung per API erzeugst — ohne Codelisten, Geschäftsregeln und Profilstände selbst zu pflegen.
Der Flow: drei Calls
1) Rechnung anlegen. Du schickst Kunde und Positionen; Summen und USt rechnet der
Server. Der Idempotency-Key-Header macht Retries sicher — ein wiederholter
Draft-Create ist ein Replay, kein Duplikat.
POST /invoices
Authorization: Bearer sk_test_…
Idempotency-Key: 6f1c2a…
Content-Type: application/json
{
"currency": "EUR",
"documentTarget": "b2g",
"buyer": {
"name": "Stadt Fennbrück — Amt für Digitalisierung",
"addressLine1": "Marktstraße 12",
"postalCode": "24998", "city": "Fennbrück", "countryCode": "DE"
},
"buyerReference": "<LEITWEG-ID>",
"buyerElectronicAddress": "<LEITWEG-ID>",
"invoiceTypeCode": "380",
"lineItems": [
{ "description": "Wartung Fachverfahren Meldewesen (Q4 2026)", "quantity": "3",
"unitCode": "MON", "unitPriceNet": "1240.00", "taxRatePercent": "19" }
]
}Antwort: 201, Status "draft", alle Summen serverseitig berechnet. Beträge und
Mengen sind DECIMAL-Strings ("1250.00"), damit an Float-Rundung nichts verloren
geht.
2) Ausstellen. Das Finalisieren vergibt die Rechnungsnummer atomar, rendert das XRechnung-XML und validiert es gegen die EN-16931-Geschäftsregeln:
PATCH /invoices/{id}/finalize
Authorization: Bearer sk_test_…
# → Status "issued", Nummer vergeben, XRechnung-XML (CII) gerendert + validiert3) XML abholen. Das reine XRechnung-XML in CII-Syntax:
GET /invoices/{id}/xml
Authorization: Bearer sk_test_…
# → XRechnung 3.0, CIIBrauchst du zusätzlich einen menschenlesbaren Sichtbeleg, holst du dasselbe Dokument als hybrides ZUGFeRD/Factur-X über den PDF-Pfad — siehe ZUGFeRD 2.x / Factur-X per API erzeugen.
XRechnung, kurz erklärt
- Reines XML, keine PDF-Hülle. XRechnung transportiert nur strukturierte Daten; der Empfänger stellt sie bei Bedarf selbst dar.
- CII oder UBL. Beide Syntaxen erfüllen die EN 16931. Fortlauf erzeugt CII — dasselbe Modell, das auch im ZUGFeRD-Hybrid steckt, sodass beide Ausgaben aus einer Quelle entstehen.
- B2G-Besonderheiten. Im Behördenkontext adressiert die Leitweg-ID den
Empfänger (als
buyerReference, BT-10). Für inländisches B2B ist sie nicht nötig.
Validierung gehört dazu
Well-formed ist nicht valide: Eine XRechnung muss die Schematron-Regeln der EN 16931 und des XRechnung-Profils bestehen. Warum das mehr ist als korrektes XML, erklärt KoSIT-Validierung erklärt. Fortlauf validiert beim Ausstellen aus einem sauberen EN-16931-Datenmodell.
Was heute schon läuft
- Sandbox & API-Keys — live: eigene Test-Keys (
sk_test_) und eine vollständige Sandbox. Den Zugang legst du dir selbst an — kostenlos, ohne Karte: Produkt-Einstieg für Entwickler →.
Was noch kommt (ehrlich: Roadmap)
- GoBD-konforme Archivierung der strukturierten Originale — in Arbeit.
Der gezeigte Code ist illustrativ. Die Base-URL und die vollständige Feld-Referenz stehen offen im API-Referenzbereich — ohne Anmeldung. Der Produkt-Einstieg für Entwickler steht im Bereich für Entwickler; die API-Kategorie im Überblick unter E-Rechnung per API.
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 →