Shopware 6 Kundengruppen-Rabatte einrichten

von Der Atilla | Aug. 12, 2026 | Alle, Shopware 6 | 0 Kommentare

Wer von Shopware 5 auf Shopware 6 umgestiegen ist, sucht früher oder später nach demselben Feature: ein einfaches Rabatt-Prozentfeld direkt an der Kundengruppe, mit dem sich zum Beispiel B2B-Kunden oder Stammkunden pauschal günstigere Preise anbieten lassen. Genau das ist der Kern der Suchanfrage Shopware 6 Kundengruppen-Rabatte – und die kurze Antwort vorweg: Dieses SW5-Feld existiert im SW6-Core bis heute nicht. Es gibt aber zwei native Wege, die dasselbe Ziel erreichen, plus mehrere Store-Plugins, die es direkter lösen. In diesem Artikel zeigen wir dir alle drei Ebenen – Bordmittel, Plugins und bekannte Stolperfallen – damit du die für deinen Shop passende Lösung findest.

Zuletzt aktualisiert am 13.08.2026. Alle Store-Angaben in Abschnitt 2 wurden an diesem Tag erneut direkt auf der jeweiligen Store-Seite geprüft. Hinweis zu den Screenshots: Diese stammen noch aus einer älteren Shopware-Version. Die Menüpfade und das Vorgehen sind unverändert, deshalb haben wir sie so gelassen.

1. Shopware 6 Kundengruppen-Rabatte mit Bordmitteln einrichten
2. Shopware 6 Kundengruppen-Rabatte per Store-Plugin – 4 Alternativen im Vergleich
3. Shopware 6 Kundengruppen-Rabatte: bekannte Probleme und Bugs in der Praxis
Häufige Fragen zu Kundengruppen-Rabatten in Shopware 6
Quellen und weiterführende Links

1. Shopware 6 Kundengruppen-Rabatte mit Bordmitteln einrichten

Schauen wir uns zuerst an, was Shopware 6 „out of the box“ mitbringt, bevor wir Fremdanbieter ins Spiel bringen. Auf der Verwaltungsseite der Kundengruppen selbst (Einstellungen > Shop > Kundengruppen) findest du laut Shopware-Dokumentation nur den Namen, die Steuerdarstellung (Brutto- oder Nettopreise), Optionen für ein eigenes Registrierungsformular sowie – bei gebuchtem Commercial-Paket – die B2B-Components-Einstellungen. Ein Rabatt-Prozentfeld wie in Shopware 5 gibt es dort nicht. Wer das dort sucht, sucht vergebens. Community-Nutzer haben genau das wiederholt als Feature Request eingereicht, ein offizieller Umsetzungsstatus lässt sich dazu aktuell aber nicht seriös belegen, weil der alte Shopware-Issue-Tracker seit Oktober 2024 abgeschaltet und auf GitHub Issues migriert wurde. Für die praktische Umsetzung gibt es stattdessen zwei unterschiedliche Core-Wege, die man sauber auseinanderhalten sollte.

1.1 Erweiterte Preise am Produkt (Preis auf der Produktdetailseite)

Der erste Weg läuft über den Tab „Erweiterte Preise“ direkt am Produkt. Hier kombinierst du eine Rule-Builder-Bedingung wie „Kundengruppe ist eine von …“ mit einem abweichenden Verkaufspreis, Streichpreis oder Staffelpreis – wahlweise brutto und netto gepflegt. Der Vorteil gegenüber dem zweiten Weg: Laut Shopware-Dokumentation wird dieser Preis direkt auf der Produktdetailseite angezeigt, der eingeloggte Kunde sieht seinen Vorzugspreis also sofort beim Blick aufs Produkt, nicht erst beim Blick in den Warenkorb.

Regel im Rule Builder anlegen (oder wiederverwenden), Bedingungskategorie „Kunde“, Bedingung „Kundengruppe“
Am Produkt im Tab „Erweiterte Preise“ die Regel als Preisstaffel hinterlegen
Staffelpreise nach Menge sind zusätzlich möglich, unabhängig von der Kundengruppen-Bedingung

