KoSIT Validator: XRechnung offiziell prüfen – Anleitung, GitHub-Nutzung und Online-Alternative

KoSIT Validator: XRechnung offiziell prüfen – Anleitung, GitHub-Nutzung und einfache Online-Alternative

Wer in Deutschland E-Rechnungen erstellen, empfangen oder versenden muss, stößt schnell auf den Begriff KoSIT Validator. Für XRechnung, UBL, CII und den europäischen Standard EN 16931 ist eine saubere technische Prüfung entscheidend. ZUGFeRD und Factur-X werden mit dem Mustang Validator geprüft. Denn eine E-Rechnung ist nicht einfach eine PDF-Datei, sondern ein strukturiertes elektronisches Rechnungsformat, das maschinell verarbeitet werden kann.

Das Bundesfinanzministerium stellt klar: Seit dem 1. Januar 2025 ist eine einfache PDF-Rechnung keine E-Rechnung im neuen Sinne mehr, weil ihr die strukturierte elektronische Datenbasis fehlt. Unternehmen müssen seit dem 1. Januar 2025 E-Rechnungen empfangen können; für die Ausstellung gelten Übergangsregelungen. Die offiziellen Informationen dazu finden Sie in den FAQ des Bundesfinanzministeriums zur E-Rechnung und auf e-rechnung-bund.de zur E-Rechnung zwischen Unternehmen.

Der KoSIT Validator prüft XRechnung-Dateien gegen Schema-, Schematron- und Geschäftsregeln. Für die praktische Nutzung sind fünf Punkte entscheidend:

• was der KoSIT Validator technisch prüft,
• warum er für XRechnung und EN 16931 so wichtig ist,
• wie Entwickler ihn lokal über GitHub nutzen können,
• warum die Einrichtung per Kommandozeile für viele Unternehmen unnötig komplex ist,
• und wie Sie Ihre Rechnung mit RechneX einfacher online prüfen, erstellen oder konvertieren können.

XRechnung direkt im Browser prüfen: Der XRechnung Validator prüft Ihre Datei mit dem KoSIT-Prüfstand, ohne lokale Installation. Wann die Versandpflicht ab 2027 gilt, erklärt die Seite E-Rechnungspflicht ab 2027.

Sie prüfen eine Eingangsrechnung für den Vorsteuerabzug? Die steuerliche Einordnung von Validierungsfehlern erklärt, warum der technische Prüfstatus allein dafür nicht ausreicht.

Für Unternehmen, die die Prüfung direkt in ERP, Shop, CRM, Plattform oder interne Workflows integrieren möchten, ist die KoSIT Validator API für XRechnung der passende Enterprise-Einstieg. ZUGFeRD- und Factur-X-Prüfungen lassen sich über Mustang ergänzen.

Drei reproduzierbare Zustände mit synthetischen Daten: technisch gültig, bewusst fehlerhaft und nach Ergänzung der Käuferreferenz erneut gültig. Die zugehörigen XML-Dateien finden Sie im öffentlichen Validierungs-Testpaket.

Zwei Fehler mit Originalberichten nachvollziehen

Diese drei Dateien wurden lokal mit KoSIT Validator 1.6.2, XRechnung-Konfiguration v2026-01-31 und XRechnung-Schematron 2.5.0 tatsächlich geprüft. Sie enthalten ausschließlich synthetische Rechnungsdaten. Die HTML- und XML-Berichte stammen unverändert aus diesem Prüflauf; sie sind keine nachgebauten Erfolgsmeldungen. Geprüft am 7. September 2026. RechneX prüft inzwischen mit Validator-Konfiguration v2026-08-31; neuere Regeln können zusätzliche Hinweise ergeben.

Jede Fehlerdatei unterscheidet sich von der korrigierten Datei ausschließlich an der beschriebenen Stelle. Beide Fehler können deshalb unabhängig nachvollzogen werden. Die gemeinsame Nachher-Datei hat keine Fehler und keine Warnungen. Laden Sie die Dateien herunter und prüfen Sie sie im XRechnung Validator selbst.

BR-DE-15: Käuferreferenz ergänzen, Empfänger trotzdem prüfen

Vorher: Das Element cbc:BuyerReference fehlt vollständig. Das XML-Schema lässt diese Struktur zu; die zusätzliche XRechnung-Regel verlangt jedoch BT-10, die Käuferreferenz. Deshalb sind „Schema gültig“ und „Rechnung abgelehnt“ hier kein Widerspruch. Im Originalbericht finden Sie die Regel-ID BR-DE-15, den Schweregrad error und die Fundstelle am Wurzelelement der Rechnung: Ein fehlendes Element hat selbst keine Fundstelle.

Nachher: Im UBL-Beispiel steht direkt nach der Dokumentwährung wieder:

