Financial Revolution: Erweiterte Berichte für PrestaShop-Shopbetreiber

Zuletzt geprüft im Juni 2026, die unten genannten Feldpfade im Backoffice und Tabellennamen gelten für PrestaShop 1.7, 8 und 9; Menübezeichnungen unterscheiden sich je nach Version leicht, daher kann der genaue Wortlaut in Ihrer Administration abweichen.

PrestaShop zeigt Ihnen ohne Weiteres, wie viel Sie verkauft haben. Öffnen Sie Statistiken (den AdminStats-Controller, je nach Version im Dashboard- oder Statistik-Menü), und Sie erhalten Umsätze im Zeitverlauf, Bestseller-Produkte, Auswertungen nach Versanddienstleistern, ein Umsatz-und-Bestellungen-Dashboard sowie eine sortierbare Bestseller-Liste. Was Ihnen keine dieser Ansichten zeigt, ist die eine Zahl, die entscheidet, ob Ihr Shop tatsächlich ein Geschäft ist: wie viel Geld bei Ihnen geblieben ist. Umsatz ist das, was PrestaShop standardmäßig misst. Gewinn ist das, was Sie mit nach Hause nehmen, und beides liegt viel weiter auseinander, als die meisten Händler glauben. In diesem Beitrag geht es darum, diese Lücke zu schließen: welches Finanzreporting ein PrestaShop-Shop braucht, um nach Marge statt nach Umsatz zu steuern, was das Backoffice liefert, wo es endet und wie Sie zum echten Gewinn pro Produkt, pro Bestellung und pro Kunde kommen.

Eine Abgrenzung vorab, damit dieser Beitrag beim Thema bleibt. Es geht hier um finanzielles Reporting. Geld hinein, Geld hinaus, was übrig bleibt. Es geht nicht um Webanalyse. Woher Ihre Besucher kommen, wie sie sich auf der Seite verhalten, welche Traffic-Quelle konvertiert. Das ist ein eigenes Thema, das wir in was Sie messen sollten und was Sie ignorieren können sowie in den GA4-Kennzahlen, die wirklich zählen behandeln. Hier bleiben wir bei der GuV.

Warum die nativen PrestaShop-Statistiken nicht zeigen, ob Sie profitabel sind

Die native Statistik-Engine ist auf Umsatz und Volumen ausgelegt, weil diese Daten sauber in den Bestelltabellen stehen. Wenn PrestaShop einen Verkauf erfasst, speichert es den vom Kunden gezahlten Preis, die Steuer, die berechneten Versandkosten und den Bestellstatus. Es speichert aber nicht in einer brauchbaren Reporting-Form, was Sie diese Bestellung gekostet hat. Diese Kosten sind über Bereiche verteilt, die die Statistikansichten nie zusammenführen:

• Großhandels- bzw. Einstandskosten. PrestaShop hat dafür ein Feld, wholesale_price beim Produkt, gesetzt unter Katalog → Produkte → [Produkt] → Preisgestaltung → Einstandspreis, gespeichert in ps_product und zum Verkaufszeitpunkt nach ps_order_detail.original_wholesale_price kopiert. Der Haken: Fast niemand füllt es aus. Und selbst wenn es gepflegt ist, erscheinen die nativen Werte nur an Stellen wie der Gewinnmargen-Kennzahl unter Statistiken → Katalogstatistiken und der Gewinnspalte pro Produkt unter Statistiken → Bestseller-Produkte / Produktdetails, als gemischte oder produktbezogen aggregierte Ansicht, nie pro Bestellung oder pro Kunde.
• Gebühren für Zahlungsabwicklung. Die 1,4–3 %, die Stripe, PayPal oder ein Kartenanbieter einbehält, landen überhaupt nicht in PrestaShop. Eine Bestellung über 100 € wird als 100 € Umsatz erfasst, obwohl nur 97,10 € auf Ihrem Konto ankommen.
• Tatsächliche Versandkosten. Die Bestellung speichert, was der Kunde für den Versand bezahlt hat, nie aber, was der Versanddienstleister Ihnen berechnet hat. Bieten Sie kostenlosen Versand an, zeigt die native Summe null Versandumsatz und null Kosten, obwohl Sie dem Paketdienst tatsächlich 6 € gezahlt haben.
• Erstattungen und Retouren. Eine erstattete Bestellung kann je nach Konfiguration Ihrer Bestellstatus weiterhin in einem Status liegen, der als "gültiger" Umsatz zählt, und dadurch die Umsatzzahl unbemerkt aufblähen.