Der Haken an diesem Weg: Er ist Produkt für Produkt zu pflegen. Bei zwei, drei ausgewählten Artikeln ist das kein Problem, bei einem Sortiment mit mehreren Tausend Positionen wird der Pflegeaufwand schnell hoch – wie hoch genau, quantifiziert die Shopware-Doku nicht, das musst du im Einzelfall selbst gegen dein Sortiment abschätzen.

Praxisbeispiel: Ein B2B-Händler pflegt für eine überschaubare Auswahl an Kernprodukten für Großkunden in der Kundengruppe „Fachhandel“ abweichende Nettopreise direkt in den Erweiterten Preisen. Der Fachhändler sieht seinen reduzierten Preis sofort auf der Produktseite, ganz ohne Gutscheincode oder Warenkorb-Umweg – für ein überschaubares, klar definiertes Sortiment ist das der sauberste und am wenigsten fehleranfällige Weg, weil keine zusätzliche Rule-Builder-Promotion parallel gepflegt werden muss.

1.2 Rule Builder + Promotions (Rabatt im Warenkorb)

Der zweite Weg nutzt den Rule Builder in Kombination mit dem Promotions-Modul. Unter Einstellungen > Shop > Rule Builder legst du eine Regel mit der Bedingung „Kundengruppe“ an (technisch steckt dahinter im Core die eigene Klasse CustomerGroupRule im Namespace Shopware\Core\Checkout\Customer\Rule). Diese Regel verknüpfst du anschließend unter Marketing > Rabatte und Aktionen mit einem prozentualen oder absoluten Rabatt.

Kundengruppen-Rabatt aktiv-Schalter in einer neu angelegten Promotion im Shopware-Admin

Anders als bei den Erweiterten Preisen wirkt und erscheint dieser Rabatt erst im Warenkorb, nicht auf der Produktseite selbst – das ist der klassische, warenkorbweite Rabatt-Ansatz. Für pauschale prozentuale Rabatte auf ganze Kundengruppen (zum Beispiel „B2B-Kunden erhalten 5 % auf den gesamten Warenkorb“) ist das der direktere Weg, weil du nicht jedes einzelne Produkt anfassen musst.

Übersichtsliste aller angelegten Rabatte/Promotions im Shopware-Admin

Rule Builder-Regel mit Bedingung „Kundengruppe“ anlegen
Unter Marketing > Rabatte und Aktionen eine neue Aktion erstellen und die Regel als Anwendungsbedingung hinterlegen
Rabatthöhe (prozentual oder fest) sowie Gültigkeitszeitraum festlegen

Bearbeitungsansicht einer Kundengruppen-Rabatt-Promotion mit Rule-Builder-Zuordnung

Manche Aktionen lassen sich zusätzlich über einen Code oder Link aktivieren, statt automatisch für die gesamte zugeordnete Kundengruppe zu greifen – praktisch, wenn du den Rabatt gezielt in einer Willkommens-Mail oder einem B2B-Onboarding verschicken willst.

Link-/Code-Erzeugung für eine Rabatt-Promotion

Praxisbeispiel: Ein Shop mit einem größeren Artikelsortiment möchte allen Neukunden in der Kundengruppe „Newsletter-Abonnenten“ pauschal einen Prozentrabatt auf den ersten Einkauf gewähren. Statt jedes Produkt einzeln mit Erweiterten Preisen zu pflegen, reicht hier eine einzige Aktion mit der Rule-Builder-Bedingung „Kundengruppe = Newsletter-Abonnenten“ und einem prozentualen Warenkorb-Rabatt. Der Rabatt taucht dann automatisch im Warenkorb auf, sobald der Kunde eingeloggt ist – ohne dass am Produkt selbst irgendetwas geändert werden muss.

1.3 Was Core-Bordmittel NICHT können