<cbc:BuyerReference>04011000-12345-34</cbc:BuyerReference>

Der Wert ist Teil der synthetischen Musterrechnung und darf nicht als Empfängerkennung für Ihre Rechnung übernommen werden. Fragen Sie die Referenz beim Auftraggeber ab. Bei Behörden ist dies üblicherweise die Leitweg-ID; im B2B-Fall kann es eine andere vereinbarte Käuferreferenz sein. Eine Bestellung in BT-13 ersetzt BT-10 nicht automatisch. Die technische Prüfung bestätigt weder, wem die Kennung gehört, noch ob der Empfänger diesen Auftrag erwartet.

In UBL Invoice lautet der Feldpfad Invoice/cbc:BuyerReference, in CII CrossIndustryInvoice/SupplyChainTradeTransaction/ApplicableHeaderTradeAgreement/BuyerReference. Die vollständigen Namespaces und Syntaxpfade stehen in der BT-10-Feldhilfe. Der herunterladbare Prüfnachweis oben bezieht sich auf UBL.

Korrigieren Sie die Referenz im Rechnungsprogramm und exportieren Sie erneut. In unserer Nachher-Datei verschwindet BR-DE-15; die vollständige Prüfung ergibt ACCEPTABLE.

BR-CO-16: Zahlbetrag aus den richtigen Summen ableiten

Die Musterrechnung enthält zwei Stunden zu 100,00 €: 200,00 € netto + 38,00 € Umsatzsteuer = 238,00 € brutto. Es gibt keine Vorabzahlung und keinen Rundungsbetrag. In der Fehlerdatei wurde nur der Zahlbetrag auf 237,99 € geändert.

Die offizielle Regel BR-CO-16 verknüpft diese Felder: BT-115 = BT-112 − BT-113 + BT-114. Im Beispiel ist das 238,00 − 0,00 + 0,00 = 238,00 €.

Die Korrektur betrifft in UBL ausschließlich cac:LegalMonetaryTotal/cbc:PayableAmount:

<!-- Vorher -->
<cbc:PayableAmount currencyID="EUR">237.99</cbc:PayableAmount>
<!-- Nachher -->
<cbc:PayableAmount currencyID="EUR">238.00</cbc:PayableAmount>

In CII entspricht BT-115 dem Element DuePayableAmount innerhalb von ApplicableHeaderTradeSettlement/SpecifiedTradeSettlementHeaderMonetarySummation. BT-112 heißt dort GrandTotalAmount, BT-113 TotalPrepaidAmount und BT-114 RoundingAmount. Verwenden Sie die verlinkten Feldhilfen für die vollständigen Pfade.

Nicht jede Centdifferenz ist ein zulässiger Rundungsbetrag. Tragen Sie keinen erfundenen Wert in BT-114 ein, nur um die Prüfung zu bestehen. Prüfen Sie zuerst die Berechnung im Ausgangssystem. Vorabzahlungen müssen tatsächlichen Zahlungen entsprechen. Die Korrektur einer Summe kann weitere abhängige Beträge verändern.

Wenn die Differenz aus fest vereinbarten Bruttopreisen entsteht, hilft der Ratgeber Bruttopreise in XRechnung und ZUGFeRD richtig runden. Er unterscheidet zu früh gerundete Einzelpreise, Steuerdifferenzen und Zahlungsrundungen.

Andere Summenfehler: von den Positionen zum Zahlbetrag prüfen

Für BR-CO-10, BR-CO-13, BR-CO-15 und BR-CO-17 enthält dieses Paket keinen eigenen Vorher-/Nachher-Prüflauf. Die Tabelle hilft, die Ursache einzugrenzen; der konkrete Summen-Prüfnachweis oben gilt für BR-CO-16.

Korrigierte Datei erneut prüfen

1. Lesen Sie Regel-ID, Meldung und Fundstelle; öffnen Sie bei unklaren Ergebnissen den Originalbericht.
2. Korrigieren Sie die betreffenden Angaben im Ausgangssystem und exportieren Sie die XML-Datei neu.
3. Wählen Sie nach einer abgelehnten eigenen Rechnung im Validator „Korrigierte Datei erneut prüfen“ und laden Sie den neuen Export hoch. Für einen anderen Beleg wählen Sie „Neue Validierung“.
4. Kontrollieren Sie das gesamte neue Ergebnis, einschließlich Warnungen. Eine verschwundene Einzelmeldung reicht nicht, solange andere Fehler bestehen.
5. Prüfen Sie zusätzlich Inhalt, Empfängerreferenz und Versandvorgaben. ACCEPTABLE ist eine technische Annahmeempfehlung, keine Zusage des Empfängers und kein Nachweis der tatsächlichen Leistung.

