Validierungs-API
Der gleiche Schematron-Validator, der hinter unserem Web-Validator läuft, als REST-Endpoint. Prüft XRechnung (CII und UBL) sowie ZUGFeRD/Factur-X gegen EN 16931 und die deutschen CIUS-Regeln. Kein API-Key, kein Account, CORS offen.
Endpoint
Die Datei geht entweder als multipart/form-data im Feld file rein oder als roher Request-Body mit passendem Content-Type. Hochgeladene Dateien werden nach der Antwort sofort verworfen und nicht gespeichert.
Beispiele
XML als Multipart
curl -X POST https://belegschmied.de/api/public/validate \
-F "file=@rechnung.xml"XML als roher Body
curl -X POST https://belegschmied.de/api/public/validate \
-H "Content-Type: application/xml" \
--data-binary @rechnung.xmlZUGFeRD-PDF
curl -X POST https://belegschmied.de/api/public/validate \
-H "Content-Type: application/pdf" \
--data-binary @rechnung-zugferd.pdfJavaScript
const res = await fetch('https://belegschmied.de/api/public/validate', {
method: 'POST',
headers: { 'Content-Type': 'application/xml' },
body: xmlString,
})
const report = await res.json()
if (!report.valid) {
console.error('Verletzte Regeln:', report.ruleCodes.join(', '))
}Python
import requests
with open("rechnung.xml", "rb") as f:
r = requests.post(
"https://belegschmied.de/api/public/validate",
files={"file": f},
timeout=60,
)
report = r.json()
print(report["valid"], report["ruleCodes"])Antwort
{
"valid": false,
"format": "xrechnung",
"issues": [
{
"severity": "ERROR",
"message": "[BR-CO-15] Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).",
"location": "/ubl:Invoice[1]/cac:LegalMonetaryTotal[1]",
"criterion": "BR-CO-15",
"section": "4"
}
],
"ruleCodes": ["BR-CO-15"]
}| Feld | Typ | Bedeutung |
|---|---|---|
| valid | boolean | true, wenn die Datei Schema und alle Schematron-Regeln erfüllt hat. |
| format | string | Erkanntes Format, normalisiert auf xrechnung, zugferd, en16931, ubl, cii, other oder unknown. |
| issues[] | array | Alle Fehler und Warnungen. NOTICE-Einträge werden vorher herausgefiltert. |
| issues[].severity | string | ERROR, FATAL, EXCEPTION oder WARNING. |
| issues[].message | string | Meldungstext aus dem KoSIT-Regelwerk, meist inklusive Regel-Code. |
| issues[].location | string | null | XPath auf das beanstandete Element, sofern der Validator einen liefert. |
| issues[].criterion | string | null | Regel-Kriterium des Schematron-Asserts. |
| issues[].section | string | null | Abschnitt des Regelwerks. |
| ruleCodes[] | string[] | Deduplizierte Liste der verletzten Regel-Codes, etwa BR-CO-15 oder BR-DE-18. Praktisch, wenn du nur auf bestimmte Regeln reagieren willst. |
Mit ?raw=1 kommt zusätzlich das vollständige XML-Validierungsprotokoll als rawReport mit. Das ist deutlich größer, aber nützlich, wenn du den Bericht als Nachweis archivieren willst — das BMF-Schreiben vom 15. Oktober 2025 empfiehlt genau das für eingehende Rechnungen.
Fehlercodes
Jede Antwort trägt X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset als Header.
Grenzen und Fairness
Die API ist für Entwicklung, Tests und gelegentliche Prüfungen gedacht, nicht als Produktions-Backend für fremde Massenverarbeitung. 100 Requests pro Tag und IP sind hart limitiert. Wenn du mehr brauchst oder eine Zusage zur Verfügbarkeit möchtest, schreib uns an kontakt@belegschmied.de — das ist unkompliziert und kostet in aller Regel nichts.
Die Prüfung ist rein formal: Schema, EN-16931-Geschäftsregeln und deutsche CIUS-Regeln. Ob Beträge, Adressen oder Leistungsbeschreibungen inhaltlich stimmen, kann kein Validator beurteilen.
Validierung im laufenden Betrieb
Wer nicht selbst integrieren will: In Belegschmied läuft die Validierung automatisch bei jeder ein- und ausgehenden Rechnung mit. Der Bericht landet im GoBD-Archiv, fehlerhafte ausgehende Rechnungen werden vor dem Versand gestoppt.