Die native Zahl zur "Gewinnmarge" taugt also grob zur Plausibilitätskontrolle, aber nicht für Entscheidungen. Sie kann Ihnen nicht sagen, welches von zwei Produkten Sie bewerben sollten, weil sie nicht sieht, dass beim einen 2 € Kartengebühr und eine Retourenquote von 30 % anfallen, während das andere frei von solchen Belastungen versendet wird.

Umsatz ist die irreführendste Zahl in Ihrem Shop

Stellen Sie zwei PrestaShop-Shops nebeneinander. Shop A macht 50.000 € Umsatz im Monat; Shop B 20.000 €. Im nativen Dashboard sieht A klar besser aus. Rechnen Sie nun die Kosten ein, die PrestaShop nicht verfolgt: A verkauft margenschwache Elektronik mit 12 % Retourenquote, zahlt 1,9 % Kartengebühren und subventioniert den Versand; B verkauft Eigenmarkenprodukte mit 60 % Marge und fast ohne Retouren. Wenn Sie sauber rechnen, behält B jeden Monat mehr Euro. Der Händler, der nur auf die native Statistikansicht schaut, würde genau den falschen Shop optimieren.

Dieses eine Beispiel erklärt den ganzen Sinn von Finanzreporting. Die Kennzahlen, die einen Shop wirklich bewegen, sind Kennzahlen zweiter Ordnung, sie entstehen erst, wenn Sie Kosten vom Umsatz abziehen:

• Bruttomarge pro Produkt, Verkaufspreis minus Großhandelskosten, minus Zahlungsgebühr, Versandzuschuss und der anteilige Gemeinkostenanteil dieser Position. Das Produkt, das in der Bestseller-Liste wie Ihr Held aussieht, ist manchmal genau das, das unbemerkt Geld verliert, sobald Gebühren und Retouren eingerechnet werden.
• Deckungsbeitrag pro Bestellung, was eine einzelne Bestellung nach ihren eigenen variablen Kosten übrig lässt. Zwei Bestellungen über 80 € sind nicht gleich, wenn die eine kostenlos quer durchs Land verschickt wurde und die andere Click-and-Collect war.
• Gewinn nach Kundensegment, Lifetime Value mit Akquisitionskosten verbinden. Das Verhältnis zwischen dem Wert eines Kunden und den Kosten, ihn zu gewinnen, ist ein eigenes Thema; wir leiten es hier nicht erneut her. Die Daten zu Kundenwert im Vergleich zu Akquisitionskosten finden Sie in was Sie messen sollten und was Sie ignorieren können.
• Tatsächliche Retourenquote nach Produkt und Kategorie. Eine Retourenquote von 30 % ist kein Bestseller, sondern ein Mangel oder eine irreführende Beschreibung, die Ihre Marge doppelt auffrisst: Sie zahlen den Versand hin, Sie tragen den Rückversand, und womöglich können Sie den Artikel nicht erneut verkaufen.

Was Sie heute aus PrestaShop herausholen können, und wo der Export an seine Grenzen kommt

Bevor Sie zu zusätzlichen Werkzeugen greifen, lohnt es sich, genau zu wissen, wie weit Sie mit Bordmitteln kommen. Für einen kleinen Katalog kann das bereits genügen.

In dieser letzten Zeile landen die meisten Händler, Bestellungen in eine Tabellenkalkulation exportieren, Gebührenmodelle und Versanddienstleister-Rechnungen von Hand ergänzen, jeden Monat dieselbe Pivot-Tabelle neu bauen. Einmal funktioniert das. Als wöchentliche Routine funktioniert es nicht. Und ein Bericht, den Sie nur erstellen, wenn Sie sich Sorgen machen, findet Probleme einen Monat zu spät. Die ehrliche native Obergrenze lautet: PrestaShop kann Ihnen Umsatz in einem Dashboard zeigen und Kosten nur dann, wenn Sie sich mit eigenen Abfragen durch den SQL Manager arbeiten. Beides in einer dauerhaften, geplanten, aufschlüsselbaren Gewinnansicht zusammenzuführen, ist die Wand, über die Sie das Backoffice nicht hebt.

Wenn Sie sich im SQL Manager wohlfühlen, kommen Sie tatsächlich weit, eine Abfrage, die ps_orders, ps_order_detail und original_wholesale_price verbindet, liefert Ihnen eine echte Bruttomarge pro Bestellung. Was dort nicht ohne Weiteres geht: externe Kostendaten einbeziehen (Ihr Stripe-Gebührenmodell, Ihre Versanddienstleister-Rechnungen), den Bericht planen oder ihn an einen nicht technischen Kollegen weitergeben. Genau dort verläuft die Grenze zwischen einer cleveren Abfrage und einem Reporting-System.

