Erzeugen
Rechnungsdaten als JSON senden, valide XRechnung (UBL oder CII) oder ZUGFeRD zurückbekommen — konform zur EN 16931.
Empfangspflicht seit 1. Januar 2025
XRechnung und ZUGFeRD per API, die beim ersten Versuch durchgehen
Prüfen Sie eine Rechnung direkt hier gegen das offizielle KoSIT-Regelwerk — kostenlos, ohne Anmeldung, jeder Fehler im Klartext. Für Software-Teams: eine REST-API, die aus JSON valide XRechnung (UBL und CII) und ZUGFeRD erzeugt und die Regeländerungen übernimmt.
Kostenlos starten ohne Kreditkarte: Prüfen zählt nie mit, 25 erzeugte Rechnungen pro Monat.
Prüfprotokoll
Anfrage
$ curl -X POST api.normapi.de/v1/validate \
-H 'Content-Type: application/xml' \
--data-binary @rechnung.xmlAntwort
"acceptable": false
BR-CO-16Zahlbetrag geht rechnerisch nicht auf
Erzeugen
$ curl -X POST api.normapi.de/v1/invoices \
-H 'Content-Type: application/json' \
--data-binary @rechnungsdaten.json \
-o rechnung.xml200 rechnung.xml geprüft, bevor sie die API verlässt
Regelwerkv2026-08-31
Rechnung prüfen
Oder XML einfügen
XML oder PDF, bis 5 MB — Datei auch einfach hierher ziehen. Ohne Anmeldung, ohne Kontingent.
Ihre Datei wird nur im Arbeitsspeicher geprüft und danach verworfen. Wir speichern keine Rechnungsinhalte.
Keine Rechnung zur Hand?
Ein Klick prüft die Datei hier — Download optional.
- GültigGültige Rechnung (UBL)
Besteht die Prüfung ohne Fehler. Guter Startpunkt für ein eigenes Mapping.
Datei ↓ - GültigGültige Rechnung (CII)
Dieselbe Rechnung in der zweiten zulässigen Syntax, UN/CEFACT CII.
Datei ↓ - GültigGültige Rechnung (ZUGFeRD-PDF)
Hybrid aus lesbarem PDF und eingebetteter CII-Rechnung — erzeugt von der NormAPI-Generierung, geprüft wie alle Beispiele.
Datei ↓ - BR-DE-15Käuferreferenz fehlt
Ohne BT-10 — bei Behördenrechnungen steht dort die Leitweg-ID.
Datei ↓ - BR-DE-2Ansprechpartner fehlt
Die Kontaktgruppe BG-6 fehlt vollständig — der häufigste Mapping-Fehler.
Datei ↓ - BR-CO-16Zahlbetrag geht nicht auf
Der Zahlbetrag passt nicht zur Summe — der klassische Rundungsfehler.
Datei ↓ - BR-DE-18Skonto falsch notiert
PROZENT=2 statt PROZENT=2.00 — die Notation begonnen, aber nicht eingehalten.
Datei ↓ - SchemaSchema-Fehler: Rechnungsnummer fehlt
Scheitert am XML-Schema. Die fachlichen Regeln werden gar nicht erst geprüft — eine leere Fehlerliste heißt hier nicht „alles in Ordnung“.
Datei ↓ - Nicht geprüftProfil ohne Prüf-Szenario (Factur-X MINIMUM)
Deklariert MINIMUM, das keine EN-16931-Rechnung ist. Kein Szenario passt, also läuft keine Regel — das Ergebnis ist weder gültig noch ungültig, sondern „nicht geprüft“.
Datei ↓
Die Fristen
Seit 1. Januar muss jedes Unternehmen E-Rechnungen empfangen können.
Unternehmen mit mehr als 800.000 € Vorjahresumsatz müssen E-Rechnungen ausstellen.
Die Pflicht gilt für alle Unternehmen.
Was NormAPI macht
Zwei Endpunkte gegen dasselbe Regelwerk. Versendet wird nichts — kein Peppol-Zugangspunkt, kein Mailversand, keine Archivierung.
Prüfen
Datei hochladen und eine verständliche Fehlerliste erhalten — nicht nur Schematron-Codes.
Regelstände
Jede Antwort nennt die Fassung, gegen die geprüft wurde — im Header X-Normapi-Ruleset. Neue Fassungen ziehen wir nach.
Woher weiß ich, dass die erzeugte Rechnung valide ist?
Weil sie geprüft wird, bevor sie die API verlässt. Jedes erzeugte Dokument läuft durch denselben KoSIT-Validator wie eine hochgeladene Datei — nicht durch eine Nachbildung, sondern durch das Werkzeug der KoSIT gegen die offizielle Konfiguration. Ein 200 heißt, dass es bestanden hat.
Dass das keine Selbstverständlichkeit ist, haben wir gemessen statt behauptet. Beide Datensätze stehen unter CC BY 4.0:
Von elf frei zugänglichen Prüfseiten verarbeiteten drei am Tag der Messung eine XRechnung in UBL überhaupt nicht; drei weitere prüften gegen ein Regelwerk von vor dem 2. September 2026.
Elf Online-Validatoren, dieselbe Rechnung, ein Tag →Zwei unabhängige Implementierungen desselben Regelwerks, dieselben 29 Dokumente: einig bei 22, uneinig bei 7.
Validator-Vergleich: 29 Dokumente, zwei Prüfer →