Ein technischer Ausfall oder eine Prüfung ohne verfügbare KoSIT-Strecke ist kein erfolgreicher Nachher-Nachweis. Bei einer Ablehnung ohne auslesbare Detailmeldungen darf „Schematron gültig“ nicht aus einer leeren Fehlerliste abgeleitet werden.

Was ist der KoSIT Validator?

Für die automatische Weiterverarbeitung zeigt der Leitfaden KoSIT-Prüfberichte maschinell auswerten Original-XML und normalisierte Antworten für erfolgreiche Prüfung, Fehler, Warnung und technischen Ausfall. Nutzen Sie die Referenzen als Grundlage Ihrer Integrationstests.

Der KoSIT Validator ist ein technisches Prüfwerkzeug für strukturierte XML-Dokumente. Im Kontext der E-Rechnung wird er vor allem genutzt, um XRechnungen gegen die passenden technischen Regeln zu prüfen.

Wichtig ist: Der Validator selbst ist eine Prüf-Engine. Die fachlichen Prüfregeln für XRechnung kommen aus der passenden Validator-Konfiguration für XRechnung. Die offiziellen Repositories der Koordinierungsstelle für IT-Standards finden Sie hier:

• itplr-kosit/validator auf GitHub
• itplr-kosit/validator-configuration-xrechnung auf GitHub
• Offizielle Usage-Dokumentation zur XRechnung-Validator-Konfiguration

Die XRechnung-Konfiguration enthält laut offizieller Beschreibung die nötigen XML-Schema- und Schematron-Regeln, um UBL- und CII-Rechnungsdokumente auf Konformität mit XRechnung zu validieren.

Praktisch bedeutet das: Eine XRechnung wird nicht nur geöffnet, sondern technisch und fachlich geprüft. Genau deshalb ist eine KoSIT-nahe Prüfung für Unternehmen so wichtig, die Rechnungen an Behörden, Geschäftskunden, Plattformen oder automatisierte Rechnungseingangssysteme senden.

Was prüft der KoSIT Validator bei einer XRechnung?

Eine valide XRechnung muss mehrere Ebenen erfüllen. Ein XML-Dokument kann technisch lesbar sein und trotzdem fachlich abgelehnt werden. Der KoSIT Validator beziehungsweise die XRechnung-Konfiguration prüft deshalb typischerweise mehrere Bereiche.

Die steuerliche Einordnung ist davon zu unterscheiden: Ein technischer Prüfbericht entscheidet nicht allein über den Vorsteuerabzug. Was bei einem Geschäftsregelfehler zu prüfen ist, erklärt der Abschnitt Validierungsfehler und Vorsteuerabzug.

Die Prüfebenen bauen aufeinander auf. Eine Datei kann korrektes XML enthalten und trotzdem an Pflichtfeldern oder Berechnungen scheitern, wie die Übersicht zeigt.

1. XML-Syntax

Zuerst wird geprüft, ob die XML-Datei technisch korrekt aufgebaut ist. Fehlerhafte Tags, ungültige Verschachtelungen oder kaputte Zeichenkodierung können dazu führen, dass die Datei nicht maschinell verarbeitet werden kann.

2. XML-Schema

Danach wird geprüft, ob die Rechnung dem erwarteten technischen Aufbau entspricht. Bei XRechnung sind insbesondere UBL und UN/CEFACT CII relevant. Diese Syntaxen definieren, wo Rechnungsnummer, Datum, Verkäufer, Käufer, Positionen, Steuerdaten, Zahlungsdaten und Summen stehen müssen.

3. Schematron- und Geschäftsregeln

Die wichtigste Ebene sind die fachlichen Regeln. Hier geht es um Pflichtfelder, logische Zusammenhänge und Business Rules. Beispiele:

• Ist die Rechnungsnummer vorhanden?
• Gibt es ein Rechnungsdatum?
• Stimmen Positionssummen und Gesamtsummen zusammen?
• Ist bei Umsatzsteuer die Steuerkategorie korrekt angegeben?
• Ist bei 0 Prozent Steuer ein zulässiger Grund vorhanden?
• Enthält eine XRechnung an öffentliche Auftraggeber die erforderliche Leitweg-ID?
• Sind Zahlungsinformationen, Verkäuferdaten und Käuferdaten plausibel strukturiert?

Mehr zum Begriff finden Sie in unserem Glossar zu Schematron, KoSIT und EN 16931.

Welchen XRechnung-Prüfstand nutzt RechneX?

Ein Validator ist nur aussagekräftig, wenn Rechnungsstandard, technisches Bundle und Validator-Konfiguration zusammenpassen. RechneX prüft aktuell XRechnung 3.0 mit dem technischen Bundle XRechnung 3.0.2 und Validator-Konfiguration v2026-08-31.