Die SQL-Manager-Abfrage für echte Bruttomarge pro Bestellung

Hier ist eine Startabfrage, die Sie in Erweiterte Einstellungen → Datenbank → SQL Manager einfügen können. Sie summiert den Umsatz jeder Bestellung gegen die zum Verkaufszeitpunkt gespeicherten Großhandelskosten, sodass Sie die Bruttomarge pro Bestellung erhalten, genau das, was die nativen Ansichten nicht zeigen. Passen Sie das Tabellenpräfix (ps_) an, falls es bei Ihnen anders lautet, und den Filter für gültige Bestellungen an Ihre Bestellstatus:

SELECT
    o.id_order,
    o.reference,
    o.total_paid_tax_excl                              AS revenue_excl_tax,
    SUM(od.product_quantity * od.original_wholesale_price) AS cost_of_goods,
    o.total_paid_tax_excl
        - SUM(od.product_quantity * od.original_wholesale_price) AS gross_margin,
    ROUND(
        100 * (o.total_paid_tax_excl
            - SUM(od.product_quantity * od.original_wholesale_price))
        / NULLIF(o.total_paid_tax_excl, 0)
    , 1)                                               AS margin_pct
FROM ps_orders o
JOIN ps_order_detail od ON od.id_order = o.id_order
WHERE o.valid = 1
GROUP BY o.id_order
ORDER BY gross_margin ASC;

Zwei ehrliche Einschränkungen. Das ist nur die Bruttomarge, sie zieht Wareneinsatz ab, aber keine Zahlungsgebühren, tatsächlichen Versandkosten oder Retouren, weil PrestaShop diese Daten nicht speichert (genau darum geht es in diesem Artikel). Außerdem ist sie nur so verlässlich wie Ihre original_wholesale_price-Daten: Bestellungen aus Zeiten, in denen das Kostenfeld leer war, zeigen 100 % Marge und verzerren die Liste. Aufsteigend zu sortieren (gross_margin ASC) setzt Ihre schlechtesten Bestellungen nach oben, und genau die möchten Sie meist zuerst prüfen.

Von Daten zu Entscheidungen: Was sich ändert, wenn Sie Gewinn sehen

Und was bringt das? Der Sinn des Ganzen ist kein schöneres Dashboard, sondern dass vier alltägliche Entscheidungen nicht länger Bauchgefühl sind:

• Preisgestaltung. Eine Erhöhung um 5 % bei einem Produkt mit gesunder Marge und stabiler Nachfrage ist eine sichere Entscheidung, wenn Sie die aktuelle echte Marge neben dem Verkaufstrend sehen. Ohne Kostensicht ist dieselbe Entscheidung ein Münzwurf.
• Was Sie bewerben. Gewinnreporting sortiert die Bestseller-Liste regelmäßig neu. Der Stückzahl-Sieger und der Gewinn-Sieger sind häufig unterschiedliche Produkte, und Ihr Platz auf der Startseite, Ihr Werbebudget und Ihre Bundle-Angebote sollten auf den zweiten zeigen.
• Lagerbestand. Was nachbestellt, eingestellt oder abverkauft wird, sollte der Marge folgen, nicht dem Volumen. Ein Langsamdreher mit 65 % Marge verdient vielleicht mehr Sichtbarkeit; ein Schnellläufer mit 4 % braucht womöglich eine Preiserhöhung oder einen stillen Ausstieg.
• Rabattstrategie. Ein Flash Sale, der 10.000 € Umsatz, aber nach Rabatt, Gebühren und Versand nur 500 € Gewinn bringt, ist nicht der Erfolg, den das Umsatzdiagramm suggeriert. Margenbewusstes Reporting zeigt Ihnen das am Morgen danach, nicht erst am Quartalsende.

Die Lücke mit dem Financial Revolution-Modul schließen

Genau dafür gibt es unser Modul Financial Revolution: Es nimmt den Umsatz, den PrestaShop bereits erfasst, ermöglicht Ihnen, die Kosten und Ausgaben zu erfassen, die PrestaShop gar nicht verfolgt, und macht daraus eine dauerhafte Gewinn-und-Verlust-Ansicht direkt im Backoffice, keine monatliche Tabellenkalkulation, kein SQL von Hand. Was bringt Ihnen das konkret?

