XRechnung 3.0
XRechnung API. JSON rein, valides XML raus.
XRechnung 3.0 (UBL oder CII) aus einem JSON. Bevor Sie das XML sehen, ist es durch den offiziellen KoSIT-Validator. Schlägt eine Regel fehl, bekommen Sie keinen [BR-DE-15]-Code, sondern invoice.buyer_reference und den Fix.
Für Product Teams, die E-Rechnung in ein SaaS einbetten. Nicht für Einzelrechnungen.
API-Key holen (kostenlos, 50 Dokumente/Monat)XRechnung validieren, ohne Key
JSON rein, XRechnung 3.0 raus
Ein Endpoint. Dieselbe Payload für UBL und CII.
POST https://api.normbill.com/v1/invoices/generate
curl https://api.normbill.com/v1/invoices/generate \
-H "Authorization: Bearer sk_live_..." \
-H "Content-Type: application/json" \
-d '{ "format": "xrechnung-3.0", "invoice": {
"number": "INV-2026-0001",
"issue_date": "2026-06-15",
"due_date": "2026-07-15",
"buyer_reference": "04011000-1234512345-06",
"seller": {
"name": "Muster Lieferant GmbH", "vat_id": "DE123456789",
"address": { "country": "DE", "city": "Berlin",
"postal_code": "10115" },
"contact": { "name": "Billing", "phone": "+49 30 1234567",
"email": "billing@lieferant.example" }
},
"buyer": {
"name": "Beispiel Kunde AG",
"address": { "country": "DE", "city": "Hamburg",
"postal_code": "20095" },
"contact": { "email": "ap@kunde.example" }
},
"payment": { "iban": "DE89370400440532013000" },
"lines": [{ "name": "Beratungsleistung", "qty": 10,
"unit_price": 100, "vat": 19 }]
} }'format: "xrechnung-3.0" oder "xrechnung-cii-3.0". Summen, EUR und Payment-Means-Code rechnet die API, wenn sie fehlen.
Offizieller KoSIT-Validator. Kein stilles XML.
Drei Stufen: strukturelle Regeln, XSD, KoSIT-Schematron (gepinnt). Ungültig kommt nicht als 200 zurück, sondern als 422 mit Report. Validation, Retries und fehlgeschlagene Calls zählen nicht gegen das Kontingent.
422 mit invoice.buyer_reference, nicht BR-DE-15
{
"valid": false,
"format": "xrechnung-3.0",
"profile": "XRechnung 3.0.2 (UBL 2.1)",
"tier": "schematron",
"counts": {
"errors": 1,
"warnings": 0
},
"issues": [
{
"severity": "error",
"rule": "BR-DE-15",
"path": "invoice.buyer_reference",
"message": "Buyer reference (BT-10) is missing. XRechnung requires it; public-sector buyers in Germany use their Leitweg-ID here.",
"fix": "Set invoice.buyer_reference. Leitweg-ID format: 04011000-1234512345-06.",
"docs_url": "https://normbill.com/docs/rules/br-de-15",
"location": "/ubl:Invoice/cbc:BuyerReference"
}
]
}BR-DE-15 · alle Regeln. XML wird nicht gespeichert.
PHP- und TypeScript-Client
composer require normbill/xrechnung
npm i @normbill/xrechnungComposer-Client: XRechnung PHP. MCP: @normbill/mcp. Generate, Validate, Parse. Dieselbe Oberfläche wie REST.
Für Product Teams, nicht für Einzelrechnungen
Ein Key, viele Mandanten. metadata für Ihre Tenant-ID. Die API antwortet synchron, Ihre User sehen normbill nicht.
XRechnung für B2G und Leitweg-ID. ZUGFeRD API für B2B, wenn der Empfänger ein PDF braucht. Peppol BIS erzeugen (Transport ist Roadmap). Parse für die Empfangspflicht seit Jan 2025.
Bibliothek statt API? OSS-Bibliothek vs. API für XRechnung.
Preise ohne Vertriebsanruf
Free: 50/Monat, KoSIT, Test- und Live-Keys, keine Karte. Paid ab €19. 30-Tage-Garantie. Design-Partner: 12 Monate Growth.
FAQ
Ist das XRechnung 3.0 / EN 16931?
Ja. Offizieller KoSIT-Schematron. Inhaltliche Compliance hängt an den Daten, die Sie schicken.
XRechnung oder ZUGFeRD?
Reines XML vs. Hybrid-PDF. Beide erfüllen die Pflicht bei EN-16931-Profil (nicht MINIMUM/BASIC-WL). Dieselbe JSON-Payload, anderes format. XRechnung vs ZUGFeRD · ZUGFeRD API.
Brauche ich Java, Mustangproject oder horstoeko?
Nein. Libraries, wenn Sie XML selbst besitzen wollen. HTTP, wenn Ihr Produkt Rechnungen für Mandanten ausstellt.
Speichert ihr Rechnungsdaten?
Kann ich fremde XRechnungen prüfen?
POST /v1/invoices/validate oder /de/validator ohne Key.