Bevor wir in die technischen Details der JTL-Wawi 2.0 eintauchen, hier das Wichtigste zu den gesetzlichen Rahmenbedingungen. Die E-Rechnungspflicht ist in Deutschland bereits in vollem Gange:
Die Pflichtzeiträume im Überblick
- Seit 1. Januar 2025: Alle Unternehmen im B2B-Bereich müssen in der Lage sein, E-Rechnungen zu empfangen.
- Ab 1. Januar 2027: Unternehmen mit einem Vorjahresumsatz von mehr als 800.000 € müssen E-Rechnungen versenden.
- Ab 1. Januar 2028: Die E-Rechnungspflicht beim Versand gilt für alle Unternehmen im B2B-Sektor (Ende der Übergangsfristen).
Wir haben die neue JTL-Wawi 2.0 im Hinblick auf die E-Rechnungserstellung unter die Lupe genommen. Viele Händler stehen aktuell unter Zeitdruck: Wegen der neuen DHL-Versandschnittstelle 4.0 ist ein zeitnahes Update auf die neueste Wawi-Version ohnehin unumgänglich.
Wir haben daher in unserem Testsystem geprüft, wie die aktuelle Version mit unserem Addon zusammenspielt.
Funktionieren E-Rechnungen in der JTL-Wawi 2.0 fehlerfrei?
Ja. Wir haben die Version 2.0 intensiv mit unserem Addon hph.JTL.ZUGFeRD getestet. Das Ergebnis: Es sind keine Anpassungen an unserem Addon notwendig. Die gewohnte Stabilität bleibt erhalten.
Was ist beim Update auf JTL-Wawi 2.0 zu beachten?
Im Zusammenhang mit unserer E-Rechnungslösung gibt es einen wichtigen technischen Punkt:
Hinweis: Bei einem Update auf JTL-Wawi 2.0 muss der JTL-Worker neu installiert werden, da die bestehenden Dienste während des Update-Prozesses deinstalliert werden.
Wie sieht es mit ZUGFeRD und den JTL-Standardfunktionalitäten aus?
In der neuen Version gibt es eine aktualisierte JTL-Druckvorlage im neuen Tab „ZUGFeRD Version (2025.12.18)“. Diese umfasst ca. 1.000 Zeilen DotLiquid-XML-Code. Wir haben die Vorlage analysiert und getestet:
- Hoher Konfigurationsaufwand: Ein kritischer Punkt ist, dass viele Teile des Codes im Standard auskommentiert sind. Das bedeutet: Die Vorlage ist „out of the box“ nicht voll einsatzfähig.
- Manuelle Nacharbeit erforderlich: Der Anwender oder ein Servicepartner muss diese Segmente händisch prüfen, aktivieren und auf die individuellen Gegebenheiten anpassen. Ohne tiefgreifendes technisches Verständnis ist die Einrichtung kaum fehlerfrei möglich.
- Lücken im Standard: Aus unserer Sicht fehlen weiterhin essentielle Felder, um vollumfänglich korrekte E-Rechnungen zu erstellen. Es müssen viele Anpassungen vorgenommen werden, um die richtigen Daten aus der Datenbank in das XML zu integrieren.
- Keine Gutschriften: In den JTL-Standardvorlagen konnten wir bisher keine Möglichkeit finden, den ZUGFeRD- oder X-Rechnungsteil für Rechnungskorrekturen und Gutschriften zu konfigurieren.
- Der Vorteil mit hph.JTL.ZUGFeRD: Wir unterstützen bereits seit 2025 die Erstellung von E-Rechnungen für Rechnungen, Rechnungskorrekturen und Gutschriften – ohne dass Sie sich durch tausende Zeilen Code kämpfen müssen.
Validierung: Vorsicht bei der Prüfung
Auch die interne Validierungsfunktion der JTL-Wawi haben wir geprüft. Hier ist Vorsicht geboten:
- JTL nutzt intern den Kosit Validator in der Version 1.5
- Die aktuellste Version des Validators (Stand heute) ist die 1.6.2 vom Februar 2026.
- Fazit zur Validierung: Die interne Prüfung ist daher nicht wirklich aussagekräftig. Bei aktuellen E-Rechnungsversionen wird oft kein passendes Regelwerk erkannt.
Was sagen KIs zur neuen JTL-ZUGFeRD-Vorlage?
Wir haben die rund 1.000 Zeilen Code der aktuellen JTL-Standardvorlage (Version 2025.12.18) einer tiefgehenden KI-Analyse unterzogen. Das Urteil der „digitalen Kollegen“ fällt eindeutig aus – und deckt sich mit unseren Praxiserfahrungen:
Präzise, aber isoliert: Die KI lobt die mathematische Genauigkeit. Durch die Berechnung auf vier Nachkommastellen (Round: 4) werden Rundungsfehler im Vergleich zu alten Vorlagen minimiert. Doch die KI warnt sofort: Ohne die korrekte Anbindung der Kopfdaten (Summenbildung am Ende des Dokuments) bleibt diese Präzision wirkungslos.
„Skelett ohne Organe“: In der Analyse wird deutlich, dass die Vorlage zwar eine saubere Struktur für Positionen bietet, aber essentielle „Lebenszeichen“ einer E-Rechnung fehlen. Wichtige Blöcke für die Zahlungsweg-Identifikation (IBAN/BIC) und die Steuerzusammenfassung nach Kategorien sind im Code-Skelett zwar vorgesehen, aber oft nicht aktiv oder unvollständig gemappt.
Die „Kommentar-Falle“: Die KI identifiziert zahlreiche auskommentierte Sektionen (z. B. für Rabatte oder spezielle Steuerbefreiungen). Das Fazit der KI: „Die Vorlage ist technisch hochgradig fragil. Ein Laie, der versucht, diese Kommentare zu aktivieren, riskiert eine sofortige Invalidität des XML-Dokuments.“
Validierungs-Risiko: Da die Vorlage sich explizit auf den Standard XRechnung 3.0 beruft, sind die Anforderungen an die Vollständigkeit extrem hoch. Die KI weist darauf hin, dass die Vorlage in ihrem Rohzustand die strengen Schematron-Prüfungen der staatlichen Portale (z. B. ZRE) vermutlich nicht ohne manuelle Nacharbeit bestehen würde.
Quelle: Ergebnis des KI-Chats
Das KI-Fazit: Die Vorlage ist eine solide Basis für Entwickler, aber ein gefährliches Werkzeug für Endanwender. Die künstliche Intelligenz rät: Wer keine Wochen in das Debugging von Liquid-Code investieren will, sollte auf eine vorkonfigurierte Lösung setzen.
Fazit: Mit hph.JTL.ZUGFeRD auf der sicheren Seite
Während der JTL-Standard viel manuelle Arbeit und technisches Know-how (vor allem durch den auskommentierten Code) erfordert, bietet unser Addon eine Plug-and-Play-Lösung. Sie sparen Zeit, vermeiden Fehler bei der manuellen XML-Anpassung und decken auch Rechnungskorrekturen rechtssicher ab.