Der Prüfbericht kann dabei Kennungen aus verschiedenen Regelwerken enthalten. Dazu gehören beispielsweise BR-DE-Regeln der XRechnung und BR-CO-Regeln aus dem EN-16931-Umfeld. Eine rote Meldung bedeutet deshalb nicht pauschal „XML kaputt“: Sie kann auf einen Syntaxfehler, ein fehlendes Pflichtfeld, einen unzulässigen Code oder einen rechnerischen Widerspruch hinweisen.

Für die Korrektur sollten Sie immer die konkrete Regelkennung, den betroffenen XML-Pfad und den Meldungstext gemeinsam betrachten. Verständliche Erläuterungen zu häufigen Kennungen finden Sie im Ratgeber XRechnung-Fehlercodes: Ursachen und Lösungen.

Validierungsfehler: Ist der Vorsteuerabzug trotzdem möglich?

Ein Geschäftsregelfehler führt nicht automatisch zum Verlust des Vorsteuerabzugs. Das BMF stellt in Randnummern 22 und 23 des Schreibens vom 15. Oktober 2026 klar: Eine Datei mit Geschäftsregelfehler, aber ohne Formatfehler, bleibt umsatzsteuerlich grundsätzlich eine E-Rechnung. Für ihre Ordnungsmäßigkeit müssen die Pflichtangaben nach §§ 14 und 14a UStG richtig und vollständig sein.

Damit ist der Vorsteuerabzug noch nicht zugesagt. Bei einer gewöhnlichen inländischen Eingangsrechnung verlangt § 15 Absatz 1 Satz 1 Nummer 1 UStG unter anderem eine Leistung eines anderen Unternehmers für das eigene Unternehmen, gesetzlich geschuldete Umsatzsteuer und den Besitz einer entsprechend ausgestellten Rechnung. Ausschlüsse vom Vorsteuerabzug können hinzukommen. Ob diese Voraussetzungen vorliegen, kann KoSIT anhand der Datei allein nicht feststellen.

Die oben gezeigte fehlende Käuferreferenz BT-10 betrifft zunächst eine technische XRechnung-Pflicht. Daraus folgt für sich genommen keine fehlende umsatzsteuerliche Pflichtangabe. Ein unzutreffender Steuerbetrag oder eine unzureichende Leistungsbeschreibung berührt dagegen steuerliche Angaben. Für den konkreten Abgleich empfiehlt das BMF die Zuordnungstabelle von KoSIT und FeRD.

Gehen Sie bei einer Eingangsrechnung so vor:

1. Lesen Sie Regelkennung, Meldung und betroffene Felder im Prüfbericht. Unterscheiden Sie Format- und Geschäftsregelfehler.
2. Vergleichen Sie die betroffenen Angaben mit der tatsächlichen Leistung und den steuerlichen Pflichtangaben. Ein formal ausgefülltes Feld kann inhaltlich falsch sein.
3. Fordern Sie bei fehlerhaften Pflichtangaben eine Berichtigung vom Aussteller an. Klären Sie offene steuerliche Fragen mit Ihrer Buchhaltung oder Steuerkanzlei und bewahren Sie Rechnung, Bericht und Klärung nachvollziehbar auf.
4. Prüfen Sie die korrigierte Datei erneut. Stimmen Sie zusätzlich ab, ob Ihr Empfangssystem sie verarbeiten kann.

Ein Portal darf eine technisch nichtkonforme Datei weiterhin zurückweisen. Die steuerliche Einordnung ersetzt deshalb weder die technische Fehlerbehebung noch die Empfängeranforderungen. Weitere Änderungen erläutert der Überblick zum BMF-Schreiben 2026.

Warum ist der KoSIT Validator für E-Rechnungen so wichtig?

Bei einer klassischen PDF-Rechnung sieht ein Mensch schnell, ob eine Rechnung plausibel aussieht. Bei einer E-Rechnung zählt zusätzlich, ob die Datei maschinell korrekt verarbeitet werden kann.

Das ist besonders wichtig bei:

• XRechnung an Behörden
• B2G-Rechnungen mit Leitweg-ID
• B2B-E-Rechnungen ab 2025 mit Übergangsfristen
• ERP-Exporten aus Buchhaltungssoftware
• ZUGFeRD- oder Factur-X-Rechnungen mit eingebettetem XML
• automatisierten Rechnungseingängen
• Shop-, CRM- oder ERP-Prozessen
• Massenverarbeitung und API-Workflows

Ein kleiner XML-Fehler kann dazu führen, dass eine Rechnung nicht angenommen wird. Deshalb sollten Unternehmen E-Rechnungen nicht erst nach dem Versand prüfen, sondern vorab validieren.

Offizieller Entwickler-Weg: KoSIT Validator lokal über GitHub nutzen

