JTL Marge je Auftrag auswerten: 4 Wege im Vergleich
Deckungsbeitrag je Auftrag in JTL-Wawi sichtbar machen: vom SQL-Report über Ameise und JTL-BI bis zum automatischen Margen-Wächter. Stärken, Grenzen und wann sich was lohnt.
Die meisten JTL-Händler kennen ihren Umsatz auf den Cent genau. Ihre Marge je Auftrag kennen sie nicht. Das ist gefährlich: Ein wachsender Umsatz mit schrumpfender Marge fühlt sich gut an und ruiniert trotzdem das Geschäft. Die Daten liegen längst in deiner JTL-Datenbank. Die Frage ist nur, wie du sie verlässlich, regelmäßig und ohne Handarbeit herausziehst.
Hier sind vier Wege, den Deckungsbeitrag je Auftrag in JTL-Wawi auszuwerten: von „schnell, aber fragil" bis „automatisch und proaktiv".
Warum „Marge je Auftrag" und nicht „Marge je Artikel"
Die Artikelmarge im Stammdatensatz ist eine Momentaufnahme. Sie ignoriert, was im echten Auftrag passiert:
- Rabatte & Gutscheine drücken den Verkaufspreis unter die kalkulierte Marge.
- Versandkosten, die du nicht voll weitergibst, fressen den Deckungsbeitrag.
- Zahlungsgebühren (PayPal, Klarna, Kreditkarte) sind je Auftrag unterschiedlich hoch.
- Plattformprovisionen (Amazon, eBay, Kaufland) machen denselben Artikel je Kanal unterschiedlich rentabel.
- Retouren drehen eine positive Marge nachträglich ins Negative, inklusive Wiedereinlagerungsaufwand.
Erst auf Auftragsebene siehst du, was wirklich hängenbleibt. Genau diese Ebene ist in JTL-Wawi am schwersten zugänglich. Und am wertvollsten.
Weg 1: Direkter SQL-Report auf die JTL-Datenbank
Der schnellste Weg zur Wahrheit führt über die SQL-Datenbank. Auftragspositionen
(tBestellpos), Einkaufspreise und Auftragskopf liefern alles, was du für den
Deckungsbeitrag brauchst. Eine Abfrage, die je Auftrag Verkaufserlös minus
Wareneinsatz minus Versand minus Gebühren rechnet, ist in einer Stunde gebaut.
Stärken: maximale Präzision, jede Kennzahl frei definierbar, keine Lizenzkosten.
Grenzen: Du brauchst SQL-Kenntnisse und Lesezugriff auf die DB. Der Report ist statisch: Du musst ihn jedes Mal aktiv ausführen. Und ein falsch gesetzter JOIN liefert lautlos falsche Zahlen, ohne dass es jemand merkt.
Faustregel: SQL-Reports sind ideal für die einmalige Analyse. Für laufende Überwachung sind sie ein schlechtes Werkzeug, weil niemand jeden Morgen ein Skript startet.
Weg 2: Export über die Ameise + Auswertung in Excel
Die JTL-Ameise exportiert Aufträge und Positionen als CSV. In Excel oder Google Sheets baust du dann mit Pivot-Tabellen deine Margenauswertung.
Stärken: kein SQL nötig, vertrautes Werkzeug, flexibel formatierbar.
Grenzen: Es ist und bleibt Handarbeit. Jeder Export ist ein neuer Datenstand, jede Formel eine potenzielle Fehlerquelle, und nach drei Monaten weiß niemand mehr, wie die Tabelle eigentlich rechnet. Spätestens ab ein paar tausend Aufträgen wird Excel zäh und unzuverlässig.
Weg 3: JTL-BI / Power BI Dashboards
Mit JTL-BI oder einem Power-BI-Modell auf der JTL-Datenbank bekommst du hübsche, aktualisierbare Dashboards. Die Marge je Auftrag lässt sich als Measure modellieren und über Zeit, Kanal oder Kategorie filtern.
Stärken: visuell stark, reproduzierbar, gut für Reporting an Stakeholder.
Grenzen, und das ist der entscheidende Punkt: BI ist rückblickend. Es zeigt dir, was passiert ist. Du musst das Dashboard öffnen, die richtige Ansicht wählen und selbst erkennen, dass eine Zahl aus dem Rahmen fällt. Reporting beantwortet die Frage „Wie war es?". Es stellt nie von selbst die Frage „Hier stimmt etwas nicht, willst du handeln?".
Weg 4: Automatischer Margen-Wächter (proaktiv)
Der vierte Weg dreht die Logik um. Statt dass du Daten holst, kommen die Erkenntnisse zu dir. Ein Margen-Wächter überwacht jeden Auftrag kontinuierlich, rechnet den echten Deckungsbeitrag (inklusive Rabatt, Versand, Zahlungsgebühren und Plattformprovision) und meldet sich nur, wenn etwas aus dem Rahmen fällt:
- Auftrag unter Ziel-Marge → Alert mit konkretem Artikel und Ursache.
- Artikel, dessen EK gestiegen ist, aber dessen VK seit Monaten gleich blieb.
- Kanal oder Kunde, dessen Margen-Mix kippt.
Genau das ist der Ansatz hinter WARP: kein weiteres Dashboard, das auf dich wartet, sondern ein Margen-Wächter, der proaktiv warnt und korrigierte Werte auf deine Freigabe direkt zurück nach JTL-Wawi schreibt (Writeback), statt nur darauf hinzuweisen. Retouren wertet WARP als eigene Ansicht aus; die automatische Verrechnung der Retourenquote je Verkaufskanal steht auf der Roadmap.
Stärken: kein Mensch muss daran denken; Probleme werden gefunden, bevor sie teuer werden; die Handlung ist Teil des Systems.
Grenzen: Du gibst etwas Kontrolle ab und brauchst klare Schwellenwerte und Freigaben, gerade beim automatischen Zurückschreiben.
Welcher Weg für wen?
| Situation | Empfehlung |
|---|---|
| Einmalige Tiefenanalyse | SQL-Report (Weg 1) |
| Gelegentlich, ohne SQL | Ameise + Excel (Weg 2) |
| Regelmäßiges Reporting an Dritte | JTL-BI / Power BI (Weg 3) |
| Laufende Überwachung + Handlung | Margen-Wächter (Weg 4) |
Die ersten drei Wege beantworten die Frage „Wie war meine Marge?". Nur der vierte beantwortet die eigentlich wichtige Frage: „Wo verliere ich gerade Geld und was tue ich jetzt dagegen?"