Marktplatz Kosten berechnen mit t4data.cloud Datawarehouse – vom Umsatz zum belastbaren Deckungsbeitrag
Viele Händler sehen auf dem Dashboard einen starken Marktplatz-Umsatz und schließen daraus auf Erfolg. Wer Marktplatz Kosten berechnen will, braucht aber mehr als Erlöse: Wareneinsatz, Provisionen, Versand, Zahlungsgebühren, Fulfillment, Retouren und – soweit verfügbar – Gemeinkosten.
Genau hier setzt t4data.cloud Datawarehouse an: Es führt Daten aus JTL-Wawi, Marktplätzen und der Kostenpflege im Portal zusammen und macht Auswertungen nach Marktplatz, Auftrag und Artikel möglich – ohne die Illusion vollständiger Kostentransparenz.
1. Warum Umsatz noch nichts über Rentabilität aussagt
2. Welche Kosten ein Marktplatzauftrag tatsächlich verursacht
3. Warum die benötigten Daten in verschiedenen Systemen liegen
4. So führt t4data.cloud Datawarehouse die Daten zusammen
5. Vom Umsatz zum Deckungsbeitrag
6. Auswertung nach Marktplatz, Auftrag und Artikel
7. Praxisbeispiel aus einem realen Datawarehouse-Projekt
8. Welche Entscheidungen dadurch möglich werden
9. Grenzen und fehlende Daten
10. FAQ
Umsatz ist eine Erlösgröße. Er beantwortet nicht, was nach allen zurechenbaren Kosten übrig bleibt. Ein Kanal mit hohem GMV kann nach Provision, Versand und Retouren schlechter abschneiden als ein umsatzschwächerer Kanal mit stabiler Marge.
Deshalb trennen wir begrifflich klar: Umsatz (Erlös), Rohertrag (Erlös minus Wareneinsatz), Deckungsbeitrag (nach weiteren variablen bzw. auftragsbezogenen Kosten) und Ergebnis (nach periodischen Gemeinkosten, soweit diese gepflegt und zugeordnet werden).
Wer nur Umsatzberichte steuert, riskiert Fehlentscheidungen: Sortimente werden ausgebaut, obwohl sie nach Kosten negativ wirken – oder Kanäle werden abgeschaltet, obwohl sie nach Deckungsbeitrag tragen.
Die Grafik zeigt das Prinzip relativ: Marktplatz C kann beim Umsatz führend sein und beim Deckungsbeitrag trotzdem das Schlusslicht. Absolute Euro-Beträge hängen vom jeweiligen Datenbestand ab und werden hier bewusst nicht behauptet.
Ein Marktplatzauftrag trägt selten nur „die Provision“. Typischerweise wirken mehrere Kostenblöcke – mit unterschiedlicher Zurechenbarkeit und unterschiedlicher Datenquelle.
Dazu zählen in der Praxis vor allem: Verkaufserlös (ggf. nach Rabatten/Erstattungen), Wareneinsatz bzw. Einstandspreis aus der Warenwirtschaft, Verkaufsprovision und weitere Plattformgebühren, Versand- und Fulfillmentkosten sowie Zahlungsgebühren – sofern sie als auftragsbezogene Kosten gepflegt oder aus Abrechnungsberichten abgeleitet werden. In t4data.cloud werden solche Positionen als auftragsbezogene Kosten (Portal → Sync ins Datawarehouse) modelliert; Typen und Attribute decken u. a. Versand, Plattform, Payment und Fulfillment ab.
Periodische Gemeinkosten (z. B. monatliche Beträge mit Abrechnungsperiode) werden im Portal gepflegt und ins Datawarehouse synchronisiert. Sie sind nicht automatisch „pro Auftrag wahr“, sondern werden in Auswertungen als Gemeinkostenblock berücksichtigt. Wer hier anteilig auf Kanäle oder Artikel verteilt, arbeitet mit einer Annahme – das muss in der Interpretation sichtbar bleiben.
Retouren, Gutschriften und nachträgliche Marktplatzgebühren können frühere Bewertungen ändern. Werbekosten, Lagerkosten oder interne Betriebskosten sind nur dann belastbar, wenn sie geliefert und gepflegt werden – sie sind nicht pauschal „automatisch vollständig“ vorhanden. Fehlen Daten, entsteht eine Lücke im Deckungsbeitrag, keine Scheingenauigkeit.
Die JTL-Wawi kennt Aufträge, Artikel und typischerweise Einkaufs-/Einstandswerte. Marktplätze und Abrechnungsberichte liefern Gebühren, Erstattungen und oft zeitversetzte Korrekturen. Werbekosten sitzen in Ads-Konten. Gemeinkosten und kalkulatorische Sätze pflegen Händler häufig manuell.
Kein Einzelsystem beantwortet zuverlässig: Was verdient ein Händler nach allen zurechenbaren Kosten mit einem Marktplatz, einem Auftrag, einem Artikel oder einem Vertriebskanal?
Deshalb braucht es eine gemeinsame Auswertungsebene – und eine ehrliche Kennzeichnung, welche Kostenblöcke belegt sind und welche fehlen. Mehr zur Kanalwahl ohne Kostenillusion finden Sie auch im Beitrag Marktplatz vs. Online-Shop.
Die t4data.cloud Datawarehouse bündelt Daten aus Warenwirtschaft, Shops, Marktplätzen und weiteren Anwendungen. Über das t4data.cloud Portal werden Gemeinkosten, auftragsbezogene Kosten und Abrechnungsberichtsquellen an das Datawarehouse übermittelt und anschließend in Power BI bzw. im nativen Dashboard ausgewertet.
Zusätzlich unterstützen Konfigurationsdaten wie Preis- und Gewichtsgruppen sowie Plattformkosten-Gruppen das Matching und die Zuordnung von Kosten. Auswertungen sind u. a. nach Zeitraum, Plattform/Vertriebskanal, Auftrag, Artikel, Hersteller und Lieferant möglich – inklusive DB-II-Analysen und Retourenauswertungen.
Technisch wichtig: Kostenpflege und Sync ersetzen keine manuelle Verantwortung. Wenn Kostenzeilen fehlen, nicht aktiv sind oder der Sync nicht greift, bleibt die Auswertung unvollständig – das ist ein Datenqualitäts-Thema, kein „automatischer Vollständigkeitsanspruch“.
Details zur klassischen DB-II-Darstellung in Power BI beschreibt der Beitrag DB-II-Analyse mit Power BI. Der vorliegende Text setzt den Fokus auf Marktplatz-Kostenlogik und Datenintegration.
Ein fachlich sauberes Modell – nur mit belegten Bestandteilen – sieht so aus:
1. Verkaufserlös (ggf. nach Rabatten/Erstattungen; Steuerbehandlung in Berichten klar trennen).
2. Wareneinsatz / Einstand → Rohertrag.
3. Auftragsbezogene Kosten (Provision/Plattform, Versand, Zahlung, Fulfillment u. a., soweit gepflegt/zugeordnet) → Deckungsbeitrag.
4. Periodische Gemeinkosten (soweit gepflegt) → Ergebnisbetrachtung auf Periodenebene.
Kennzeichnung: Direkt zurechenbar sind Positionen, die einem Auftrag oder Artikel zugeordnet werden können. Gemeinkosten sind periodisch und oft nur verteilt. Nachträgliche Kosten (Retouren, Korrekturen) ändern historische Snapshots. Nicht verfügbare Kosten (z. B. nicht gelieferte Ads-Kosten) müssen als Lücke ausgewiesen werden – nicht als null.
Umsatzsteuer ist keine „Gewinnkostenposition“ im Sinne des Deckungsbeitrags, sondern eine steuerliche Größe. In Auswertungen sollte Netto-/Brutto-Logik konsistent sein, sonst entsteht Scheingenauigkeit.
Wer Retouren und Gutschriften ignoriert, überschätzt die Rentabilität systematisch. Das Retourendashboard und kanalbezogene Retourenkennzahlen helfen, diesen Effekt sichtbar zu machen – siehe auch Retourenmanagement mit Power BI.
Sobald Erlöse und verfügbare Kosten im Datawarehouse liegen, lässt sich die Frage operationalisieren: Welcher Marktplatz trägt nach Kosten? Welche Aufträge sind knapp oder negativ? Welche Artikel sind Umsatzstars ohne Deckungsbeitrag?
Typische Sichten – belegt über die Produktseite und DB-II-Boards – umfassen Plattform-/Kanalvergleiche, Monatsvergleiche, auftragsbezogene und artikelbezogene Analysen sowie Auswertungen nach Hersteller und Lieferant.
Unrentable Artikel oder Kanäle erkennt man nicht am Umsatzrank, sondern an negativem oder chronisch niedrigem Deckungsbeitrag bei belastbarer Datenlage. Die Konsequenz kann Preis, Sortiment, Fulfillment-Modell oder Kanalstrategie betreffen – nie „automatisch auslisten“ ohne Kontext.
Drill-down heißt: Marktplatz → Zeitraum → Auftrag → Artikel. Jede Stufe braucht dieselben Kostenregeln, sonst bricht die Vergleichbarkeit.
Hinweis zur Kundenregel: Für den beschriebenen Anwendungsfall (Marktplatz-Rentabilität / Deckungsbeitrag über Datawarehouse) liegt keine passende veröffentlichte Success Story vor. Das Beispiel bleibt daher vollständig anonymisiert. Vorhandene Success Stories zu Marktplatz-Middleware (z. B. Anbindung/Synchronisation) decken diesen Fall nicht ab und werden hier nicht als Beleg für Kostentransparenz genannt.
1. Ausgangslage: Ein Multichannel-Händler mit JTL-Wawi konnte Umsatz und Bestellvolumen je Marktplatz sehen, aber nicht zuverlässig entscheiden, welcher Kanal nach Kosten trägt. Excel-Exporte aus verschiedenen Portalen waren zeitversetzt und nicht auftragsfein abgleichbar.
2.–3. Systeme und Zusammenführung: Anbindung der Warenwirtschaftsdaten, Marktplätze/Abrechnungsquellen sowie Pflege von auftragsbezogenen Kosten und periodischen Gemeinkosten im Portal. Sync ins kundenindividuelle Datawarehouse; Auswertung über Power-BI-/Dashboard-Sichten.
4. Zuordnung: Erlöse und Wareneinsatz auf Auftrags-/Artikelebene; Plattform-, Versand- und weitere Kostenarten über auftragsbezogene Kosten bzw. Matching-Konfiguration; Gemeinkosten periodisch. Fehlende Werbe- oder Lagerkosten wurden als Lücke markiert, nicht als null.
5.–6. Auswertung und Erkenntnis: Der Händler konnte Kanäle und Artikel nach Deckungsbeitrag statt nur nach Umsatz vergleichen und priorisierte Maßnahmen (Preis, Sortiment, Fulfillment) auf belastbareren Sichten. Vertrauliche Kennzahlen werden hier nicht veröffentlicht.
7. Verbliebene Einschränkungen: Zeitversetzte Marktplatzkorrekturen, unvollständige Ads-Kosten und manuell zu pflegende Gemeinkosten. Die Auswertung ist so gut wie die Datenpflege – nicht „vollständig automatisch wahr“.
Für eine individuelle Einordnung Ihrer Datenlage eignet sich die Kontaktaufnahme zu einer Datenanalyse.
Mit belastbaren Deckungsbeiträgen lassen sich Sortimente steuern, Kanäle priorisieren, Preise und Versandmodelle prüfen und Retouren-Schwerpunkte adressieren. Entscheidungen bleiben Hypothesen auf Datenbasis – keine Garantie für Gewinnsteigerung.
Besonders wertvoll ist der Abgleich: Hoher Umsatz bei schwachem Deckungsbeitrag vs. moderater Umsatz bei stabilem Beitrag. Das verändert Budget- und Kapazitätsentscheidungen.
Mehr zur Plattform und den Analysebausteinen: Business-Intelligence-Plattform t4data.cloud Datawarehouse sowie Power BI für JTL-Wawi.
t4data.cloud Datawarehouse schafft Transparenz über vorhandene und gepflegte Daten. Es erzeugt keine magische Vollständigkeit. Typische Grenzen: fehlende oder verspätete Abrechnungspositionen, manuell nicht gepflegte Kostenarten, Annahmen bei Gemeinkostenverteilung, Steuer- und Währungsthemen, Retouren-Zeitversatz.
Nicht automatisch als „immer vorhanden“ darzustellen sind u. a. vollständige Werbekosten aller Kanäle, alle Lager- und Kapitalbindungskosten sowie sämtliche internen Betriebskosten – sofern sie nicht geliefert und modelliert wurden.
Gute Praxis: Jede Auswertung mit einem Datenqualitäts-Hinweis versehen – welche Kostenblöcke sind belegt, welche geschätzt, welche fehlend?
Was bedeutet es konkret, Marktplatz Kosten zu berechnen?
Sie stellen dem Erlös die zurechenbaren Kosten gegenüber – mindestens Wareneinsatz und auftragsbezogene Kosten (Provision, Versand, Zahlung, Fulfillment soweit verfügbar) – und interpretieren den Deckungsbeitrag. Gemeinkosten kommen periodisch hinzu und sind oft nur verteilt.
Reicht der Umsatzbericht des Marktplatzes?
Nein. Umsatzberichte zeigen Erlöse und oft Teilgebühren, aber selten Wareneinsatz, alle Versand-/Fulfillmentkosten, Retourenfolgen und Gemeinkosten in einer auftragsfeinen Logik.
Welche Rolle spielt JTL-Wawi?
Die Wawi liefert typischerweise Auftrags-, Artikel- und Einkaufs-/Einstandsdaten. Marktplatzgebühren und Abrechnungskorrekturen kommen zusätzlich aus Marktplatz- bzw. Berichtsquellen; Kostenregeln und Gemeinkosten aus der Portal-Pflege.
Was ist der Unterschied zwischen Rohertrag, Deckungsbeitrag und Ergebnis?
Rohertrag: Erlös minus Wareneinsatz. Deckungsbeitrag: nach weiteren variablen/auftragsbezogenen Kosten. Ergebnis: nach periodischen Gemeinkosten (soweit einbezogen). Die Stufen dürfen nicht vermischt werden.
Können Retouren frühere Bewertungen ändern?
Ja. Retouren, Gutschriften und nachträgliche Gebühren wirken zeitversetzt. Eine Auswertung ohne Retourenlogik überschätzt die Rentabilität.
Wie starte ich mit einer individuellen Auswertung?
Prüfen Sie, welche Kostenarten Sie heute belegt haben, und klären Sie Lücken. Anschließend können Sie über die Produktseite oder den Kontakt eine Analyse mit t4data.cloud Datawarehouse anfragen.
Wenn Sie wissen wollen, was ein Marktplatz, Auftrag oder Artikel nach verfügbaren Kosten wirklich beiträgt, führen wir Erlöse und Kosten in t4data.cloud Datawarehouse zusammen – inklusive klarer Grenzen.
t4data.cloud Datawarehouse ansehenOder direkt eine individuelle Datenanalyse anfragen.