Wenn Sie Entwickler sind oder eine eigene E-Rechnungsstrecke betreiben, können Sie den KoSIT Validator lokal oder serverseitig einsetzen. Das offizielle Repository beschreibt mehrere Nutzungsarten, unter anderem als Standalone-CLI, als eingebettete Java-Bibliothek oder als Dienst mit HTTP-Schnittstelle.

Die folgende Anleitung ist eine vereinfachte Orientierung für den lokalen CLI-Weg. Prüfen Sie für produktive Systeme immer die aktuelle offizielle Dokumentation und Releases der KoSIT-Repositories.

Voraussetzungen

Sie benötigen in der Regel:

• eine passende Java-Laufzeit,
• Zugriff auf die Kommandozeile,
• den aktuellen Validator-Release,
• die passende XRechnung-Validator-Konfiguration,
• eine zu prüfende XML-Datei,
• Grundkenntnisse im Umgang mit Terminal, Pfaden und ZIP-Dateien.

Schritt 1: Validator herunterladen

Laden Sie den Validator aus dem offiziellen Repository herunter:

KoSIT Validator Releases auf GitHub

Die offizielle Dokumentation zeigt beispielsweise den Download eines Validator-ZIP-Archivs per curl. Verwenden Sie in produktiven Umgebungen immer die Version, die zu Ihrer XRechnung-Konfiguration und Ihren Anforderungen passt.

Schritt 2: XRechnung-Validator-Konfiguration herunterladen

Der Validator allein enthält noch keine spezifischen XRechnung-Regeln. Für die Prüfung von XRechnung benötigen Sie zusätzlich die passende Konfiguration:

Validator Configuration XRechnung Releases

Diese Konfiguration enthält die relevanten XML-Schema- und Schematron-Regeln für die XRechnung-Prüfung.

Schritt 3: Dateien entpacken

Entpacken Sie den Validator und die Validator-Konfiguration in einem gemeinsamen Arbeitsverzeichnis. Die offizielle Usage-Dokumentation zeigt diesen Ablauf mit unzip.

Schritt 4: XRechnung prüfen

Ein typischer CLI-Aufruf orientiert sich an diesem Muster:

bash
java -jar validator-<version>-standalone.jar -s scenarios.xml -r <repository-path> -h meine-rechnung.xml

Die konkrete Datei, Version und Pfadangabe hängen von Ihrem Setup ab. In der offiziellen Dokumentation finden Sie die jeweils aktuellen Beispiele:

KoSIT XRechnung Validator Usage

Schritt 5: Prüfbericht auswerten

Nach der Validierung erhalten Sie einen technischen Prüfbericht. Dieser zeigt, ob die Rechnung valide ist oder welche Regeln verletzt wurden. Für Entwickler ist das hilfreich. Für Buchhaltung, Geschäftsführung, Verwaltung oder Vertrieb ist der Bericht aber oft zu technisch.

Genau hier entsteht das praktische Problem: Der offizielle Weg ist stark, aber nicht besonders niedrigschwellig.

Das Problem bei der lokalen KoSIT-Prüfung

Der KoSIT Validator ist technisch leistungsfähig. Für viele Unternehmen ist der direkte Einsatz über GitHub und Kommandozeile jedoch aufwendig.

Typische Hürden sind:

* Java muss korrekt installiert sein.
* Validator und XRechnung-Konfiguration müssen zusammenpassen.
* Releases und Regelwerke müssen aktuell gehalten werden.
* Der CLI-Aufruf muss richtig aufgebaut sein.
* Der Prüfbericht muss fachlich verstanden werden.
* Fehlercodes müssen in konkrete Korrekturen übersetzt werden.
* Bei ZUGFeRD muss zusätzlich das eingebettete XML berücksichtigt werden.
* Bei größeren Volumen braucht es Automatisierung, Monitoring und Fehlerlisten.

Für Entwickler, ERP-Hersteller und Plattformbetreiber ist dieser Weg sinnvoll. Für Selbstständige, Handwerksbetriebe, KMU, Buchhaltungsteams oder Fachabteilungen ist eine Online-Prüfung oft deutlich effizienter.

Einfache Alternative: XRechnung online validieren mit RechneX

Mit RechneX können Sie E-Rechnungen direkt im Browser prüfen. Der XRechnung Validator ist dafür gedacht, XML-Rechnungen verständlich zu validieren, ohne dass Sie selbst Java, GitHub-Releases oder Kommandozeilenbefehle einrichten müssen.

RechneX unterstützt rund um die E-Rechnung mehrere zentrale Workflows:

* XRechnung prüfen
* E-Rechnung validieren
* XRechnung lesbar anzeigen
* PDF zu XRechnung oder ZUGFeRD konvertieren
* XRechnung manuell erstellen
* ZUGFeRD manuell erstellen
* KoSIT Validator API für automatisierte Workflows