Es gibt noch einen dritten, kommerziellen Baustein, den man kennen sollte, bevor man ihn fälschlich für die Lösung hält: die „Customer-Specific Pricing“-API (/api/_action/custom-price) aus dem Commercial-Paket. Sie erlaubt 1:1-Preise pro Einzelkunde – aber wichtig für unser Thema: Das Feld customerGroupId ist in der offiziellen Entwickler-Dokumentation ausdrücklich als „stub implementation“ markiert. Es existiert nur, um spätere Breaking Changes zu vermeiden, und übergebene Daten wirken sich laut Doku nicht auf die Storefront aus. Für Kundengruppen-Rabatte ist dieser Weg damit aktuell nicht produktiv nutzbar, er funktioniert nur für individuelle Einzelkunden-Preise. Zusätzliche Einschränkung: Preisfilter in Produktlisten und in Elasticsearch berücksichtigen Custom Prices ohnehin nicht.

Vollständige Rabatt-Liste mit mehreren aktiven Kundengruppen-Promotions im Überblick

1.4 Welcher Weg passt zu welchem Anwendungsfall?

Wenige, klar definierte Produkte mit dauerhaft abweichendem Kundengruppen-Preis → Erweiterte Preise am Produkt
Pauschaler prozentualer oder fester Rabatt über viele oder alle Produkte hinweg, optional zeitlich befristet → Rule Builder + Rabatte und Aktionen
Individuelle 1:1-Preise für einzelne, namentlich bekannte Kunden → Customer-Specific-Pricing-API (Commercial), nicht für ganze Kundengruppen geeignet

Zurück zur Übersicht

2. Shopware 6 Kundengruppen-Rabatte per Store-Plugin – 4 Alternativen im Vergleich

Wenn dir die Bordmittel zu umständlich sind – etwa weil du einen pauschalen Rabatt auf viele Produkte gleichzeitig brauchst, ohne jedes Produkt einzeln in den Erweiterten Preisen zu pflegen – lohnt sich der Blick in den Shopware Store. Wir haben vier aktuell aktive Plugins/Apps herausgesucht, die das Thema Kundengruppen-Rabatt aus unterschiedlichen Richtungen angehen. Alle Preise und Kompatibilitätsangaben wurden am 13.08.2026 direkt auf der jeweiligen Store-Seite geprüft.

Ein Hinweis vorweg, der für alle vier gilt: Jede dieser Erweiterungen startet mit einem kostenlosen Probemonat, in dem das Abo jederzeit kündbar ist. Der Testmonat ist also kein Alleinstellungsmerkmal einer einzelnen Lösung, sondern der Standard im Store. Alle vier sind aktuell bis Shopware 6.7.13.0 freigegeben – die Obergrenze wandert mit jedem Shopware-Release weiter, prüfe sie im Zweifel selbst nach.

2.1 Rabatte und Aufschläge für Kundengruppen (moori)

Dieses Plugin arbeitet auf Produktebene über dynamische Produktgruppen und rechnet mit einer etwas gewöhnungsbedürftigen Logik: Der Rabatt-Wert ist als „Rest nach Rabatt“ zu verstehen – 100 entspricht dem Originalpreis, 90 bedeutet 10 % Rabatt. Wer das beim ersten Einrichten übersieht, konfiguriert schnell das Gegenteil von dem, was er wollte. Der Rabatt wird laut Hersteller auf Produktebene berechnet, nicht als Warenkorb-Rabatt.

Preis: 15,00 €/Monat (monatlich kündbar) bzw. 162,00 €/Jahr (entspricht 13,50 €/Monat)
Kompatibilität: Shopware 6.4.0.0–6.7.13.0
Stand: Version 1.7.8, laut Store-Seite zuletzt aktualisiert am 05.08.2026
Wichtig laut Hersteller-Doku: Nach Änderung der Bedingungen einer dynamischen Produktgruppe müssen die Indices per bin/console dal:refresh:index neu aufgebaut werden. Zusätzlich muss der Shop-Cache geleert werden, damit die Preise sofort in der Storefront greifen – Warenkorb und Bestellabschluss sind davon nicht betroffen.

2.2 Rabattgruppen – Kunden-Rabatt auf Warengruppen vom Listenpreis (ACRIS E-Commerce)

ACRIS setzt eine Ebene höher an: Statt einzelner Produkte definierst du Warengruppen bzw. Listenpreis-Ebenen mit Staffelrabatten, die produktübergreifend gelten. Die Kundenzuweisung kann per Kunden-Rabattgruppe, per Rule-Builder-Regel oder auch einzeln pro Kunde erfolgen – das macht das Plugin flexibler, aber auch komplexer in der Ersteinrichtung als die reinen Kundengruppen-Lösungen. Es ist gleichzeitig das mit Abstand am aktivsten gepflegte der vier.

