Die elektronische Rechnungsstellung im öffentlichen Sektor folgt in Deutschland dem Standard XRechnung. Dieser Standard wird von der KoSIT (Koordinierungsstelle für IT-Standards) im Auftrag des IT-Planungsrats entwickelt, gepflegt und betrieben. GitHub spielt dabei eine zentrale Rolle: Auf der Plattform stellen die Betreiber Quellcode, technische Komponenten, Validator-Konfigurationen und weitere Artefakte bereit, die für die praktische Umsetzung erforderlich sind. Wenn Sie XRechnung in Ihre Finance- und Rechnungsprozesse einführen möchten, müssen Sie verstehen, welche GitHub-Ressourcen tatsächlich relevant sind, wie Sie diese in bestehende Systeme integrieren und welcher konkrete Aufwand und Nutzen damit verbunden ist. Im weiteren Kontext der E-Rechnung ist dieses Verständnis besonders wichtig.
Dieser Guide zeigt Ihnen Schritt für Schritt, wie Sie XRechnung-Repositories auf GitHub nutzen, welche Komponenten Sie wirklich benötigen, wie Sie den Validator konfigurieren und testen und wie Sie Validierung sowie Visualisierung in Ihre ERP- und Eingangsrechnungsprozesse einbinden. Der Fokus liegt auf praktischer Umsetzbarkeit statt auf technischen Details.
Bevor Sie GitHub-Komponenten nutzen, sollten Sie folgende Punkte klären:
Auf GitHub finden Sie unter der Organisation des IT-Planungsrats (itplr-kosit) mehrere Repositories. Nicht alle sind für jeden Anwendungsfall gleich wichtig. Hier die zentralen Repositories und ihre praktische Bedeutung:
| Repository | Funktion und Inhalt | Wann benötigt? | Priorität |
|---|---|---|---|
| validator-configuration-xrechnung | Enthält die aktuelle Validatorkonfiguration für die gültige XRechnung-Version. Legt fest, welche Geschäftsregeln und Schematron-Dateien der Validator prüft. Dies ist das "Gehirn" des Validators. | Immer, wenn Sie einen Validator einsetzen. Ein Validator mit veralteter Konfiguration validiert nicht zuverlässig. | Zwingend |
| xrechnung-visualization | XSLT-Dateien zur Umwandlung von XRechnungen in lesbare HTML- oder PDF-Formate. Ermöglicht Mitarbeitern, XML-Inhalte zu verstehen. | Wenn Sie Fehleranalyse oder fachliche Freigabe durch Finance-Mitarbeiter benötigen. Besonders wertvoll bei der Eingangsrechnungsprüfung. | Stark empfohlen |
| xrechnung-schematron | Schematron-Dateien und XSLT-Umsetzungen für nationale Geschäftsregeln. Ergänzt die EU-Validierungsmittel. | Nur wenn Sie sehr spezifische nationale oder interne Geschäftsregeln prüfen möchten. Für die Standardnutzung nicht erforderlich. | Optional |
| xrechnung-bundle | Komplettes Paket einer XRechnung-Version mit Validator, Schematron, XSLT, Beispielrechnungen, Dokumentation und SeMoX-Modellen (seit 3.0.2). | Als Einstiegspunkt zum Testen und zur Dokumentation. Laden Sie das aktuelle Bundle herunter, bevor Sie mit der Integration starten. | Zwingend für Tests |
Für die meisten Unternehmen genügen validator-configuration-xrechnung und xrechnung-bundle. Die Visualisierung ist eine praktische Ergänzung, kein Muss.
Eine der häufigsten Fehlerquellen ist die Verwendung veralteter Versionen. XRechnung wird in Versionen und Bundles veröffentlicht. Seit Februar 2024 gilt Version 3.0. Version 2.3 wurde zum 1. Februar 2024 außer Kraft gesetzt und ist nicht mehr zur Nutzung in Produktion empfohlen.
Das Betriebskonzept XRechnung sieht vor, dass mittelfristig nur noch ein Hauptrelease pro Jahr erfolgt statt zwei (Sommer und Winter). Dies bedeutet für Sie: Versionswechsel werden seltener, aber dafür umfassender. Unternehmen sollten inzwischen prüfen, ob sie noch Version 2.3 nutzen, und einen Migrationszeitplan zu Version 3.0 haben, der bis spätestens Frühjahr 2025 abgeschlossen sein sollte.
Wenn Sie ein Repository bewerten, sollten Sie diese Punkte prüfen:
Ältere Versionen stehen zwar weiterhin zu Informationszwecken zur Verfügung. Es wird aber ausdrücklich davon abgeraten, Versionen nach ihrer Außerkraftsetzung zur Rechnungseinreichung zu verwenden. Wenn Ihre Systeme noch Version 2.3 nutzen, sollten Sie inzwischen einen Migrationszeitplan haben.
Ein Bundle ist ein Paket, das alle technischen Komponenten einer XRechnung-Version zusammenfasst. Das Bundle enthält:
Die empfohlene Herangehensweise ist:
Dieser Test dauert typischerweise 2–4 Stunden und spart Ihnen später erhebliche Debugging-Zeit.
Der Validator ist ein XML-Prüftool, das Ihre XRechnungen technisch validiert. Er prüft:
Die Validatorkonfiguration definiert, welche Regeln und Schematron-Dateien der Validator prüft. Sie finden die aktuelle Konfiguration im Repository validator-configuration-xrechnung. Diese Konfiguration ist essenziell: Ein Validator mit falscher oder veralteter Konfiguration validiert nicht zuverlässig. Für Praxisvergleiche kann zusätzlich ein E-Rechnung-Validator als Orientierung hilfreich sein.
Der Validator wird von der KoSIT als Java-basiertes Werkzeug bereitgestellt. Es gibt mehrere Möglichkeiten, ihn zu nutzen:
| Nutzungsform | Wie es funktioniert | Aufwand | Am besten für |
|---|---|---|---|
| Kommandozeile (CLI) | Sie laden die JAR-Datei herunter und führen sie manuell über Terminal/Kommandozeile aus: java -jar validator.jar -i input.xml -o output.html | Niedrig: Kein Code nötig, nur Befehle | Manuelle Tests und Ad-hoc-Validierungen |
| Java-Integration (OSGi) | Sie binden den Validator als OSGi-Plugin in Ihr Java-System ein (z. B. ECM, ERP). Der Validator läuft im Prozess des Hostsystems. | Mittel bis hoch: Classloader-Management, Dependency-Handling erforderlich | Produktive Integration in Java-Systeme |
| REST-Service/API | Sie bauen einen Microservice, der den Validator aufruft. Rechnungen werden an eine API übermittelt, das Validierungsergebnis wird zurückgegeben. | Mittel: Zusätzliche Service-Schicht nötig, aber entkoppelt vom ERP | Cloud-Szenarien, mehrere Client-Systeme |
| GUI-Tools (OpenXRechnungToolbox) | Sie nutzen grafische Open-Source-Tools, die den Validator aufrufen. Einfach Dateien hochladen, Ergebnis sehen. | Niedrig: Keine Entwicklung, nur Download und Start | Manuelle Überprüfung durch Finance-Mitarbeiter |
Für die meisten Unternehmen ist eine Kombination aus CLI-Tests in der Entwicklung und einer Java-Integration oder API-Integration in Produktion sinnvoll.
Je nachdem, ob Sie Rechnungen versenden oder empfangen, unterscheiden sich die Integrationswege:
Szenario A: Sie versenden Rechnungen an öffentliche Auftraggeber
Workflow: Rechnungserstellung im ERP → XML-Export → Validator prüft vor dem Versand → Fehler werden dem Sachbearbeiter angezeigt → Fehler werden korrigiert → Rechnung wird versendet.
Integrationstechnisch:
Vorteil: Keine ungültigen Rechnungen werden je versendet. Nachteil: Zusätzliche Komplexität im Exportprozess.
Szenario B: Sie empfangen Rechnungen von Lieferanten
Workflow: XRechnung kommt rein (Peppol, E-Mail, Portal) → Validator prüft die Konformität → Visualisierung zeigt den Inhalt → Finance-Mitarbeiter gibt frei oder lehnt ab → Daten werden in das ERP übernommen → Archivierung.
Integrationstechnisch:
Vorteil: Hohe Automatisierung möglich, die Fehlerrate sinkt. Nachteil: DMS- oder Rechnungssystem-Integration erforderlich.
Eine Rechnung ist ein XML-Datensatz. Für Menschen ist diese Form schwer zu lesen. Zur Visualisierung stellt die KoSIT XSLT-Dateien bereit, die eine XRechnung in eine lesbare HTML- oder PDF-Ansicht umwandeln. Diese Dateien finden Sie im Repository xrechnung-visualization.
Wichtig: Visualisierung ist nicht das Gleiche wie Validierung. Eine schön formatierte Darstellung bedeutet nicht, dass die Rechnung korrekt ist. Sie benötigen immer beides: den Validator zur technischen Prüfung und die Visualisierung zur Fehleranalyse und fachlichen Prüfung.
Die Visualisierung ist praktisch für:
In der Praxis bedeutet das: Wenn eine eingehende Rechnung nicht validiert, kann der Empfänger sofort in einer HTML-Ansicht sehen, welche Felder fehlen oder falsch sind. Das spart erhebliche Abstimmungszeit zwischen Lieferant und Abnehmer.
XRechnung nutzt Codelisten für viele Felder. Diese Listen definieren die zulässigen Werte für bestimmte Rechnungselemente (z. B. Länder, Währungen, Steuerkategorien). Die Codelisten sind im Anhang B der Spezifikation dokumentiert und verlinkt.
Geschäftsregeln sind fachliche Vorgaben, die über die reine XML-Struktur hinausgehen. Ein Beispiel: Eine Rechnung muss ein Zahlungsfälligkeitsdatum enthalten oder eine Bankverbindung oder beides. Das kann nicht allein durch ein XSD ausgedrückt werden, sondern nur durch eine Geschäftsregel.
Die technische Umsetzung der Geschäftsregeln erfolgt durch Schematron- und XSLT-Dateien im Repository xrechnung-schematron. Die KoSIT pflegt diese Regeln fortlaufend auf nationaler Ebene.
Für Ihre praktische Umsetzung bedeutet das:
Eine besonders wichtige nationale Anforderung ist die Leitweg-ID. Diese eindeutige Kennung ermöglicht es, eine elektronische Rechnung im strukturierten Format adressiert an den richtigen Empfänger zu leiten. Die Leitweg-ID wurde von Bund und Ländern als einheitliche Systematik festgelegt, um Akzeptanz und Handhabbarkeit zu optimieren.
Die Leitweg-ID ist für öffentliche Auftraggeber und deren Dienstleister essenziell. Sie wird im Standard XRechnung beschrieben. Praktisch bedeutet das:
In einigen GitHub-Tools (wie der OpenXRechnungToolbox) finden Sie auch Funktionen zur Leitweg-ID XRechnung-Prüfung oder Berechnung, die Sie nutzen können.
Bevor Sie Entwicklungsressourcen binden, sollten Sie klären, ob und wann sich die Umsetzung für Ihr Unternehmen wirtschaftlich lohnt. Die Entscheidung hängt von mehreren Faktoren ab:
| Faktor | Frage zur Bewertung | Auswirkung auf den ROI |
|---|---|---|
| Volumen öffentlicher Aufträge | Wie viel Prozent Ihrer Rechnungen gehen an öffentliche Auftraggeber? | Bei unter 5 % kann Outsourcing wirtschaftlicher sein als Eigenintegration. Bei über 20 % lohnt sich meist eine Eigenentwicklung. |
| Aktuelle manuelle Last | Wie viel Zeit verbringen Sie heute mit manuellen Konvertierungen oder der Ablehnung ungültiger Rechnungen? | Wenn dies täglich mehrere Stunden ist, ist ein Validator eine schnelle Kostenersparnis. Wenn nie, ist der ROI schwach. |
| ERP-Unterstützung | Unterstützt Ihr aktuelles ERP-System bereits XRechnung nativ? | Ja: Sie können oft auf externe Validator-Integration verzichten. Nein: Es entsteht zusätzliche Komplexität und höherer Aufwand. |
| Fehlerquoten und Reklamationen | Wie oft kommen Rechnungen zurück, weil sie nicht konform sind? | Jede Reklamation kostet Zeit und Geld. Ein Validator vor dem Versand verhindert diese direkten Kosten. |
| Integrationskosten | Wird die Integration durch interne Ressourcen geleistet oder durch externe Dienstleister? | Externe Integration kann 20.000–50.000 EUR kosten, auch wenn die Tools selbst kostenlos sind. Dies deutlich in die ROI-Rechnung einkalkulieren. |
Eine realistische Business-Case-Rechnung könnte so aussehen: Ein Unternehmen mit 500 Rechnungen pro Jahr an öffentliche Auftraggeber spart durch automatische Validierung etwa 2–3 Tage manuelle Fehleranalyse pro Jahr (ca. 1.500–2.000 EUR). Die Eigenintegration kostet aber 30.000 EUR. Der Break-even ist bei etwa 15–20 Jahren erreicht – wirtschaftlich nicht sinnvoll. Besser: Outsourcing an einen Service-Provider.
Bei 5.000 Rechnungen pro Jahr sieht die Rechnung anders aus: Die Ersparnis liegt bei 15.000–20.000 EUR pro Jahr, die Integration kostet 30.000 EUR, der Break-even ist in 1–2 Jahren erreicht – wirtschaftlich sinnvoll.
Die XRechnung wird von der KoSIT im Auftrag des IT-Planungsrats betrieben. Das Änderungsmanagement erfolgt auf Basis des Betriebskonzepts. Alle interessierten Kreise können Änderungsanträge (Change Requests) einreichen.
Für Ihre Organisation bedeutet das konkret: Wenn Sie XRechnung produktiv nutzen, müssen Sie eine Betriebsverantwortung definieren. Diese Verantwortung sollte umfassen:
Das Betriebskonzept XRechnung ging zum 1. Januar 2023 im Betriebskonzept XStandards Einkauf auf. Das bedeutet für Sie: Die Governance wird breiter und ist nicht mehr nur auf XRechnung fokussiert. Das kann erhebliche Auswirkungen auf geplante Updates haben.
Aus der Praxis gibt es einige typische Fehler bei der Nutzung von GitHub-Komponenten:
Fehler 1: Verwechslung von Spezifikation und Code
GitHub-Repositories sind nicht die offizielle Spezifikation. Die gültige Spezifikation XRechnung ist ein separates Dokument auf der offiziellen Website. Wenn Code und Spezifikation auseinanderlaufen, folgen Sie der Spezifikation. Dies ist auch für Ihre Compliance wichtig: Falls eine Behörde Ihre Rechnung ablehnt, können Sie sich nicht auf GitHub berufen.
Fehler 2: Verwendung veralteter Versionen in Produktion
Unternehmen sollten inzwischen Version 2.3 oder älter nicht mehr produktiv nutzen. Wenn Sie ein System betreiben, sollten Sie mindestens quartalsweise prüfen, ob Updates verfügbar sind, und einen Upgrade-Plan haben.
Fehler 3: Validierung durch Visualisierung ersetzen
Eine schöne Darstellung einer XRechnung bedeutet nicht, dass sie validiert ist. Sie benötigen immer beides: den Validator für die technische Prüfung und die Visualisierung für die fachliche Prüfung und Fehleranalyse.
Fehler 4: Integration ohne Testumgebung
Den Validator direkt in Produktion zu nutzen, ohne ihn vorher ausreichend getestet zu haben, führt zu Überraschungen. Nutzen Sie mindestens eine Staging-Umgebung, um Integration und Fehlerszenarien zu testen.
Fehler 5: Keine Governance für Versionswechsel
Wenn eine neue XRechnung-Version die Anforderungen ändert, kann dies Ihre Rechnungsgenerierung oder Eingangsverarbeitung beeinträchtigen. Ohne klare Governance und Testprozesse erleben Sie produktive Fehler.
Fehler 6: Codelisten veraltet halten
Codelisten ändern sich. Länder, Währungen und Steuerkategorien werden aktualisiert. Wenn Sie Codelisten hardcodiert haben, können neue Rechnungen validierungsfehleranfällig werden.
Fehler 7: Classloader-Probleme in OSGi-Umgebungen ignorieren
Bei der Integration des Validators in Java-Systeme können komplexe Classloader-Probleme entstehen. Das ist ein häufiges Problem bei ECM- oder ERP-Systemen. Planen Sie ausreichend Zeit für Debugging ein.
Fehler 8: Keine Dokumentation von Integrationsentscheidungen
Wenn Sie benutzerdefinierte Anpassungen am Standard vornehmen oder spezielle Integrationen bauen, dokumentieren Sie diese. Das ist essenziell für künftige Wartung und Audits.
Checkliste zur Fehlervermeidung:
Wenn Sie XRechnung in Ihre Prozesse einführen möchten, arbeiten Sie diese vereinfachte Entscheidungs-Checkliste ab:
Frage: Brauche ich wirklich alle Komponenten oder nur den Validator?
Antwort: Das hängt von Ihrem Anwendungsfall ab. Unternehmen, die XRechnungen versenden, benötigen mindestens den Validator. Öffentliche Stellen, die XRechnungen empfangen, benötigen den Validator UND die Visualisierungskomponente. Der Validator allein ist oft ausreichend; die Visualisierung ist eine praktische Ergänzung für die Fehleranalyse und fachliche Prüfung durch Finance-Mitarbeiter. Schematron-Dateien brauchen Sie nur, wenn Sie sehr spezifische nationale oder interne Geschäftsregeln definieren möchten.
Frage: Ist die Integration des Validators in mein ERP-System schwierig und teuer?
Antwort: Das hängt von Ihrer Systemarchitektur ab. Java-basierte Systeme können den Validator relativ direkt integrieren (Aufwand: 2–4 Wochen). Bei anderen Technologien müssen Sie möglicherweise eine REST-API oder einen Service bauen, der den Validator aufruft (Aufwand: 4–8 Wochen). Für OSGi-Umgebungen können komplexe Classloader-Probleme entstehen (Aufwand: 8–16 Wochen). Kosten: Eigenentwicklung 30.000–80.000 EUR, Outsourcing an einen externen Dienstleister 40.000–120.000 EUR. Planen Sie deshalb realistisch und evaluieren Sie vorher, ob E-Rechnung-Beratung oder Outsourcing nicht wirtschaftlicher ist.
Frage: Was ist der Unterschied zwischen CIUS und Extension XRechnung?
Antwort: CIUS XRechnung ist die deutsche Konkretisierung der europäischen Norm EN 16931. Sie schränkt Optionen ein und definiert nationale Verpflichtungen (z. B. Leitweg-ID). Extension XRechnung ergänzt die CIUS um weitere zusätzliche Elemente oder Regeln. Eine Rechnung kann nach CIUS XRechnung oder nach Extension XRechnung erstellt werden; Extensions bauen immer auf einer CIUS auf. Für die meisten Unternehmen ist CIUS ausreichend.
Frage: Wie prüfe ich, ob meine XRechnung konform ist?
Antwort: Eine XRechnung ist konform, wenn sie (1) ein wohlgeformtes XML-Dokument ist, (2) gegen das XSD-Schema valide ist, (3) alle technisch umgesetzten Geschäftsregeln erfüllt und (4) fachlich vollständig und richtig ist. Die Punkte 1–3 prüft der Validator automatisch. Punkt 4 ist eine fachliche Aufgabe, die Sie manuell oder mit Zusatzprüfungen durchführen müssen. Nutzen Sie den Validator immer als ersten Schritt.
Frage: Kann ich Open-Source-Komponenten in meine kommerzielle Software einbinden?
Antwort: Ja. XRechnung-Komponenten stehen unter permissiven Lizenzen. Sie dürfen diese in proprietäre und kommerzielle Software einbinden, verändern und weitervertreiben. Sie müssen nur die Lizenzbedingungen einhalten (z. B. den Lizenztext mitliefern). Das semantische Datenmodell der EN 16931 und die zwei mandatorischen Syntaxen (UBL 2.1 und UN/CEFACT CII) stehen unentgeltlich über das Deutsche Institut für Normung (DIN) zur Verfügung.
Frage: Welche Rolle spielt GitHub für Compliance und Audit?
Antwort: GitHub ist ein Transparenzraum. Sie können den Quellcode prüfen und verstehen, wie Validierung und Verarbeitung funktionieren. Das unterstützt Compliance und Audit. GitHub ersetzt aber nicht die offizielle Spezifikation oder die Governance. Compliance bedeutet, nach der aktuellen Spezifikation zu handeln und diese im Audit-Trail nachzuweisen – nicht nach beliebigen Versionen von GitHub. Falls Sie eine XRechnung ablehnen oder akzeptieren, müssen Sie dies gegen die Spezifikation begründen können.
Frage: Wie oft sollte ich Versionen aktualisieren?
Antwort: Sie sollten alle Versionswechsel zeitnah durchführen, nachdem diese zur Nutzung empfohlen werden. Alte Versionen sollten nicht mehr produktiv verwendet werden. Unternehmen sollten inzwischen einen Upgrade-Plan von Version 2.3 zu Version 3.0 haben, der bis Frühjahr 2025 abgeschlossen sein sollte. Für regelmäßige Bugfixes und Sicherheitsupdates innerhalb einer Hauptversion sollten Sie ebenfalls zeitnah nachziehen. Abonnieren Sie den RSS-Newsfeed der KoSIT, um Ankündigungen nicht zu verpassen.
Frage: Kann ich den Validator auch ohne Git- oder Developer-Kenntnisse nutzen?
Antwort: Ja, aber mit Einschränkungen. Sie können den Validator als fertige JAR-Datei herunterladen und über die Kommandozeile aufrufen. Das reicht für einfache Tests. Für die produktive Integration benötigen Sie aber technische Unterstützung. Alternativ: Nutzen Sie die OpenXRechnungToolbox (Open Source), die eine grafische Benutzeroberfläche bietet und einfacher zu handhaben ist als die Kommandozeile.
Frage: Welche Kosten entstehen durch die Nutzung der GitHub-Komponenten?
Antwort: Die XRechnung-Komponenten selbst sind kostenlos (Open Source). Die Kosten entstehen durch: (1) Entwicklung und Integration in Ihr System (30.000–120.000 EUR je nach Szenario), (2) Testing und Quality Assurance (10.000–30.000 EUR), (3) Schulung von Mitarbeitern (3.000–8.000 EUR) und (4) laufende Wartung und Updates (5.000–15.000 EUR pro Jahr). Planen Sie daher realistisch und evaluieren Sie auch Outsourcing-Optionen.
Frage: Werden die GitHub-Komponenten automatisch aktualisiert, oder muss ich manuell prüfen?
Antwort: Sie müssen manuell prüfen. GitHub lädt keine Komponenten automatisch in Ihre Systeme. Sie müssen regelmäßig (mindestens monatlich) die Release-Seiten der relevanten Repositories prüfen und entscheiden, ob und wann Sie Updates einspielen. Abonnieren Sie die RSS-Feeds der Repositories, um Benachrichtigungen zu erhalten. Bauen Sie einen Prozess ein, bei dem eine verantwortliche Person diese Feeds regelmäßig prüft und Updates koordiniert.