XRechnung 3.0
XRechnung API. JSON in, valid XML out.
XRechnung 3.0 (UBL or CII) from JSON. Before you see the XML, it has gone through the official KoSIT validator. If a rule fails, you do not get a [BR-DE-15] code — you get invoice.buyer_reference and the fix.
For product teams embedding e-invoicing in a SaaS. Not for one-off invoices.
Get API key (free, 50 documents/month)Validate XRechnung, no key
JSON in, XRechnung 3.0 out
One endpoint. The same payload for UBL and 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" or "xrechnung-cii-3.0". The API computes totals, EUR and the payment means code when they are missing.
Official KoSIT validator. No silent XML.
Three tiers: structural rules, XSD, KoSIT Schematron (pinned). Invalid does not come back as 200 — it is 422 with a report. Validation, retries and failed calls do not count against the quota.
422 with invoice.buyer_reference, not 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 · all rules. XML is not stored.
PHP and TypeScript clients
composer require normbill/xrechnung
npm i @normbill/xrechnungComposer client: XRechnung PHP. MCP: @normbill/mcp. Generate, Validate, Parse. The same surface as REST.
For product teams, not one-off invoices
One key, many tenants. metadata for your tenant id. The API answers synchronously; your users never see normbill.
XRechnung for B2G and Leitweg-ID. ZUGFeRD API for B2B when the recipient needs a PDF. Peppol BIS generation (transport is roadmap). Parse for the receiving mandate since Jan 2025.
Library instead of an API? OSS library vs API for XRechnung.
Pricing with no sales call
Free: 50/month, KoSIT, test and live keys, no card. Paid from €19. 30-day guarantee. Design partners: 12 months of Growth.
FAQ
Is this XRechnung 3.0 / EN 16931?
Yes. Official KoSIT Schematron. Substantive compliance depends on the data you send.
XRechnung or ZUGFeRD?
Pure XML vs hybrid PDF. Both meet the mandate at an EN 16931 profile (not MINIMUM/BASIC-WL). Same JSON payload, different format. XRechnung vs ZUGFeRD · ZUGFeRD API.
Do I need Java, Mustangproject or horstoeko?
No. Libraries if you want to own the XML yourself. HTTP if your product issues invoices for tenants.
Do you store invoice data?
Can I check someone else's XRechnung?
POST /v1/invoices/validate or /validator without a key.