Leitfäden
Leitfäden für Entwickler
Praxisnahe, technische Leitfäden zur deutschen E-Rechnungspflicht: Formate, Validierung und die Entscheidungen, vor denen Teams wirklich stehen.
- KoSIT-Fehlermeldungen lesen und beheben
Was KoSIT-Meldungen bedeuten (BR-DE, BR-CO, BR-DEC, Codelisten), wie ein Schematron-Report aufgebaut ist — und wie Sie die acht häufigsten XRechnung-Fehler beheben.
Aktualisiert am
- E-Rechnung 2027 — Checkliste für Entwickler
Was Produkt- und Engineering-Teams vor der B2B-E-Rechnungspflicht klären sollten: Formate, Empfang, KoSIT, Leitweg-ID, Bibliothek vs. API.
Aktualisiert am
- Leitweg-ID für Entwickler — BT-10 / buyer_reference
Leitweg-ID (BT-10) in XRechnung: Format, BR-DE-15, und wie Sie invoice.buyer_reference in normbill setzen. Mit Live-Formatcheck.
Aktualisiert am
- Storno & Gutschrift in XRechnung: 384 oder 381?
Storno: type_code 384, preceding_invoice, negative Mengen. 381 über CII (XRechnung CII, ZUGFeRD, Factur-X); eine UBL-Invoice lehnt 381 ab. Self-Billing: 389.
Aktualisiert am
- XRechnung: OSS-Bibliothek vs. API im Vergleich
horstoeko und Mustangproject erzeugen XML. normbill prüft zusätzlich gegen KoSIT und ordnet jeden Fehler Ihrem JSON zu. Wann eine Bibliothek reicht.
Aktualisiert am
- E-Rechnung im SaaS: Build vs. Buy
OSS-Bibliothek, E-Rechnungs-API oder Komplettanbieter? Entscheidungsrahmen für SaaS-Teams vor der E-Rechnungspflicht: Kosten, Risiken, Empfehlung.
Aktualisiert am
Sie suchen die Referenz? Die Validierungsregel-Referenz dokumentiert jede EN-16931-/ XRechnung-Regel, die die API melden kann — auf Deutsch und Englisch. Formate: XRechnung vs ZUGFeRD. Die API-Dokumentation (Englisch) beschreibt Endpunkte, Auth und den 422-Validierungsbericht.