ZUGFeRD / XRechnung
MCP Validation Server
MCP-Server zur automatisierten Validierung von E-Rechnungen in den Formaten ZUGFeRD, Factur-X und XRechnung. Gibt strukturierte JSON-Ergebnisse mit konkreten Korrekturvorschlägen zurück.
1. Übersicht
Der Server stellt drei Tools und eine Resource bereit, die von KI-Agenten über das Model Context Protocol aufgerufen werden können.
| Szenario | Tool / Resource |
|---|---|
| Rechnung vor dem Versand prüfen | validate_invoice |
| XML-Daten aus ZUGFeRD-PDF lesen | extract_xml |
| Prüfen ob PDF und XML übereinstimmen | check_consistency |
| Verfügbare Formate und Regelsets abfragen | validation://rules |
2. Architektur & Datenfluss
Ablauf für validate_invoice
3. Validierungsengines
Jede Anfrage wird von zwei Engines gleichzeitig geprüft. Die Ergebnisse werden konsolidiert und dedupliziert zurückgegeben.
| Engine | Version | Abgedeckte Formate |
|---|---|---|
| Mustang Project | v2.22.0 | ZUGFeRD 1.0–2.4, Factur-X 1.0, XRechnung (allgemein) |
| KoSIT Validierungstool | v1.6.2 | XRechnung 3.0.2 (CII + UBL), EN 16931 CII/UBL (plain), Factur-X 1.07.3 / 1.08 (alle Profile) |
errors-Liste. Duplikate (gleiche Regel-ID + Meldung) werden automatisch entfernt. KoSIT-Fehler fließen nur ein, wenn ein passendes Validierungsszenario erkannt wurde — bei unbekannten GuidelineIDs übernimmt Mustang allein.
4. Installation & Konfiguration
# Kostenlos registrieren:
https://zugferd-validator.de/portal.html
npm install -g zugferd-mcp-client
// mcp_config.json (je nach Client abweichender Pfad) { "mcpServers": { "zugferd": { "command": "zugferd-mcp-client", "env": { "ZUGFERD_API_KEY": "zv_dein_key_hier" } } } }
Direkte REST API
Die API kann auch direkt ohne MCP-Client angesprochen werden:
# Beispiel: Validierung per curl curl -X POST https://api.zugferd-validator.de/v1/validate \ -H "Content-Type: application/json" \ -H "X-Api-Key: zv_dein_key_hier" \ -d '{"file_content":"<base64>","file_type":"xml"}'
Umgebungsvariablen (MCP-Client)
| Variable | Beschreibung | Standard |
|---|---|---|
ZUGFERD_API_KEY | API-Key vom Portal | – (Pflicht) |
ZUGFERD_API_URL | API-Basis-URL | https://api.zugferd-validator.de |
5. Tools
Validiert eine E-Rechnung (ZUGFeRD/Factur-X PDF oder XRechnung XML) gegen EN 16931 und die deutschen Erweiterungen. Gibt strukturierte Fehler, Warnungen und Korrekturvorschläge zurück.
Input-Schema
data:application/pdf;base64,…) werden automatisch entfernt.
"pdf" für ZUGFeRD/Factur-X-PDFs · "xml" für reine XRechnung/CII-XML-Dateien
rule_id: "PROFILE_MISMATCH" erzeugt.Werte:
minimum · basic_wl · basic · en16931 · extended · xrechnung
Output-Schema
{
"valid": true,
"format": "ZUGFeRD 2.x",
"profile": "EN16931",
"summary": "Keine Probleme gefunden",
"errors": [],
"warnings": [],
"notices": [],
"metadata": {
"invoice_number": "RE-2026-001",
"issue_date": "2026-04-01",
"seller": "Musterfirma GmbH",
"buyer": "Beispiel AG",
"total_amount": "1190.00",
"currency": "EUR"
}
}
{
"valid": false,
"format": "ZUGFeRD 2.x",
"profile": "EN16931",
"summary": "2 Fehler, 1 Warnung gefunden",
"errors": [
{
"severity": "error",
"rule_id": "BR-DE-1",
"field": "BT-31 / BT-32",
"message": "Die USt-ID (BT-31) oder Steuernummer (BT-32) muss angegeben werden.",
"fix_suggestion": "Füge 'ram:SpecifiedTaxRegistration' mit schemeID='VA' und USt-ID hinzu.",
"xpath": "//ram:SellerTradeParty/ram:SpecifiedTaxRegistration"
}
],
"warnings": [
{
"severity": "warning",
"rule_id": "BR-CL-10",
"field": "BT-81",
"message": "Zahlungsmittelcode muss aus UNTDID 4461 stammen.",
"fix_suggestion": "Verwende z.B. '58' für SEPA-Überweisung oder '59' für SEPA-Lastschrift.",
"xpath": "//ram:SpecifiedTradeSettlementPaymentMeans/ram:TypeCode"
}
]
}
Ausgabefelder
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
valid | boolean | Ja | true wenn kein einziger Fehler gefunden wurde |
format | string | Nein | Erkanntes Format, z.B. "ZUGFeRD 2.x", "CII EN16931", "XRechnung 3.0" — null wenn kein XML extrahierbar |
profile | string | Nein | Erkanntes Profil in Großbuchstaben, z.B. "EN16931", "XRECHNUNG" — null wenn kein XML extrahierbar |
summary | string | Ja | Lesbare Zusammenfassung, z.B. "2 Fehler, 1 Warnung gefunden" |
errors | array | Ja | Validierungsfehler — machen die Rechnung ungültig |
warnings | array | Ja | Warnungen — Rechnung kann trotzdem gültig sein |
notices | array | Nein | Informative Hinweise ohne Einfluss auf die Gültigkeit |
metadata | object | Nein | Extrahierte Rechnungsdaten — bei PDFs vorhanden wenn eingebettetes XML erfolgreich gelesen wurde, bei file_type: "xml" immer |
Extrahiert das eingebettete XML-Dokument aus einer ZUGFeRD/Factur-X-PDF. Gibt den vollständigen XML-Inhalt als String zurück, zusammen mit erkanntem Format und Profil.
Input
Output
{
"xml_content": "<?xml version='1.0' encoding='UTF-8'?>\n<rsm:CrossIndustryInvoice ...>...</rsm:CrossIndustryInvoice>",
"format": "ZUGFeRD 2.x",
"profile": "EN16931"
}
xml_content kann direkt (nach Base64-Kodierung) an validate_invoice mit file_type: "xml" weitergegeben werden.Prüft, ob die für Menschen sichtbaren Daten im PDF (Rechnungsnummer, Datum, Gesamtbetrag) mit den im XML-Anhang gespeicherten Maschinendaten übereinstimmen. Deckt Manipulationen oder Erfassungsfehler auf.
Input
Output
{
"consistent": true,
"discrepancies": []
}
{
"consistent": false,
"discrepancies": [
{
"field": "total_amount",
"pdf_value": "1190.00",
"xml_value": "1180.00",
"message": "Gesamtbetrag im PDF ('1190.00') unterscheidet sich von dem im XML ('1180.00')."
}
]
}
Geprüfte Felder & Toleranzen
| Feld | Erkennungsmuster im PDF | Toleranz |
|---|---|---|
invoice_number | Rechnungsnummer:, Rechnung Nr., Invoice No. | Groß-/Kleinschreibung, Leerzeichen, Bindestriche ignoriert |
issue_date | Rechnungsdatum:, Datum:, Invoice Date: | Keiner — Datumformate werden auf ISO 8601 normiert |
total_amount | Gesamtbetrag:, Rechnungsbetrag:, Total: | ±0,01 EUR (Rundungsdifferenzen) |
6. Resource: validation_rules
Gibt das aktuelle Regelwerk des Servers zurück: unterstützte Formate, Profile und die verwendete Validierungsengine.
URI: validation://rules
{
"supported_formats": [
"ZUGFeRD 1.0", "ZUGFeRD 2.0", "ZUGFeRD 2.1", "ZUGFeRD 2.2",
"ZUGFeRD 2.3", "ZUGFeRD 2.x / Factur-X 1.0x",
"XRechnung 1.2", "XRechnung 2.0", "XRechnung 2.3", "XRechnung 3.0"
],
"supported_profiles": [
"minimum", "basic_wl", "basic", "en16931", "extended", "xrechnung"
],
"validation_engines": [
"Mustang Project v2.22.0",
"KoSIT Validierungstool v1.6.2 (XRechnung 3.0.2 + EN 16931 CII)"
],
"last_updated": "2026-04-08"
}
7. Fehlerbehandlung
Alle Tools geben bei Fehlern ein JSON-Objekt mit einem error-Feld zurück. Es gibt niemals eine unstrukturierte Fehlerausgabe.
{
"error": "Kurze Fehlerkategorie",
"details": "Ausführliche Beschreibung mit konkretem Hinweis zur Behebung."
}
| error | Auslöser |
|---|---|
"Fehlender Parameter" | Pflichtfeld nicht übergeben |
"Ungültiger Parameter" | Falscher Wert für file_type |
"Ungültiger Base64-Input" | Kein gültiger Base64-String übergeben |
"Validierungsfehler" | Mustang CLI konnte nicht starten (z.B. Java fehlt) oder Timeout nach 30s |
"XML-Extraktion fehlgeschlagen" | Keine XML-Datei im PDF-Anhang gefunden (bei extract / consistency). Bei validate wird stattdessen ein Notice mit rule_id: "NO_EMBEDDED_XML" zurückgegeben und valid: true gesetzt |
"PDF-Lesefehler" | PDF kann nicht gelesen werden |
"XML-Parsing-Fehler" | Extrahiertes XML ist kein valides XML |
"Interner Fehler" | Unerwarteter Laufzeitfehler |
"error": "Validierungsfehler" zurückgegeben. Ein KoSIT-Timeout wird still ignoriert — Mustang-Ergebnisse bleiben erhalten.8. Gemeinsame Datentypen
ValidationIssue
Wird in den Arrays errors, warnings und notices von validate_invoice verwendet.
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
severity | "error" | "warning" | "notice" | Ja | Schweregrad des Befundes |
rule_id | string | Ja | Regel-ID, z.B. "BR-DE-1", "BR-CL-10". Wert "UNKNOWN" bei XSD-Schema-Verletzungen (KoSIT) oder wenn keine Regel-ID ermittelbar ist |
field | string | Nein | Betroffenes BT-Feld, z.B. "BT-31 / BT-32" |
message | string | Ja | Fehlermeldung auf Deutsch |
fix_suggestion | string | Nein | Konkreter Korrekturhinweis mit XML-Beispiel |
xpath | string | Nein | XPath zum betroffenen XML-Element |
InvoiceMetadata
Optionales Feld im Ergebnis von validate_invoice (nur bei file_type: "xml").
| Feld | Typ | Beschreibung |
|---|---|---|
invoice_number | string? | Rechnungsnummer (BT-1) |
issue_date | string? | Rechnungsdatum ISO 8601, z.B. "2026-04-01" |
seller | string? | Name des Verkäufers (BT-27) |
buyer | string? | Name des Käufers (BT-44) |
total_amount | string? | Gesamtbetrag als Dezimalstring, z.B. "1190.00" |
currency | string? | ISO 4217 Währungscode, z.B. "EUR" |
9. Unterstützte Formate & Profile
Formate
| Format | Standard | Anmerkung |
|---|---|---|
| ZUGFeRD 1.0 | ZUGFeRD 1.0 / GEFEG | Ältere Version, eingeschränkte Profilunterstützung |
| ZUGFeRD 2.0 | FeRD 2.0 | Erste CII-basierte Version |
| ZUGFeRD 2.1 | Factur-X 1.0 (FR) | Technisch identisch mit Factur-X 1.0 |
| ZUGFeRD 2.2 | Factur-X 1.0.05 | Kleinere Korrekturen |
| ZUGFeRD 2.3 | Factur-X 1.0.06 | Version vor 2.4 |
| ZUGFeRD 2.x / Factur-X 1.0x | EN 16931 + D16B | Aktuelle Hauptversion (2026) — API gibt "ZUGFeRD 2.x" zurück |
| XRechnung 1.2 | XRechnung 1.2 | Ältere XRechnung-Version |
| XRechnung 2.x | XRechnung 2.0–2.3 | Verschiedene Zwischenversionen |
| XRechnung 3.0 | XRechnung 3.0 | Aktuelle XRechnung-Version |
Profile (ZUGFeRD/Factur-X)
| Profil-ID | Anzeigename | Typischer Einsatz |
|---|---|---|
minimum | MINIMUM | Einfache maschinelle Verarbeitung |
basic_wl | BASIC-WL | Ohne Positionsdetails |
basic | BASIC | Standard-Rechnungen |
en16931 | EN 16931 (COMFORT) | Öffentliche Auftraggeber, PEPPOL |
extended | EXTENDED | Komplexe B2B-Prozesse |
xrechnung | XRECHNUNG | Deutsche öffentliche Verwaltung |
10. Regelwerk & Korrekturvorschläge
Der Server enthält eine Datenbank mit Korrekturvorschlägen für 48 Regelkategorien. Fehler beider Validierungsengines (Mustang + KoSIT) werden konsolidiert — wenn eine bekannte Regel-ID gefunden wird, wird der Korrekturvorschlag automatisch angehängt.
BR-DE-Regeln 26 Regeln
Deutsche Erweiterungen — Pflicht für XRechnung-konforme Rechnungen.
| Regel-ID | Feld | Kurzbeschreibung |
|---|---|---|
BR-DE-1 | BT-31 / BT-32 | USt-ID oder Steuernummer des Verkäufers |
BR-DE-2 | BT-35 | Straße des Verkäufers |
BR-DE-3 | BT-37 | Stadt des Verkäufers |
BR-DE-4 | BT-38 | PLZ des Verkäufers |
BR-DE-5 | BT-40 | Land des Verkäufers |
BR-DE-6 | BT-50 | Straße des Käufers |
BR-DE-7 | BT-52 | Stadt des Käufers |
BR-DE-8 | BT-53 | PLZ des Käufers |
BR-DE-9 | BT-55 | Land des Käufers |
BR-DE-10 | BT-81 | Zahlungsmitteltyp-Code |
BR-DE-11 | BT-84 | IBAN des Zahlungskontos |
BR-DE-12 | BT-86 | BIC des Zahlungsdienstleisters |
BR-DE-13 | BT-20 | Zahlungsbedingung als Freitext |
BR-DE-14 | BT-22 | Rechnungsanmerkung nicht leer |
BR-DE-15 | BT-7 | Steuerdatum wenn abweichend |
BR-DE-16 | BT-6 | Steuerkurs-Code |
BR-DE-17 | BT-92 | Nachlass-Grund auf Belegebene |
BR-DE-18 | BT-98 | Abschlags-Grund auf Belegebene |
BR-DE-19 | BT-132 | Nachlass-Grund auf Positionsebene |
BR-DE-20 | BT-140 | Abschlags-Grund auf Positionsebene |
BR-DE-21 | BT-23 | Prozessart |
BR-DE-22 | BT-24 | Spezifikationskennung |
BR-DE-23 | BT-10 | Käuferreferenz / Leitweg-ID |
BR-DE-24 | BT-48 | USt-ID oder Steuer-ID des Käufers |
BR-DE-25 | BT-131 | Nettobetrag der Position positiv |
BR-DE-26 | BT-129 | Abgerechnete Menge > 0 |
EN-16931-Kernregeln (BR-*) 10 Regeln
| Regel-ID | Feld | Kurzbeschreibung |
|---|---|---|
BR-1 | BT-1 | Rechnungsnummer |
BR-2 | BT-2 | Rechnungsdatum |
BR-3 | BT-3 | Rechnungstyp-Code |
BR-4 | BT-5 | Währungsangabe |
BR-5 | BT-27 | Name des Verkäufers |
BR-6 | BT-44 | Name des Käufers |
BR-7 | BT-22 | Rechnungsanmerkung nicht leer |
BR-8 | BT-19 | Bestellreferenz mit Inhalt |
BR-9 | BT-14 | Vertragsnummer mit Inhalt |
BR-10 | BT-13 | Bestellnummer mit Inhalt |
Berechnungsregeln (BR-CO-*) & Codelistenregeln (BR-CL-*) 8 Regeln
| Regel-ID | Kurzbeschreibung |
|---|---|
BR-CO-3 | Gesamtbetrag korrekt berechnet |
BR-CO-9 | Nettobetrag korrekt berechnet |
BR-CO-10 | Gesamtsteuer korrekt berechnet |
BR-CO-13 | Summe der Positionsnettobeträge korrekt |
BR-CL-10 | Zahlungsmittelcode aus UNTDID 4461 |
BR-CL-16 | Steuerbefreiungscode aus VATEX-Liste |
BR-CL-17 | Steuercode aus UNCL5305 (S, Z, E, AE, K) |
BR-CL-18 | Maßeinheitencode aus UN/ECE Rec. 20 |
Steuerkategorieregeln (BR-S/Z/E/AE-*) 4 Regeln
| Regel-ID | Kurzbeschreibung |
|---|---|
BR-S-1 | Steuerbetrag bei Normalsatz (S) angegeben |
BR-Z-1 | Steuerbetrag bei Nullsatz (Z) = 0 |
BR-E-1 | Steuerbetrag bei Steuerbefreiung (E) = 0 |
BR-AE-1 | Steuerbetrag bei Reverse Charge (AE) = 0 |
11. Nutzungsbeispiele
Beispiel 1: XRechnung-XML validieren
{
"tool": "validate_invoice",
"arguments": {
"file_content": "PD94bWwgdmVyc2lvbj0iMS4wIj8+...",
"file_type": "xml",
"profile": "xrechnung"
}
}
{
"valid": true,
"format": "XRechnung 3.0",
"profile": "XRECHNUNG",
"summary": "Keine Probleme gefunden",
"errors": [],
"warnings": [],
"metadata": {
"invoice_number": "INV-2026-0042",
"issue_date": "2026-04-07",
"seller": "Tech GmbH",
"buyer": "Bundesbehörde X",
"total_amount": "5950.00",
"currency": "EUR"
}
}
Beispiel 2: Fehlerhafte Rechnung mit Korrekturvorschlag
{
"tool": "validate_invoice",
"arguments": {
"file_content": "JVBERi0xLjQK...",
"file_type": "pdf"
}
}
{
"valid": false,
"format": "ZUGFeRD 2.x",
"profile": "EN16931",
"summary": "1 Fehler gefunden",
"errors": [{
"severity": "error",
"rule_id": "BR-DE-23",
"field": "BT-10",
"message": "Käuferreferenz (BT-10) muss für XRechnung angegeben werden.",
"fix_suggestion": "Füge 'ram:BuyerReference' hinzu, z.B. '04011000-1234-34' für Behörden.",
"xpath": "//ram:ApplicableHeaderTradeAgreement/ram:BuyerReference"
}],
"warnings": []
}
Beispiel 3: XML extrahieren und validieren
// Schritt 1 — XML aus PDF extrahieren { "tool": "extract_xml", "arguments": { "pdf_content": "JVBERi0x..." } } // Schritt 2 — Extrahiertes XML validieren (base64-kodiert übergeben) { "tool": "validate_invoice", "arguments": { "file_content": "<base64 des xml_content>", "file_type": "xml" } }
Beispiel 4: Konsistenzprüfung
{
"tool": "check_consistency",
"arguments": { "pdf_content": "JVBERi0xLjQK..." }
}
{
"consistent": false,
"discrepancies": [{
"field": "total_amount",
"pdf_value": "1190.00",
"xml_value": "1180.00",
"message": "Gesamtbetrag im PDF ('1190.00') unterscheidet sich von dem im XML ('1180.00')."
}]
}
Beispiel 3: Plain-PDF ohne eingebettetes XML
Eine normale PDF-Rechnung ohne ZUGFeRD/Factur-X-Anhang gibt valid: true mit einem informativen Notice zurück — kein Fehler, aber ein Hinweis dass keine strukturierten Daten geprüft werden konnten.
{
"tool": "validate_invoice",
"arguments": {
"file_content": "JVBERi0xLjQK...",
"file_type": "pdf"
}
}
{
"valid": true,
"format": null,
"profile": null,
"summary": "2 Hinweise gefunden",
"errors": [],
"warnings": [],
"notices": [
{
"severity": "notice",
"rule_id": "UNKNOWN",
"message": "XML could not be extracted"
},
{
"severity": "notice",
"rule_id": "NO_EMBEDDED_XML",
"message": "Kein eingebettetes XML gefunden. Die PDF ist möglicherweise keine ZUGFeRD/Factur-X Rechnung."
}
]
}
12. Grenzen & Bekannte Einschränkungen
| Einschränkung | Details |
|---|---|
| Timeout | Mustang CLI wird serverseitig nach 30 Sekunden abgebrochen. Sehr große oder korrupte Dateien können diesen Timeout auslösen. |
| Rate-Limit | Free: 20 Anfragen/Tag · Pro: 500/Tag · Ultra: 5.000/Tag. Bei Überschreitung: HTTP 429. |
| PDF-OCR | check_consistency wertet nur maschinenlesbaren PDF-Text aus. Eingescannte PDFs ohne OCR-Schicht werden nicht unterstützt. |
| Metadaten bei PDFs | validate_invoice extrahiert Metadaten auch bei PDFs, sofern ein eingebettetes XML vorhanden und lesbar ist. Bei Plain-PDFs ohne XML fehlt dieses Feld. |
| Konsistenzprüfung | Nur drei Felder werden verglichen (Nummer, Datum, Betrag). Adressen, Steuernummern und Positionsdetails werden nicht abgeglichen. |
| Unbekannte Regel-IDs | Fehlt eine Regel-ID in der Fix-Suggestions-DB, bleibt fix_suggestion leer. Die Meldung wird trotzdem zurückgegeben. |
| Dateigröße | Keine explizite Größenbeschränkung, aber sehr große PDFs (>50 MB) können zum Timeout führen. |