Der Vorteil: Sie laden Ihre Datei hoch, erhalten ein verständliches Ergebnis und sehen schneller, ob Ihre Rechnung vor dem Versand korrigiert werden muss.

KoSIT CLI vs. RechneX Validator

So prüfen Sie eine XRechnung online in wenigen Schritten

Schritt 1: Validator öffnen

Öffnen Sie den XRechnung Validator oder den umfassenderen Einstieg E-Rechnung validieren.

Schritt 2: XML-Datei hochladen

Laden Sie Ihre XRechnung-XML hoch. Wenn Sie noch keine Datei zur Hand haben, können Sie zum Testen auch eine Beispiel-XRechnung verwenden.

Schritt 3: Ergebnis prüfen

RechneX zeigt Ihnen, ob die Datei erfolgreich validiert wurde oder ob Fehler gefunden wurden. Statt einen technischen Report manuell zu interpretieren, erhalten Sie eine verständlichere Darstellung der relevanten Hinweise.

Schritt 4: Fehler korrigieren

Falls Pflichtangaben fehlen oder Summen nicht stimmen, korrigieren Sie die Rechnung in Ihrem System oder erstellen Sie die E-Rechnung direkt neu über den passenden Generator.

Schritt 5: Valide E-Rechnung versenden

Erst wenn die Rechnung technisch und fachlich plausibel ist, sollten Sie sie an Kunden, Behörden, Plattformen oder Rechnungseingangssysteme übermitteln.

Häufige Fehler bei der XRechnung-Validierung

Viele Validierungsfehler entstehen nicht durch große technische Probleme, sondern durch kleine Unstimmigkeiten in Pflichtfeldern oder Summen.

Fehlende Pflichtangaben

Typische Pflichtangaben sind Rechnungsnummer, Rechnungsdatum, Verkäufer, Käufer, Positionen, Steuerdaten, Zahlungsinformationen und Gesamtbetrag. Bei Rechnungen an öffentliche Auftraggeber kann zusätzlich die Leitweg-ID erforderlich sein.

Falsche Steuerangaben

Bei Standardumsätzen, Reverse Charge, Kleinunternehmerregelung, Steuerbefreiungen oder 0-Prozent-Steuersätzen müssen Steuerkategorie, Steuersatz und Begründung zusammenpassen. Schon ein falscher Code kann zur Ablehnung führen.

Summen passen nicht zusammen

Positionsbeträge, Nettosummen, Steuerbeträge und Bruttobeträge müssen rechnerisch konsistent sein. Rundungsdifferenzen sind eine häufige Fehlerquelle, besonders bei vielen Positionen.

Falscher Dokumenttyp

Eine Rechnung, Gutschrift, Korrekturrechnung, Abschlagsrechnung oder Schlussrechnung ist fachlich nicht dasselbe. Der Belegtyp muss korrekt abgebildet werden.

Ungültige oder unvollständige Zahlungsdaten

IBAN, Zahlungsbedingungen, Fälligkeitsdatum und Verwendungszweck sollten sauber strukturiert sein, damit Rechnungsempfänger und automatische Buchhaltungssysteme die Daten verarbeiten können.

Technisch gültig, aber fachlich problematisch

Eine Datei kann formal XML sein und trotzdem nicht den XRechnung-Geschäftsregeln entsprechen. Deshalb reicht es nicht, eine XML-Datei nur zu öffnen. Sie muss validiert werden.

XRechnung, ZUGFeRD und Factur-X: Was wird eigentlich validiert?

Bei der Validierung ist wichtig zu verstehen, welches Format Sie prüfen.

XRechnung

Die XRechnung ist ein strukturiertes XML-Format. Sie wird besonders im öffentlichen Auftragswesen eingesetzt und basiert auf den Anforderungen der EN 16931. Für XRechnung sind UBL und CII relevante Syntaxen.

ZUGFeRD

ZUGFeRD ist ein hybrides Format: Es kombiniert eine lesbare PDF-Datei mit eingebettetem XML. Dadurch ist die Rechnung für Menschen sichtbar und gleichzeitig maschinell auswertbar. RechneX erzeugt ZUGFeRD im passenden PDF/A-3B-Kontext über den ZUGFeRD Generator oder den PDF-Konverter.

Factur-X

Factur-X ist eng mit ZUGFeRD verbunden und ebenfalls ein hybrides Rechnungsformat mit eingebettetem XML. Für Unternehmen mit internationalen oder europäischen Rechnungsaustauschprozessen kann das relevant sein.

UBL und CII

UBL und CII sind technische XML-Syntaxen, in denen eine elektronische Rechnung strukturiert abgebildet werden kann. Die XRechnung-Konfiguration der KoSIT enthält laut offizieller GitHub-Beschreibung Regeln zur Validierung von UBL- und CII-Rechnungsdokumenten.