• Eine echte Gewinn-und-Verlust-Ansicht, nicht nur ein Umsatz-Dashboard, Umsatz, Ihre erfassten Kosten und Betriebsausgaben, Steuer/VAT und der daraus resultierende Gewinn, nach Kategorien aufgeschlüsselt, sodass die Untergrenze, die Sie sehen, der Betrag ist, den Sie tatsächlich behalten, und nicht bloß eine Umsatzzahl.
• Kosten- und Ausgabenerfassung für das, wofür PrestaShop keinen Platz hat, erfassen Sie Kosten und Gemeinkosten, die die Plattform nie speichert (Gebühren von Zahlungsanbietern, tatsächlicher Versand, Betriebsausgaben), und lassen Sie sie automatisch vom Umsatz abziehen, statt sie nachträglich in einer Tabelle anzukleben.
• Cashflow-, Steuer- und VAT-Reporting an einem Ort. Cashflow-Bewegungen, Steuer- und VAT-Berichte, Rechnungen und Korrekturen werden im Backoffice verwaltet, statt im Nachhinein von Hand abgeglichen zu werden.
• Es lebt in Ihrer Administration, lesen Sie es im Backoffice in demselben wöchentlichen Rhythmus, in dem Sie ohnehin Bestellungen prüfen, statt zu exportieren und neu aufzubauen, mit CSV-Export, wenn Sie die Zahlen an den Steuerberater weitergeben müssen.

Ehrliche Grenze: Ein Reporting-Modul reportet, es legt Ihre Preise nicht fest und erstattet Ihnen keine Kartengebühren. Seine Aufgabe ist es, die echte Zahl unübersehbar zu machen, damit Sie danach handeln können. Und es ist nur so genau wie die Kostendaten dahinter. Das ist der nächste Punkt.

Vertrauenswürdig machen: Erst die Kostendaten pflegen

Für Finanzreporting gilt: schlechte Daten hinein, schlechte Daten heraus. Der häufigste Grund, warum ein Gewinnbericht falsch aussieht, sind leere Kostenfelder. Bevor Sie irgendeiner Margenzahl vertrauen, nativ oder aus einem Modul, erledigen Sie die unspektakuläre Grundlage:

• Großhandels-/Einstandspreis pflegen bei jedem Produkt (Katalog → Produkte → Preisgestaltung → Einstandspreis). Bearbeiten Sie ihn in großen Mengen oder importieren Sie ihn über den Katalogimport, wenn Sie Hunderte SKUs haben; ein Margenbericht über halb leere Kostenfelder ist schlimmer als gar kein Bericht, weil er verbindlich wirkt, es aber nicht ist.
• Ihr echtes Gebührenmodell kennen, den tatsächlichen Prozentsatz und die Gebühr pro Transaktion, die Ihr Zahlungsanbieter berechnet und die Sie aus einer Stripe- oder PayPal-Abrechnung ablesen können, nicht den beworbenen Standardsatz.
• Ihre echten Versanddienstleisterkosten erfassen, nicht den für Kunden sichtbaren Versandpreis, aus den Rechnungen Ihres Paketdienstes, besonders wenn Sie kostenlosen Versand oder Pauschalversand anbieten, bei dem die vom Kunden gezahlte Zahl nichts aussagt.
• Ihre Bestellstatus aufräumen, damit erstattete und stornierte Bestellungen nicht still als gültiger Umsatz zählen. Prüfen Sie, welche Status als logable/bezahlt unter Shop-Einstellungen → Bestelleinstellungen → Status markiert sind.

Eine Reporting-Routine aufbauen

Der genaueste Bericht der Welt ist wertlos, wenn ihn niemand öffnet. Die Shops, die dauerhaft besser werden, sind die, in denen eine Zahl und nicht ein Bauchgefühl die Diskussion beendet, und das passiert nur mit einem festen Rhythmus:

• Wöchentlich: gesamter Gewinn (nicht Umsatz), Ihre stärksten und schwächsten Produkte nach Marge und jede Bewegung, die einen zweiten Blick verdient. Fünf Minuten im Backoffice.
• Monatlich: Trends und Saisonalität sowie die Frage, ob eine konkrete Maßnahme, Preisänderung, neuer Lieferant, Aktion, tatsächlich den Gewinn bewegt hat und nicht nur den Umsatz.
• Quartalsweise: die gesamte Strategie gegen die Daten prüfen. Welche Kategorien verdienen ihren Platz im Sortiment, welche Kunden lohnen sich, wo liegt totes Gewicht im Katalog.

