Guides
Developer guides
Practical, engineering-first guides to the German e-invoicing mandate: formats, validation, and the decisions teams actually face.
- How to read KoSIT validator errors — and fix them fast
What KoSIT validator findings mean (BR-DE, BR-CO, BR-DEC, code lists), how a Schematron report is structured, and how to fix the eight most common XRechnung errors.
Updated on
- E-Invoice 2027 Developer Readiness Checklist
What product and engineering teams should settle before Germany’s B2B e-invoice mandate: formats, receiving, KoSIT validation, Leitweg-ID, library vs API.
Updated on
- Leitweg-ID for developers — BT-10 / buyer_reference
German public-sector Leitweg-ID (BT-10) in XRechnung: format, BR-DE-15, and how to set invoice.buyer_reference in normbill. Includes a live format check.
Updated on
- OSS library vs API for XRechnung — honest comparison
horstoeko and Mustangproject generate XML. normbill generates, KoSIT-validates, and maps every failure back to your JSON. When a library is enough — and when it is not.
Updated on
- E-invoicing build vs buy for SaaS — an honest framework
OSS library, e-invoicing API or full-service provider? A decision framework for SaaS teams facing the German mandate — costs, risks, and when each option wins.
Updated on
Looking for the raw reference instead? The validation rule reference documents every EN 16931 / XRechnung rule the API can report. Formats: XRechnung vs ZUGFeRD. The API documentation covers endpoints, auth and the 422 validation report.