Wann reicht der kostenlose Validator und wann lohnt sich Pro?

Der kostenlose Einstieg ist ideal, wenn Sie einzelne Rechnungen prüfen, erste Tests durchführen oder gelegentlich eine XRechnung ansehen möchten.

Laut aktueller RechneX-Preisseite umfasst der kostenlose Tarif unter anderem:

* 50 KoSIT-Validierungen pro Tag,
* 3 XRechnung-Ansichten pro Tag,
* 1 E-Rechnung pro Tag erstellen,
* Viewer und Validator kostenlos nutzen,
* keine Kreditkarte erforderlich,
* Einzelkauf für einzelne E-Rechnungen oder PDF-Konvertierungen.

Der Pro-Tarif eignet sich, wenn Sie regelmäßig E-Rechnungen erstellen, prüfen oder PDF-Rechnungen und unterstützte Sonderfälle konvertieren möchten. Laut RechneX-Preisseite umfasst Pro unter anderem:

* unterstützte PDF-Konvertierungen im Pro-Tarif,
* XRechnung- und ZUGFeRD-Generator,
* XRechnung-Viewer,
* KoSIT-Validierungen,
* KoSIT-Validierung vor dem Download,
* KI-Datenextraktion und Data Editor,
* Batch-Upload bis 10 PDFs pro Lauf,
* Prioritäts-Support per E-Mail.

Alle aktuellen Konditionen finden Sie auf der Seite Preise und Pro-Tarif ansehen.

Enterprise: KoSIT-Validierung, API und E-Rechnung-Automatisierung für komplexe Prozesse

Nicht jedes Unternehmen möchte einzelne Dateien manuell hochladen. Viele Mittelständler, Plattformen, Shops, ERP-Anwender und Dienstleister brauchen automatisierte E-Rechnungsprozesse.

Der Enterprise-Plan von RechneX ist für genau diese Fälle gedacht. Er passt, wenn Sie:

* E-Rechnungen direkt aus ERP, CRM oder Shop erzeugen möchten,
* eine API für XRechnung, ZUGFeRD oder Validierung benötigen,
* bestehende Systeme anbinden wollen,
* PDF-Rechnungen automatisch in XRechnung oder ZUGFeRD konvertieren möchten,
* E-Rechnungen per E-Mail weiterleiten oder verarbeiten lassen möchten,
* automatisierten E-Rechnungsversand benötigen,
* hohe Belegvolumen verarbeiten,
* strukturierte Fehlerreports und Fehlerlisten brauchen,
* Freigabeprozesse im Dashboard abbilden möchten,
* Sonderfälle wie Abschlagsrechnungen, Schlussrechnungen, Storno, Gutschriften, Korrekturrechnungen oder Factoring automatisiert verarbeiten müssen,
* individuelle Pflichtfelder, Empfängerregeln oder Layoutlogiken benötigen,
* SLA, Monitoring, White-Label, SSO oder persönliches Onboarding wünschen.

Enterprise ist besonders sinnvoll, wenn fast alles möglich sein muss: eigene Prozessregeln, API-Anbindung, ERP-Integration, Shopware- oder Shopsystem-Anbindung, E-Mail-Weiterleitung, E-Rechnungsversand, individuelle Prüfstrecken, manuelle Freigabe und Sonderfallbehandlung.

Für wen ist welcher Weg sinnvoll?

Entwickler und technische Teams

Wenn Sie eine eigene E-Rechnungssoftware entwickeln, kann der direkte Einsatz des offiziellen KoSIT Validators sinnvoll sein. Sie behalten volle Kontrolle über Konfiguration, Releases, Reports und Integration.

Selbstständige und Freiberufler

Wenn Sie einzelne E-Rechnungen erstellen oder prüfen möchten, ist ein Browser-Workflow meist schneller. Nutzen Sie den XRechnung Generator, den ZUGFeRD Generator oder den Validator.

Handwerk und kleine Unternehmen

Wenn Sie bisher PDF-Rechnungen aus Word, Excel, DATEV-nahen Prozessen oder einer älteren Software erzeugen, ist der PDF zu XRechnung und ZUGFeRD Konverter oft der pragmatischste Einstieg.

Mittelstand

Wenn Sie regelmäßig Standardrechnungen prüfen, erstellen oder konvertieren, ist der Pro-Tarif eine klare Lösung mit festen Kosten. Details finden Sie auf der Preise-Seite.

Unternehmen mit komplexen Workflows

Wenn Sie die Erkennung auf Ihre Vorlagen abstimmen möchten, ERP, CRM oder Shop anbinden oder hohe Volumen mit Freigaben verarbeiten, können Sie Enterprise nutzen. Die Einrichtung richtet sich nach Ihren Belegen und Abläufen.

Best Practice: E-Rechnung immer vor dem Versand validieren

