XRechnung validieren: KoSIT-Validator, Schematron-Fehler und was sie bedeuten
Wie der KoSIT-Validator XRechnungen prüft, was Schematron-Fehler bedeuten und wie Sie die Kontrolle automatisieren.
Wie die KoSIT-Visualisierung eine XRechnung in eine lesbare HTML- oder PDF-Ansicht verwandelt, ohne das Original zu ersetzen.

Eine XRechnung ist eine XML-Datei, die kein Mensch direkt lesen soll, und genau das ist der Kern des Problems, wenn ein Sachbearbeiter oder ein Kunde die Rechnung trotzdem einmal ansehen möchte. Die Lösung dafür heißt Visualisierung: eine XSLT-Transformation, die aus der XML-Struktur eine für Menschen lesbare HTML- oder PDF-Ansicht erzeugt, ohne dass sich am rechtlich maßgeblichen XML-Original etwas ändert. Wie das technisch funktioniert und was sich davon automatisieren lässt, zeigt dieser Artikel. Stand: August 2026.
Eine XRechnung enthält reine Geschäftsdaten in einer standardisierten Struktur nach EN16931 und der deutschen CIUS-Erweiterung, aber keinerlei Layout-Information. Öffnen Sie die Datei direkt, sehen Sie verschachtelte XML-Tags statt einer Rechnung mit Kopf-, Positions- und Summenbereich. Damit aus den reinen Daten wieder etwas Lesbares wird, braucht es eine zusätzliche Transformation, die festlegt, welches Feld wo auf der Seite erscheint.
Die KoSIT stellt dafür XSL-Transformatoren bereit, die in zwei Stufen arbeiten. Laut Architekturbeschreibung des Projekts wird im ersten Schritt die XML-Rechnung, egal ob im UBL- oder im CII-Syntax vorliegend, in eine syntaxneutrale Zwischenform überführt, die mit Informationen zu den verwendeten Geschäftsbegriffen der EN16931 angereichert ist. Im zweiten Schritt wird aus dieser Zwischenform eine anwendungsspezifische HTML-Darstellung erzeugt, deren endgültiges Aussehen über CSS-Dateien gesteuert wird, in denen Positionen und Reihenfolge der einzelnen Rechnungsbestandteile festgelegt sind. Diese Bausteine sind laut Projektbeschreibung ausdrücklich als optionale Komponenten für den Einbau in eigene Software gedacht, nicht als fertige Anwendung zum Herunterladen.
Automatisierbar ist vor allem der Schritt von der eingehenden XML-Datei zur HTML- oder PDF-Ansicht: Ein Workflow kann die Zwischentransformation und die zweite Stufe hintereinander ausführen und das Ergebnis direkt an eine E-Mail, ein Ticket oder eine Ablage anhängen, sobald eine neue Rechnung eintrifft. So bekommt zum Beispiel die Buchhaltung automatisch eine lesbare Ansicht neben der Original-XML, ohne dass jemand manuell ein Viewer-Tool öffnen muss. Nicht automatisierbar im Sinne von "einmal einrichten und vergessen" ist dagegen die CSS-Gestaltung selbst, denn Layout-Entscheidungen wie Schriftgröße oder Feldreihenfolge treffen weiterhin Menschen einmalig beim Einrichten der Visualisierung.
Rechtlich maßgeblich bleibt ausschließlich die ursprüngliche XML-Datei, die HTML- oder PDF-Visualisierung ist nur eine Lesehilfe. Für die GoBD-konforme Aufbewahrung archivieren Sie daher die XML-Datei unverändert, eine zusätzlich erzeugte Visualisierung können Sie parallel ablegen, sie ersetzt das Original aber nicht. Wer die visualisierte Fassung stattdessen als einzige Ablage verwendet, verliert im Zweifel die maschinenlesbaren Daten, die für Weiterverarbeitung und Prüfung eigentlich der Zweck der XRechnung sind.
Nein, die Transformation läuft für alle XRechnungen nach demselben Muster, weil sie auf der standardisierten Struktur nach EN16931 aufsetzt. Sie richten die Visualisierung einmal ein und wenden sie danach auf jede eingehende Rechnung an, unabhängig vom jeweiligen Absender.
Beide Syntaxformen laufen durch dieselbe erste Transformationsstufe in die syntaxneutrale Zwischenform, danach ist der weitere Weg zur HTML-Ansicht identisch. Für die Endnutzer im Unternehmen ist der zugrundeliegende XML-Syntax der eingehenden Rechnung damit nicht mehr sichtbar.
Weitgehend ja, denn Kopf-, Positions- und Summenbereich lassen sich über die CSS-Gestaltung so anordnen, dass eine vertraute Rechnungsoptik entsteht. Exakt deckungsgleich mit einer bestimmten firmeneigenen Rechnungsvorlage wird das Ergebnis aber nur, wenn die CSS-Datei entsprechend individuell angepasst wird.
Die von der KoSIT bereitgestellten Bausteine richten sich an Entwickler, die sie in eine bestehende Software oder einen n8n-Workflow einbauen. Eine fertige Klick-Oberfläche ohne technische Integration ist in den offiziellen Komponenten nicht enthalten, hier bieten einzelne E-Rechnungs-Portale und Buchhaltungsprogramme eigene, teils vereinfachte Viewer an.
Gründer von NordFlux. Sieben Jahre Erfahrung von Web und SEO bis zur Automatisierung im Konzern-Maßstab, heute pragmatisch für den Mittelstand und mit deutscher Datenhoheit.
Zertifizierungen
Wie der KoSIT-Validator XRechnungen prüft, was Schematron-Fehler bedeuten und wie Sie die Kontrolle automatisieren.
Empfangen ab 2025, ausstellen ab 2027 oder 2028: Welche Frist der E-Rechnungspflicht für Ihren Betrieb gilt und wovon der Stichtag abhängt.
So bauen Sie mit n8n ein automatisches Eingangspostfach, das E-Rechnungen abholt, erkennt und weiterleitet.
Ein Viewer macht eine einzelne XRechnung lesbar, löst aber nicht das eigentliche Problem: Dutzende Rechnungen täglich prüfen, archivieren und ins richtige System bringen. NordFlux baut Ihnen die automatisierte Ein- und Ausgangsstrecke für E-Rechnungen, von der Validierung bis zur revisionssicheren Ablage der XML. Im ersten Gespräch sehen wir uns Ihren aktuellen Rechnungsweg an und zeigen, was sich davon automatisieren lässt.