XRechnung for your software — with one API call.

The output conforms to EN 16931, the European standard the German mandate is based on. XRechnung documents follow the current KoSIT specification and are validated against the official KoSIT Schematron before you get them back; ZUGFeRD output is valid Factur-X with structural EN 16931 checks. Compliance of the content (correct VAT treatment, mandatory references for your buyer) still depends on the data you send — which is exactly what the validation report tells you about.

XRechnung is pure XML — required for invoicing German public authorities (B2G) and common in B2B. ZUGFeRD / Factur-X is a normal PDF with the same structured XML embedded, so humans and machines both read it. Both satisfy the mandate; many teams send ZUGFeRD to businesses and XRechnung to government. The API generates either from the same JSON.

No. Invoices are processed in memory and returned; nothing is persisted, and request bodies are excluded from our logs. EU-hosted infrastructure, GDPR-first — there is no retention setting to configure because there is nothing retained.

Yes — POST XRechnung (UBL or CII) to /v1/invoices/validate for authoritative KoSIT validation; ZUGFeRD / Factur-X CII is checked at the structural EN 16931 tier today. Either way you get a machine-readable report: every failed rule with its ID, severity, a plain-language message and a suggested fix. Or try the free validator with no key. Validation is free within a generous fair-use allowance — five times your plan's monthly document quota — and never counts against your billable documents.

That's the core use case. One API key, and a free-form metadata object on every invoice for your own per-tenant correlation. The API responds synchronously — your users never see normbill, they just get compliant invoices out of your product. At platform volume, the Platform tier adds dedicated support, an EU data-residency guarantee and pay-by-invoice billing on request (SEPA, net-30).

The API generates Peppol BIS Billing 3.0 UBL today, so your documents are network-ready. Transmission over the Peppol network (via a certified access point) is on the roadmap — generation and validation come first, because that's the part every team needs on day one.

You get a 422 with field-level errors: the rule that fired, the path in your JSON that caused it, a plain-language message, and a suggested fix. The API never silently returns an invalid document.

Only successful documents count against your quota — failed attempts cost nothing, and validation has its own generous free allowance. The quota runs with your billing period; on annual plans twelve months' worth of documents pool across the contract year. From 80% usage every response carries an X-Quota-Warning header, so nothing surprises you. On paid plans with metered overage active on your subscription, extra documents are billed at the per-document rate shown on your tariff (capped at 2× the plan fee); otherwise calls stop at the quota with a clear 429 instead of being billed. The Free plan always returns a 429 with an upgrade link. sk_test_ keys are never billed.

Email support@normbill.com — for support, questions about the docs, or anything this FAQ doesn't cover. A practical getting-started guide lives in the public docs.

You can, and for pure generation they work. What you take on is running and updating the KoSIT validator, following rule and specification releases, and turning Schematron findings into something your users can act on. normbill is that part as a service: the same JSON in, a validated document or a field-level report out. If your team already has that knowledge in-house, a library may be all you need.

Not as a separate export — the e-invoice itself is what DATEV takes in. DATEV states that its Rechnungseingangspostfach receives every e-invoice format that conforms to EN 16931, and that all of its existing Datenservices can already transport ZUGFeRD and XRechnung files — with differences, DATEV notes, in how each service processes the data. The file normbill returns is such a document; which DATEV channel carries it is an integration decision in your product. What normbill does not produce is booking data: per DATEV, complete Buchungssätze go through its Buchungsdatenservice and need accounts and contra-accounts (Konto und Gegenkonto) — data your product holds and an invoice does not carry.

normbill generates, validates and parses documents. It does not deliver over the Peppol network or archive invoices (GoBD), and it covers EN 16931-based formats only. Official KoSIT validation applies to XRechnung (UBL and CII); ZUGFeRD / Factur-X and Peppol BIS are checked at the structural EN 16931 tier. Cancellations use type 384 with negative quantities; commercial credit notes without a preceding invoice (type 381) are available in the CII formats, not yet as a UBL CreditNote — see the guide on cancellations, corrections and credit notes. If one of these is a must-have for your rollout, tell us before you build.

We do. The KoSIT validator and its XRechnung configuration are pinned to exact versions, and a new specification version gets its own format id next to the existing one instead of silently replacing the one you integrated against. Changes are announced in the changelog.

Paid plans include email support for questions about the API; the Free plan has community support. For hands-on help there is the optional Integration Launch package (€990 one-time, excl. VAT): one workflow, a documented data mapping, a working reference integration and 2 sessions. It is never required.

Your integration produces standard documents — XRechnung, ZUGFeRD / Factur-X — that stay valid and readable without us, and we never hold your invoices, so there is nothing to migrate out. The invoice JSON follows the EN 16931 business terms, so moving to a library or another provider is a mapping exercise, not a data rescue. normbill is operated by VIBOA UG (haftungsbeschränkt).