Preis: 69,90 €/Monat bzw. 699,00 €/Jahr (entspricht 58,25 €/Monat)
Kompatibilität: Shopware 6.4.0.0–6.7.13.0
Stand: Version 7.5.3, laut Store-Seite zuletzt aktualisiert am 11.08.2026
Zwei Einschränkungen, die der Hersteller selbst nennt und die man vor dem Kauf kennen sollte: Ein Kunde kann immer nur einer Kunden-Rabattgruppe angehören, nicht mehreren. Und die Warengruppe am Produkt ist je Sprache zu pflegen – wird sie in einer Sprache nicht gesetzt, greift in dieser Sprache kein Rabatt.
Als „Premium Extension“ wird das Plugin im Store priorisiert ausgespielt. Das sagt etwas über die Platzierung, nicht über die Eignung für deinen Fall.

2.3 Kundengruppenrabatt für Kategorien – klassisches Plugin (D-MIT-S)

Für Shops, die primär kategorieweise rabattieren wollen (zum Beispiel „alle B2B-Kunden erhalten 8 % auf die gesamte Kategorie Werkzeuge“), bietet D-MIT-S eine klassische Plugin-Variante. Praktisch dabei: Am Artikel selbst lässt sich ein maximaler Rabatt hinterlegen, damit Produkte nicht unter Marge verkauft werden. Unterstützt werden bis zu 20 Kundengruppen.

Preis: 5,29 €/Monat bzw. 54,99 €/Jahr (entspricht 4,58 €/Monat)
Kompatibilität: Shopware 6.4.0.0–6.7.13.0
Stand: Version 3.0.1, laut Store-Seite zuletzt aktualisiert am 05.08.2026

2.4 Kundengruppenrabatt für Kategorien – App-Variante (D-MIT-S)

Dieselbe Kategorie-Logik gibt es von D-MIT-S auch als App statt als klassisches Plugin – relevant, wenn dein Shop auf Shopware Cloud/SaaS läuft, wo klassische Plugins mit Server-Zugriff nicht laufen. Der Preis ist etwas günstiger als die Plugin-Variante. Zur Einordnung: Die App steht laut Store-Seite noch bei Version 1.0.0 und unter 10 Downloads – wer sie einsetzt, sollte sie vorher im Testmonat gründlich gegen den eigenen Shop prüfen.

Preis: 4,99 €/Monat bzw. 49,99 €/Jahr (entspricht 4,17 €/Monat)
Kompatibilität: Cloud 6.5.2.0–6.7.13.0
Stand: Version 1.0.0, laut Store-Seite zuletzt aktualisiert am 05.08.2026

2.5 Was wir bewusst NICHT gelistet haben

Zwei in älteren Recherchen genannte Kandidaten fehlen hier absichtlich: Das Runourcode-Plugin „Kundenindividuelle Rabatte / Kundengruppenrabatt“ liefert bei Aufruf der Store-URL aktuell einen 404-Fehler und ist damit nicht mehr sicher auffindbar – wir nennen dazu bewusst keinen Preis. Und „Kundenindividuelle Rabatte“ von lenz-ebusiness ist nur bis Shopware 5.7.20 kompatibel und für 6.7-Shops schlicht irrelevant. Ein Vollständigkeitsanspruch besteht bei dieser Liste ohnehin nicht – der Store-Markt für Kundengruppen-Rabatte ist größer, wir haben uns auf die vier aktuell prominentesten und tatsächlich für 6.7 kompatiblen Treffer konzentriert.

2.6 Bordmittel oder Plugin – eine kurze Einordnung