PrestaShop misst Umsatz von Haus aus, weil Umsatz die einfache Zahl zum Speichern ist. Gewinn ist die Zahl, die das Geschäft steuert. Dorthin zu kommen bedeutet, die Kosten abzuziehen, die die Plattform verteilt oder ignoriert, Großhandel, Gebühren, tatsächlicher Versand, Retouren. Ob Sie das mit einer sorgfältigen SQL-Manager-Abfrage, einer disziplinierten Tabellenkalkulation oder einem Modul erreichen, das die Verknüpfung für Sie übernimmt: Die Disziplin bleibt dieselbe. Steuern Sie nach dem, was Sie behalten, nicht nach dem, was Sie umsetzen, und lesen Sie es oft genug, um den Abwärtstrend zu erkennen, bevor er ein Quartal alt ist.

Häufig gestellte Fragen

Warum sieht die native Gewinnmarge in PrestaShop falsch aus oder ist leer?

Fast immer, weil das Einstandspreisfeld leer ist. Die Marge unter Statistiken → Katalogstatistiken in PrestaShop wird aus wholesale_price berechnet. Wenn Sie dieses Feld bei Ihren Produkten nie ausgefüllt haben, ist die Zahl bedeutungslos. Selbst wenn sie gefüllt ist, bleibt der native Wert ein gemischter globaler Prozentsatz, der Zahlungsgebühren, tatsächliche Versandkosten und Retouren ignoriert, gut genug für eine grobe Plausibilitätskontrolle, aber unbrauchbar für die Entscheidung, welches Produkt Sie bewerben sollten. Füllen Sie zuerst die Einstandspreise aus; danach entscheiden Sie, ob die native Ansicht reicht oder ob Sie Details pro Bestellung brauchen.

Kann ich den echten Gewinn pro Bestellung ohne Modul berechnen?

Ja, für die Bruttomarge, die SQL-Manager-Abfrage oben verbindet ps_orders und ps_order_detail über original_wholesale_price und liefert Ihnen die Marge pro Bestellung. Was Sie im SQL Manager ohne echten Aufwand nicht schaffen, ist, externe Kosten einzubeziehen (Ihr Stripe-Gebührenmodell, Versanddienstleister-Rechnungen), den Bericht zu planen oder ihn an einen nicht technischen Kollegen weiterzugeben. Diese Lücke, externe Kostendaten in eine dauerhafte, aufschlüsselbare GuV einzubinden. Ist die Grenze zwischen einer cleveren Abfrage und einem Reporting-System wie Financial Revolution.

Wo speichert PrestaShop den Einstandspreis, und wie fülle ich ihn in großen Mengen?

Der Einstandspreis steht in wholesale_price auf ps_product (und je Kombination dort, wo Sie ihn setzen), bearbeitet unter Katalog → Produkte → Preisgestaltung → Einstandspreis. Zum Zeitpunkt des Verkaufs kopiert PrestaShop ihn nach ps_order_detail.original_wholesale_price. Deshalb behalten historische Bestellungen die Kosten, die beim Kauf tatsächlich galten. Bei Hunderten SKUs füllen Sie das Feld besser über den Katalog-CSV-Import statt von Hand, und denken Sie daran: Bestellungen, die vor der Pflege des Feldes eingegangen sind, zeigen keine Kosten. Vertrauen Sie der Marge alter Bestellungen daher nicht.

Erfasst Financial Revolution Zahlungsgebühren und Versandkosten automatisch?

Es gibt Ihnen den Ort, an dem Sie diese Werte erfassen können, und zieht sie automatisch vom Umsatz ab, sobald sie eingetragen sind, aber es kann Ihre Stripe-Abrechnung oder Paketdienstrechnung nicht selbst lesen. Die Aufgabe des Moduls ist es, die Kosten zu erfassen, für die PrestaShop keinen Speicherort hat (Zahlungsanbietergebühren, tatsächlicher Versand, Betriebsausgaben), und sie in eine Backoffice-GuV einzubeziehen, damit Sie keine Tabellenkalkulation mehr neu bauen müssen. Die Genauigkeit hängt weiterhin davon ab, dass Sie Ihr echtes Gebührenmodell und Ihre Versanddienstleisterkosten eintragen; schlechte Daten hinein, schlechte Daten heraus gilt hier genauso wie überall.

Ist das dasselbe wie meine GA4- oder Analytics-Daten?

Nein, und beides zu vermischen ist ein häufiger Fehler. Das hier ist Finanzreporting: Geld hinein, Geld hinaus, was übrig bleibt. GA4 und ähnliche Werkzeuge sind Webanalyse: woher Besucher kommen, wie sie sich verhalten, welcher Kanal konvertiert. Sie beantworten unterschiedliche Fragen, und keines ersetzt das andere. Für die Analytics-Seite beginnen Sie mit was Sie messen sollten und was Sie ignorieren können und den GA4-Kennzahlen, die wirklich zählen.