Die E-Rechnung ist seit 2025 nicht mehr nur eine Zukunftsoption, sondern ein fester Bestandteil der Geschäftspraxis für Onlinehändler und Unternehmen in Deutschland. Wer mit JTL-Wawi arbeitet, kann diesen Prozess systematisch automatisieren und damit Zeit sparen, Fehler reduzieren und gesetzliche Anforderungen erfüllen.
In diesem Artikel zeigen wir dir, wie du JTL-Wawi für die E-Rechnung nutzt, welche Formate sinnvoll sind, wie du die Automatisierung aufbaust und worauf du im laufenden Betrieb achten solltest. Der Fokus liegt auf praxisnahen Lösungen mit messbaren Ergebnissen für dein E-Commerce-Team – mit klaren KPIs, einem Messplan und Verantwortlichkeiten nach dem RACI-Modell.
Eine E-Rechnung ist eine strukturierte elektronische Rechnung, die Maschinen direkt verarbeiten können. Sie besteht aus standardisierten Datenformaten wie XRechnung oder ZUGFeRD und ermöglicht es, Rechnungsprozesse von der Erstellung bis zur Buchhaltung zu automatisieren. JTL-Wawi kann diese Formate erzeugen, versenden und archivieren, ohne dass manuelle Zwischenschritte nötig sind. Während eine klassische PDF-Rechnung nur für Menschen lesbar ist, enthält eine E-Rechnung strukturierte Daten, die Buchhaltungssysteme, Behördenportale oder ERP-Lösungen direkt einlesen können.
Seit dem 1. Januar 2025 gilt in Deutschland die schrittweise Einführung der E-Rechnungspflicht. Unternehmen sollten sich inzwischen mit der praktischen Umsetzung im Tagesgeschäft beschäftigen. Das ist nicht nur eine technische Aufgabe, sondern auch eine organisatorische: Datenqualität, Prozesslogik, Versand und Archivierung müssen zusammenpassen.
Für E-Commerce-Unternehmen mit JTL-Wawi bedeutet das konkret messbare operative Auswirkungen: Die Reduktion von Supportaufwand durch weniger Rückfragen zu Rechnungsformaten, die Eliminierung von manuellen Nacharbeiten bei fehlerhaften Rechnungen, die Senkung der Prozessdurchlaufzeiten von der Rechnungserstellung bis zum Versand und die Überwachung von Fehlerquoten als operatives KPI. Für die E-Commerce-Leitung ist entscheidend, dass Rechnungen in den richtigen Formaten erzeugt werden, je nachdem, wer der Empfänger ist. Für die Buchhaltung ist wichtig, dass Rechnungen sauber archiviert und übergeben werden. Für die IT ist klar, dass die Infrastruktur zuverlässig funktionieren muss.
Wer diese Anforderungen ignoriert, riskiert Compliance-Probleme, manuelle Nacharbeiten und fehlende Transparenz. Wer sie strukturiert angeht, gewinnt Effizienz, Sicherheit und Skalierbarkeit.
Es gibt mehrere E-Rechnungsformate. Die wichtigsten sind:
XRechnung ist ein reines XML-Format, das vor allem für Behörden und öffentliche Auftraggeber verwendet wird. Es ist strukturiert, maschinenlesbar und wird über spezielle Portale wie das OZG-RE-Portal versendet. Wenn ein Kunde eine Leitweg-ID hat, ist XRechnung oft das richtige Format. Der Versand erfolgt entweder über ein Behördenportal oder per E-Mail an eine spezifische Empfängeradresse. Die Risiken und Abhängigkeiten liegen in der korrekten Erfassung der Leitweg-ID und der Einhaltung der spezifischen Versandwege pro Behörde. Die Eskalationslogik muss vorsehen, dass bei fehlerhaften Leitweg-IDs oder Versandfehlern eine Benachrichtigung an das Buchhaltungs-Team erfolgt.
ZUGFeRD kombiniert ein lesbares PDF mit eingebetteten strukturierten XML-Daten. Das macht es praktisch für B2B-Kunden, die eine lesbare Rechnung brauchen, aber auch die Möglichkeit haben sollen, die Daten maschinell zu verarbeiten. ZUGFeRD ist hybrid und flexibel. Der Versand erfolgt per E-Mail an die Kundenadresse. Die Abhängigkeit liegt in der korrekten Einbettung der XML-Daten ins PDF und der Validierung des Gesamtformats. Die Eskalationslogik sollte vorsehen, dass bei Validierungsfehlern auf Standard-PDF ausgewichen wird.
Für Privatkunden oder wenn keine E-Rechnung erforderlich ist, bleibt das Standard-PDF eine Option. Die Automatisierung kann dann diesen Prozess überspringen oder auf PDF umstellen.
Die Wahl des Formats hängt vom Empfängertyp, der Leitweg-ID und dem Land ab. Eine gute Automatisierung trifft diese Entscheidung datengesteuert, nicht manuell.
| Format | Empfängertyp | Struktur | Versandweg | Lesbarkeit |
|---|---|---|---|---|
| XRechnung | Behörden, öffentliche Auftraggeber | Reines XML | Behördenportal oder E-Mail mit Eskalationslogik | Nur für Maschinen |
| ZUGFeRD | B2B-Kunden, Geschäftspartner | PDF + eingebettetes XML | E-Mail mit Fallback-Logik | PDF lesbar, XML strukturiert |
| Standard-PDF | Privatkunden, Standardfälle | Nur PDF | Für Menschen lesbar |
Diese Tabelle zeigt, dass die Formatwahl nicht willkürlich ist, sondern von klaren Kriterien abhängt. Eine automatisierte Lösung prüft diese Kriterien und wählt das passende Format aus. Der Versandweg ist dabei eng an die Eskalationslogik gekoppelt: Wenn ein Versand fehlschlägt, muss klar sein, wer benachrichtigt wird und welche Schritte folgen.
Die Umsetzung folgt einer klaren Reihenfolge: Erst die Daten prüfen, dann die Logik definieren, dann die Infrastruktur vorbereiten, dann automatisieren und schließlich testen.
Bevor du Automatisierung aufbaust, müssen die Kundenstammdaten sauber sein. Das bedeutet konkret:
Fehlerhafte oder unvollständige Daten führen zu Prozessabbrüchen oder falschen Formatentscheidungen. Datenqualität ist die Grundlage.
JTL-Wawi benötigt korrekte Speicherpfade für die erzeugten Rechnungs-PDFs. Der Pfad sollte angepasst werden, damit der JTL-Wawi-Worker-Server darauf zugreifen kann. Wenn du bereits eine Speicherung nutzt, kannst du mit DotLiquid den Pfad für den Worker anpassen.
Das PDF-Format sollte auf PDF/A-3b umgestellt werden. Das ist wichtig für die Langzeitarchivierung und für die Einbettung strukturierter Daten. Schriftarten müssen korrekt eingebettet sein.
Der SQL-ConnectionString muss korrekt konfiguriert sein, damit die Verarbeitung auf dem Server läuft und nicht auf dem Client-PC.
Ein Rechnungs-Workflow wird beim Festschreiben einer Rechnung ausgelöst. Das ist der Moment, in dem die Automatisierung startet. Die Verzögerung (z. B. 5 Minuten) sorgt dafür, dass die Verarbeitung auf dem JTL-Worker-Server läuft, nicht lokal am Arbeitsplatz.
Die Formatwahl erfolgt über eine DotLiquid-Formel, die Kundeneigenschaften prüft. Wenn eine Leitweg-ID vorhanden ist, wird XRechnung gewählt. Wenn der Kunde eine Firma ist und aus Deutschland kommt, wird ZUGFeRD gewählt. Sonst wird der Prozess übersprungen oder auf Standard-PDF umgestellt.
Nach der Erzeugung wird die Datei validiert. Wenn die Validierung fehlschlägt, kann der Workflow auf das Standard-PDF ausweichen. Das ist die Fallback-Logik, die Prozesssicherheit schafft.
Der Versand erfolgt automatisiert über den Workflow. Die richtige Datei (XML oder PDF) wird zum richtigen Empfänger geschickt. Gleichzeitig wird die Rechnung in einem Zielverzeichnis archiviert, das später für den Export via JTL2Datev genutzt wird.
Aus der Praxis kennen wir häufige Fehlerquellen, die den Betrieb verlangsamen:
Fehlende oder falsch gepflegte Kundendaten sind die häufigste Ursache für Prozessabbrüche. Eine Leitweg-ID kann nicht gefunden werden, das Land ist nicht gesetzt, oder der Firmenname fehlt. Das führt zu manuellen Nacharbeiten und erhöht den Supportaufwand.
Wenn die Logik nicht richtig definiert ist, erhalten Behörden das falsche Format oder Geschäftskunden ein Format, das sie nicht verarbeiten können. Das führt zu Rückfragen und Verwirrung.
Falsche Speicherpfade, fehlende Schreibrechte, Datenbankverbindungsfehler oder Worker-Probleme führen dazu, dass Rechnungen gar nicht erzeugt werden. Das ist ein technisches Problem, das vor dem Livegang behoben sein muss.
Wenn Rechnungen nicht validiert werden, können fehlerhafte Dateien versendet werden. Das führt zu Ärger bei Empfängern und zu Compliance-Problemen.
Wenn vor dem Livegang nicht mit echten Testdaten und typischen Empfängerkonstellationen getestet wird, entstehen Probleme erst im produktiven Betrieb. Das ist dann schwer nachzuvollziehen und zu beheben.
Wenn nicht klar ist, wer für Monitoring, Fehlerbehandlung und Prozessüberwachung zuständig ist, fallen Probleme zu spät auf oder werden übersehen. Ohne explizite Monitoring- und Eskalationslogik können Fehler tagelang unbemerkt bleiben. Die Eskalationslogik muss definieren: Wer wird bei welchem Fehler benachrichtigt? Welche Fehler sind kritisch, welche sind Warnungen? Wie werden Fehlerquoten gemessen und wann wird eingegriffen? Typische Messwerte sind: Fehlerquote pro Tag (Zielwert unter 2%), Durchlaufzeit vom Festschreiben bis zum Versand (Zielwert unter 10 Minuten), Anteil der Fallbacks auf Standard-PDF (Zielwert unter 5%), Anzahl der Supporttickets zu Rechnungsformaten (Zielwert: Reduktion um mindestens 70%), und Audit-Readiness (100% der Rechnungen müssen nachvollziehbar archiviert sein). Die Verantwortlichkeiten sollten nach dem RACI-Modell definiert werden: Wer ist Responsible (führt die Überwachung durch), Accountable (trägt die Gesamtverantwortung), Consulted (wird hinzugezogen) und Informed (wird benachrichtigt).
Die Formatwahl sollte automatisiert erfolgen, basierend auf klaren Regeln. Hier ist ein Entscheidungsmodell:
| Bedingung | Format | Umsetzungsregel | Konsequenz bei Fehler | KPI-Messung |
|---|---|---|---|---|
| Privatkunde oder Nicht-DE-Land | Standard-PDF oder SKIP | Prozess überspringen oder PDF-Versand aktivieren | Keine E-Rechnung erforderlich, Standard-Versand | Durchlaufzeit unter 5 Minuten |
| Leitweg-ID vorhanden und validiert | XRechnung | XML erzeugen, Versand über Behördenportal oder E-Mail mit Eskalation bei Fehler | Bei ungültiger Leitweg-ID: Benachrichtigung an Buchhaltung, Fallback auf PDF | Fehlerquote unter 1%, Durchlaufzeit unter 10 Minuten |
| Firmenkunde, DE, keine Leitweg-ID | ZUGFeRD | PDF mit eingebettetem XML erzeugen, Validierung durchführen, E-Mail-Versand | Bei Validierungsfehler: Fallback auf Standard-PDF, Fehler protokollieren | Fehlerquote unter 2%, Fallback-Anteil unter 5% |
Diese Logik wird in DotLiquid-Formeln abgebildet und sorgt dafür, dass die Entscheidung automatisch und konsistent erfolgt. Das reduziert manuelle Fehler und spart Zeit. Die Umsetzungsregel definiert nicht nur das Format, sondern auch den konkreten Versandweg und die Fehlerbehandlung. Die Konsequenz bei Fehler macht klar, welche Fallback-Aktion eintritt und wer informiert wird. Die KPI-Messung zeigt, welche Zielwerte für jede Formatvariante gelten und wie der Erfolg gemessen wird.
Eine gute E-Rechnungslösung mit JTL-Wawi hat folgende Merkmale:
Eine Lösung, die diese Merkmale erfüllt, reduziert operative Reibung und schafft Vertrauen in den Prozess.
Vor der Aktivierung sollten diese Punkte überprüft werden:
Diese Checkliste sichert ab, dass die Lösung vor dem Livegang wirklich bereit ist.
Seit Januar 2025 gilt die E-Rechnungspflicht schrittweise. Für B2B-Rechnungen ist sie bereits verpflichtend, wenn der Empfänger es verlangt. Für Behörden ist sie oft bereits Pflicht. Wer jetzt nicht handelt, wird bald dazu gezwungen. Es ist sinnvoll, die Umsetzung proaktiv anzugehen.
Ja, aber nicht für die gleiche Rechnung. Die Formatwahl erfolgt pro Empfänger. Behörden erhalten XRechnung, B2B-Kunden erhalten ZUGFeRD. Die Automatisierung trifft diese Entscheidung.
Mit einer Fallback-Logik wird auf Standard-PDF ausgewichen. Die Rechnung wird versendet, aber in einem anderen Format. Das ist besser als ein Versandstopp. Die Fehlerursache sollte aber protokolliert und später behoben werden.
Das hängt vom Setup ab. Mit klaren Anforderungen, sauberen Daten und einer strukturierten Vorgehensweise dauert es meist 2-4 Wochen bis zum Livegang. Ohne Vorbereitung kann es Monate dauern.
Das hängt von deinem internen Know-how ab. Die Grundlagen sind mit JTL-Wawi machbar. Für komplexe Logiken, Validierungen und Monitoring kann externe Unterstützung sinnvoll sein.
Durch Protokolle, Statusmeldungen und regelmäßige Kontrolle. Wichtige Kennzahlen sind: Fehlerquote (Zielwert unter 2%), Durchlaufzeit (Zielwert unter 10 Minuten), Anteil Fallbacks (Zielwert unter 5%), Supportticket-Reduktion (Zielwert mindestens 70% weniger Tickets zu Rechnungsformaten) und Audit-Readiness (100% Archivierungsquote). Wer diese regelmäßig prüft, erkennt Probleme früh. Die Monitoring-Logik sollte automatisiert sein und bei kritischen Fehlern eine Benachrichtigung auslösen. Ein täglicher Report sollte zeigen: Rechnungsvolumen pro Format, aktuelle Fehlerquote, durchschnittliche Durchlaufzeit, Fallback-Anteil und offene Supporttickets.
Nach dem RACI-Modell: E-Commerce-Leitung ist Accountable für die Gesamtverantwortung und wird täglich informiert. Der Rechnungs-Administrator ist Responsible für die tägliche Überwachung und Fehlerbehandlung. Die IT ist Consulted bei technischen Problemen. Die Buchhaltung ist Informed über Archivierungsstatus und wird bei kritischen Fehlern benachrichtigt.
Die E-Rechnung mit JTL-Wawi ist kein Hexenwerk, wenn die Umsetzung strukturiert erfolgt. Datenqualität, klare Formatlogik, zuverlässige Infrastruktur, explizite Monitoring- und Eskalationslogik, messbare KPIs, ein klarer Messplan und definierte Verantwortlichkeiten sind die Hebel. Wer diese richtig setzt, gewinnt Effizienz, Sicherheit und Compliance – mit messbaren Ergebnissen.