Ob sich ein kostenpflichtiges Plugin lohnt, hängt stark von der Sortimentsgröße und der Rabatt-Logik ab. Für einen reinen prozentualen Warenkorb-Rabatt pro Kundengruppe reichen die Core-Bordmittel aus Abschnitt 1 in aller Regel aus – dafür zusätzlich 5 bis 70 Euro im Monat für ein Plugin auszugeben, ist selten nötig. Interessant werden die Store-Lösungen erst, wenn du Rabattlogiken brauchst, die der Core so nicht abbildet: warengruppenübergreifende Staffelrabatte vom Listenpreis (ACRIS), kategorieweite Rabatte mit Margenschutz am Artikel (D-MIT-S) oder eine dynamische Produktgruppen-Logik mit eigener Rabatt-Prozentrechnung (moori). Wäge das gegen den laufenden Monatspreis und die im Abschnitt 3 beschriebenen Stolperfallen bei dynamischen Produktgruppen ab, bevor du dich festlegst.

Zurück zur Übersicht

3. Shopware 6 Kundengruppen-Rabatte: bekannte Probleme und Bugs in der Praxis

Bevor du dich für einen der beiden Wege entscheidest, lohnt sich ein Blick auf dokumentierte Fehlerbilder aus der Community und dem offiziellen Issue-Tracker. Nicht jedes Problem ist ein Show-Stopper, aber alle sind es wert, vorher zu kennen.

Der häufigste Grund, warum dynamische Produktgruppen „nicht funktionieren“, ist gar kein Bug: Ist auf dem Server die Einstellung shopware.product_stream.indexing auf false gesetzt – ein von Shopware selbst in den Performance-Tweaks dokumentierter Kniff – greifen dynamische Produktgruppen und die Rule-Builder-Bedingung „Artikel in dynamischer Produktgruppe“ nicht mehr. Im Admin gibt es dafür bis heute keine Warnung und keinen Tooltip; genau das ist als Issue #11142 mit „priority: high“ eingetragen, aber noch offen. Du klickst, speicherst, und im Frontend passiert nichts. Bevor du also Cronjobs und Redis-Flushes ausprobierst: erst diese Config-Zeile prüfen.
Dynamische Produktgruppen aktualisieren sich nicht automatisch: Mehrere Nutzer im Shopware-Forum berichten, dass sich dynamische Produktgruppen erst nach manuellem erneutem Speichern der Regel im Backend aktualisieren. Der gängige Community-Workaround ist ein regelmäßiger Cronjob mit bin/console dal:refresh:index, kombiniert mit zeitrelativen statt fixen Datumsfiltern in der Regel. Der moori-Hersteller schreibt denselben Befehl übrigens direkt in seine Konfigurationsanleitung – das deckt sich also.
Reindexing hilft nicht immer: In einem gemeldeten Fall auf Shopware 6.6.10.2 half reines Reindexing über dal:refresh:index nicht – auch Cache-Invalidierung über X-Keys, Varnish-PURGE oder das Löschen von Redis-Keys blieb wirkungslos. Das zugehörige Issue #8221 wurde inzwischen geschlossen, allerdings mit Verweis auf das Folge-Issue #15955 und weiterhin als „priority: high“ gelabelt. „Geschlossen“ heißt hier also nicht zwingend „behoben“ – wer betroffen ist, sollte den verlinkten Nachfolger im Auge behalten.
Dynamische Produktgruppen und die Elternkategorie (6.7.4.2): Produkte, die über eine dynamische Produktgruppe einer Unterkategorie zugewiesen sind, tauchen im Listing der übergeordneten Kategorie nicht auf. Bei manuell zugewiesenen Produkten funktioniert es. Relevant für alle, die Kundengruppen-Rabatte auf Kategorie- oder Produktgruppen-Ebene aufbauen. Als Issue #13661 mit „priority: high“ gemeldet.
Rule-Engine-Bug bei kombinierten Kundengruppen-Bedingungen: Eine Produktpreisregel mit der Kombination „Kundengruppe A UND NICHT Kundengruppe B“ wurde in einem gemeldeten Fall falsch ausgewertet – ausgeschlossene Kunden konnten trotzdem zum Preis der anderen Gruppe kaufen. Shopware hat das Issue als „not planned“ geschlossen, ein Fix ist also nicht zu erwarten. Wer mit UND/NICHT-Verknüpfungen bei Kundengruppen arbeitet, sollte das Ergebnis testweise mit einem Testkunden pro Gruppe verifizieren.
Rabatte griffen fälschlich auch bei Streichpreis-Produkten: Ein Rabatt, der nur auf Produkte ohne Streichpreis wirken sollte, wurde in einer Version zusätzlich auf Produkte mit Streichpreis angewendet. Der Bug war als „priority: high“ eingestuft und ist inzwischen per Pull Request behoben.
Kein natives Äquivalent zu „Kundenrabatt Advanced“ aus Shopware 5: Die Community bestätigt in einem Forumsthread, dass es für individuelle Rabatte pro Einzelkunde kein direktes SW6-Bordmittel-Äquivalent gibt und verweist auf Drittanbieter-Plugins als Workaround – deckt sich mit dem, was wir oben zur Customer-Specific-Pricing-API und ihrem „stub“-Status beschrieben haben.