Ob Sie den offiziellen KoSIT Validator lokal einsetzen oder RechneX online nutzen: Prüfen Sie E-Rechnungen möglichst vor dem Versand.

Eine sinnvolle Reihenfolge ist:

1. Rechnung in Ihrem System erstellen.
2. XRechnung oder ZUGFeRD-Datei erzeugen.
3. Datei validieren.
4. Fehler korrigieren.
5. Rechnung erneut validieren.
6. Erst danach an Kunde, Behörde, Portal oder Rechnungseingang versenden.
7. Ergebnis und Rechnung revisionssicher im eigenen System archivieren.

So reduzieren Sie Rückfragen, Ablehnungen und manuelle Nacharbeit.

Häufige Fragen zum KoSIT Validator

Prüft KoSIT auch alle zusätzlichen Anforderungen meines Kunden?

Nein. Der Standardprüflauf kennt nicht jede bilateral vereinbarte Kunden- oder Lieferreferenz. Im fiktiven Fall einer fehlenden Lieferscheinreferenz ist eine Rechnung technisch gültig, erfüllt aber eine zusätzlich angenommene Kundenvorgabe nicht. Der verlinkte Originalbericht dokumentiert den genauen Prüfstand; er ist keine Empfängerfreigabe.

Nutzen Sie die Anforderungsliste als PDF oder Excel-Datei für diesen gesonderten Abgleich. Zwei weitere vollständige Referenzfälle mit Originalprüfberichten zeigen Kennungen und Lieferreferenzen sowie mehrere Nachlassebenen.

Ist der KoSIT Validator kostenlos?

Der offizielle Validator und die XRechnung-Konfiguration werden öffentlich über die itplr-kosit-Repositories bereitgestellt. Der technische Einsatz erfordert jedoch Einrichtung, Wartung und Know-how. Für viele Anwender ist eine Online-Oberfläche wie RechneX praktischer.

Muss ich den KoSIT Validator selbst installieren?

Nein. Wenn Sie nur eine XRechnung prüfen möchten, können Sie den XRechnung Validator oder den Workflow E-Rechnung validieren nutzen. Eine lokale Installation ist vor allem für Entwickler und technische Integrationen relevant.

Kann ich mit dem KoSIT Validator auch ZUGFeRD prüfen?

Der KoSIT Validator ist bei RechneX für XRechnung vorgesehen. ZUGFeRD und Factur-X werden mit dem Mustang Validator geprüft, der das eingebettete XML und den hybriden PDF/A-3-Container berücksichtigt. Für die jeweilige Prüfung nutzen Sie den ZUGFeRD Validator.

Was ist der Unterschied zwischen XRechnung Validator und XRechnung Viewer?

Ein Validator prüft, ob die Datei technisch und fachlich gültig ist. Ein Viewer macht die XML-Rechnung lesbar. Wenn Sie eine XML-Datei verstehen möchten, nutzen Sie den Viewer. Wenn Sie wissen möchten, ob sie akzeptiert werden kann, nutzen Sie den Validator.

Kann RechneX auch E-Rechnungen erstellen?

Ja. Sie können E-Rechnungen direkt über den XRechnung Generator oder ZUGFeRD Generator erstellen. Alternativ können Sie bestehende PDF-Rechnungen über den Konverter in XRechnung oder ZUGFeRD überführen.

Kann RechneX bestehende Systeme anbinden?

Ja, für komplexe Anforderungen ist Enterprise vorgesehen. Dazu gehören API-Anbindung, ERP-/CRM-/Shop-Anbindung, E-Mail-Weiterleitung, E-Rechnungsversand, eigene Regeln, Sonderfälle, Freigaben, strukturierte Fehlerreports und individuelle Workflows. Details finden Sie auf der Preise-Seite.

Fazit: KoSIT-Standard nutzen, ohne sich in Technik zu verlieren

Der KoSIT Validator ist ein zentraler technischer Baustein für die Prüfung von XRechnungen nach EN 16931. Für Entwickler, ERP-Hersteller und technische Teams ist der direkte Weg über GitHub und Kommandozeile sinnvoll. Für die meisten Unternehmen ist er jedoch zu aufwendig, wenn nur schnell eine E-Rechnung geprüft, erstellt oder konvertiert werden soll.

RechneX macht diesen Prozess einfacher: Sie können XRechnungen validieren, XML-Rechnungen lesbar anzeigen, PDF-Rechnungen in XRechnung oder ZUGFeRD umwandeln und neue E-Rechnungen direkt im Browser erstellen. Für regelmäßige unterstützte Rechnungen und Sonderfälle gibt es Pro. Für API, ERP-Anbindung, hohe Volumen, automatisierte Sonderfälle, E-Mail-Weiterleitung, E-Rechnungsversand und individuelle Automatisierung gibt es Enterprise.