Wer als Onlinehändler „Gewinn je Artikel" sucht, findet vier Klassen von Werkzeugen, die alle „Übersicht" versprechen und Verschiedenes leisten. Dieser Vergleich nennt keine Anbieter — er sortiert nach Fragen: Welche Datenquellen fließen ein? Rechnet das Werkzeug DB3 je Artikel oder zeigt es Umsatz? Kennt es den Break-even je Kampagne, den Stockout, die Liquidität — und weiß es bei jeder Zahl, woher sie kommt? Die Tabelle steht zuerst, die Erklärung danach.
Stand 27.08.2026. Bewusst ohne Anbieternamen: Funktionen und Tarife ändern sich, die Klassen nicht. „Ja/Nein" beschreibt den typischen Vertreter der Klasse.
| Kriterium | Dashboard-Tool | Profit-Tracker | ERP-/WaWi-Report | Digitaler Zwilling (Modell) |
|---|---|---|---|---|
| Datenquellen | Ein System (meist der Shop), manchmal das Werbekonto daneben | Shop + Werbekonten + Zahlungsanbieter, per Schnittstelle | Nur das ERP: Belege, Bestände, Rechnungen | Shop, Werbekonten, Zahlungsanbieter, Warenwirtschaft — nur lesend |
| Gewinn je Artikel (DB3) | Nein — Umsatz, Bestellungen, Ø Bestellwert | Ja, als Kennzahl je Produkt; Retouren und Versandkosten meist als Pauschale | Rohertrag (VK − EK) je Artikel; keine Werbung, Gebühren, Retourenkosten | Ja — je Bestellung verrechnet: Ware, Versand, Gebühr, Retoure, Werbung |
| Break-even je Kampagne | ROAS aus dem Werbekonto, ohne Marge | Teils: ROAS gegen Zielmarge | Nein | Ja — Break-even-ROAS aus der Marge der beworbenen Artikel |
| Stockout / Meldebestand | Nein | Nein | Mindestbestand-Warnung; kein Sicherheitsbestand aus Absatzschwankung | Ja — Reserve aus Absatz- und Lieferzeitschwankung, Stockout-Kosten je Tag |
| Liquidität | Nein | Nein | Offene Posten, Fälligkeiten | Ja — 13 Wochen aus offenen Posten, Auszahlungsfristen, Einkauf, Werbebudget |
| Herkunft je Zahl | Eine Quelle, daher klar | Meist ohne Beleg je Zahl | Beleg je Buchung | Jede Zahl mit Quelle, Zeitpunkt und Annahme |
| Was passiert, wenn sich etwas ändert | Nichts — Anzeige | Neue Kennzahl | Neue Buchung | Modell rechnet neu: Auswirkung auf DB3, Break-even, Bestand, Liquidität |
| Hosting / Datenschutz | Beim Shop-Anbieter | Meist außerhalb der EU, Datenweitergabe an Werbeplattformen üblich | Beim ERP-Anbieter oder eigener Server | Entwickelt und gehostet in Deutschland, keine Weitergabe |
| Aufwand | Keiner — ist schon da | App installieren, Kosten je Produkt pflegen | Einrichtung und Pflege durch Buchhaltung | Quellen verbinden, Annahmen einmal prüfen — dann nächtlich automatisch |
| Passt für | Erste Orientierung, Tagesumsatz | Kleine Sortimente mit wenigen Kanälen | Belegführung, Lager, Buchhaltung | Händler mit mehreren Quellen, die Entscheidungen rechnen wollen |
Das Dashboard des Shopsystems ist die erste Quelle jedes Händlers — und die ehrlichste über das, was es kennt: Umsatz, Bestellungen, Ø Bestellwert, Bestseller, Besucher. Es rechnet nichts hinzu, was in einem anderen System entsteht. Zahlartgebühren werden beim Zahlungsanbieter einbehalten, Versandkosten stehen auf der Logistikrechnung, Werbung im Werbekonto, Retourenkosten im Lager. Ein Dashboard kann deshalb keinen Gewinn je Artikel zeigen; es zeigt Umsatz je Artikel und lässt den Rest offen. Für die Frage „Wie läuft der Tag?" reicht das. Für die Frage „Verdient dieser Artikel?" nicht — im Beispiel werden aus 8.611,76 € Bruttogewinn 147,43 € Ergebnis, und keine der Abzugszeilen steht im Dashboard.
Profit-Tracker-Apps setzen genau hier an: Sie holen Werbekosten aus den Werbekonten und Gebühren vom Zahlungsanbieter, rechnen sie gegen den Umsatz und zeigen einen Netto-Gewinn je Tag und je Produkt. Das ist ein echter Fortschritt gegenüber dem Dashboard. Die Grenze liegt in der Herkunft der Zahlen: Einkaufspreise werden je Produkt gepflegt statt aus Einkaufsbelegen gelesen, Versand- und Retourenkosten laufen als Pauschale, Bestände und Lieferzeiten kommen nicht vor. Ein Profit-Tracker beantwortet „Wie viel ist gestern geblieben?". Er beantwortet nicht „Was passiert mit dem Ergebnis, wenn die Retourenquote von 10 auf 20 % steigt?" — das wären im Beispiel 6,41 € statt 3,54 € DB3 je Bestellung, und diese Rechnung braucht ein Modell, keine Kennzahl. Dazu kommt, dass viele dieser Apps außerhalb der EU gehostet sind und Daten an Werbeplattformen zurückspielen.
Die Warenwirtschaft ist die verlässlichste Quelle für Einkaufspreise, Bestände und offene Posten — jede Zahl hat einen Beleg. Ihre Reports rechnen den Rohertrag je Artikel korrekt: Verkaufspreis netto minus Einkaufspreis. Was sie nicht rechnen, weil es nicht im ERP entsteht: Werbekosten je Artikel, Zahlartgebühren je Bestellung, Retourenkosten als Vollkosten, Break-even je Kampagne. Im Beispiel liegen zwischen 21,53 € Rohertrag und 6,41 € DB3 vier Abzüge, die in keiner Warenwirtschaft je Artikel gebucht sind (Ratgeber). Der Mindestbestand des ERP ist eine gepflegte Zahl, kein Sicherheitsbestand aus Absatz- und Lieferzeitschwankung.
Ein digitaler Zwilling liest alle vier Quellen — Shop, Werbekonten, Zahlungsanbieter, Warenwirtschaft — nur lesend und verrechnet sie je Bestellung: Ware aus dem Einkaufsbeleg, Gebühr aus dem Tarif des Zahlungsanbieters, Versand aus der Logistikrechnung, Retoure als Erwartungswert je Artikel, Werbung aus dem Werbekonto. Daraus entstehen DB3 je Artikel, Break-even-ROAS je Kampagne, Sicherheits- und Meldebestand je Artikel und eine Liquiditätsvorschau — jede Zahl mit Quelle, Zeitpunkt und Annahme. Der Unterschied zu den drei anderen Klassen ist nicht die Menge der Kennzahlen, sondern dass die Zahlen zusammenhängen: Ändert sich die Retourenquote, ändern sich DB3, Kipppunkt, Break-even-ROAS und die Bestellungen, die für die Fixkosten nötig sind — im Beispiel 391 statt 708, wenn die Quote von 10 auf 20 % steigt. Das ist die Klasse, in der de_core arbeitet; der Vergleich ist trotzdem ehrlich gemeint: Wer nur einen Shop und wenige Artikel hat, braucht dieses Modell nicht.
Nein. Der Profit-Tracker kennt Werbekosten und Gebühren, die Warenwirtschaft kennt Einkaufspreise aus Belegen, Bestände und offene Posten. Beide zusammen sind die Quellen; keines von beiden rechnet den DB3 je Artikel aus allen Kosten. Das ist der Platz des Modells.
Für Umsatz und Bestellungen ja. Für den Gewinn je Artikel fehlen Zahlartgebühr, Versandkosten, Retourenkosten und Werbung — im Beispiel 15,12 € je Bestellung bei 33,53 € Netto-Erlös. Mit dem kostenlosen Deckungsbeitrags-Rechner lässt sich das für einzelne Artikel nachrechnen; ein Modell lohnt erst ab mehreren Quellen.
Der Zusammenhang. Ein Dashboard zeigt Kennzahlen nebeneinander; ein Modell rechnet sie auseinander hervor: Aus Retourenquote, Einkaufspreis, Gebühr und Werbung folgt DB3, daraus Break-even-ROAS und die Bestellungen, die für die Fixkosten nötig sind. Ändert sich eine Eingangsgröße, ändern sich alle abhängigen Zahlen — mit Herkunft.
Weil sich Tarife, Funktionen und Hosting-Orte monatlich ändern und ein Anbietervergleich in wenigen Wochen veraltet wäre. Die vier Klassen und die Fragen dahinter bleiben stabil. Für einen konkreten Anbieter lassen sich die zehn Kriterien der Tabelle in einer Viertelstunde prüfen.
Eine Nacht mit de_core
Sonntag 22:40 senkt der Marktführer den Preis. Montag 06:12 liegt ein Brief da — die ganze Nacht, mit Zeitstempeln.
Kennzahlenbaum Onlineshop
Alle Kennzahlen als eine Rechnung — vom Besucher bis zur Auszahlung.
Deckungsbeitrags-Rechner (DB1–DB3)
Ein Artikel, drei Stufen, Kanalvergleich Shop gegen Marktplatz.
Ratgeber: KI, die rechnet
Generative gegen entscheidende KI — drei Rechnungen, die Sprache nicht löst.
Lexikon: Digitaler Zwilling
Definition, Aufbau, Beispiel — was ein Modell des Geschäfts ist.
Die Klasse 4 kannst du sieben Tage lang prüfen.
Shop verbinden, Sofort-Befund lesen, DB3 je Artikel sehen. Nur lesend, ohne Zahlungsdaten, jederzeit trennbar.