Der praktische Rat daraus: Teste jede neu eingerichtete Kundengruppen-Rabatt-Regel mit einem echten Testkonto pro betroffener Gruppe, bevor du sie live schaltest – gerade bei kombinierten Bedingungen und dynamischen Produktgruppen zeigen sich Fehler oft erst im echten Frontend, nicht in der Admin-Vorschau.

Zurück zur Übersicht

Häufige Fragen zu Kundengruppen-Rabatten in Shopware 6

Gibt es in Shopware 6 ein Rabatt-Prozentfeld direkt an der Kundengruppe wie in Shopware 5?

Nein. Die Kundengruppen-Verwaltungsseite in Shopware 6 bietet laut offizieller Dokumentation nur Name, Steuerdarstellung, Optionen zum Registrierungsformular und – mit Commercial – die B2B-Components-Einstellungen, aber kein eigenes Rabattfeld. Rabatte müssen über Erweiterte Preise am Produkt oder über Rule Builder + Rabatte und Aktionen abgebildet werden.

Sieht der Kunde den Kundengruppen-Rabatt auf der Produktseite oder erst im Warenkorb?

Das hängt vom gewählten Weg ab. Erweiterte Preise am Produkt werden laut Shopware-Doku direkt auf der Produktdetailseite angezeigt. Ein über Rule Builder + Rabatte und Aktionen eingerichteter Rabatt wirkt und erscheint dagegen erst im Warenkorb.

Kann ich mit Bordmitteln individuelle Rabatte pro Einzelkunde statt pro Kundengruppe vergeben?

Dafür gibt es die Commercial-API „Customer-Specific Pricing“. Für gruppenbasierte Rabatte ist sie aber aktuell nicht nutzbar, da das Feld customerGroupId in der Entwickler-Dokumentation ausdrücklich als „stub implementation“ markiert ist und übergebene Daten sich nicht auf die Storefront auswirken – produktiv funktionieren dort nur Preise für einzelne Kunden.

Warum aktualisiert sich meine dynamische Produktgruppe für den Rabatt nicht automatisch?

Prüfe zuerst, ob auf deinem Server shopware.product_stream.indexing auf false steht. Diese Performance-Einstellung legt dynamische Produktgruppen still, ohne dass der Admin dich warnt – das ist als Issue #11142 dokumentiert und noch offen. Wenn das nicht die Ursache ist: Dynamische Produktgruppen aktualisieren sich laut Forumsberichten teils erst nach manuellem erneutem Speichern der Regel. Der gängige Workaround ist ein regelmäßiger Cronjob mit bin/console dal:refresh:index; in Einzelfällen half laut Issue #8221 selbst das nicht.

Welche Store-Plugins gibt es für Shopware 6 Kundengruppen-Rabatte?

Aktuell (Prüfdatum 13.08.2026) haben wir vier kompatible Optionen identifiziert: „Rabatte und Aufschläge für Kundengruppen“ von moori (15 €/Monat), „Rabattgruppen“ von ACRIS (69,90 €/Monat), sowie „Kundengruppenrabatt für Kategorien“ von D-MIT-S als klassisches Plugin (5,29 €/Monat) oder als Cloud-App (4,99 €/Monat). Alle vier sind bis Shopware 6.7.13.0 freigegeben und starten mit einem kostenlosen Probemonat. Details und Wirkebenen findest du in Abschnitt 2.