Eine Pricing Engine berechnet Verkaufspreise automatisch aus Kosten, Margenvorgaben, Kundengruppen, Mengen, Lieferanten oder anderen Geschäftsregeln - statt aus manueller Eingabe pro Artikel. Sie wird interessant, sobald sich Preise nicht mehr zuverlässig als einzelner, von Hand gepflegter Wert pro Produkt verwalten lassen: eine Margenänderung, eine Rundungsregel oder ein geänderter Lieferantenpreis muss sich dann auf jedes betroffene Produkt auswirken, ohne dass jemand Zeilen einzeln bearbeitet.
PIMSuite enthält dafür eine eigene regelbasierte Preisengine.
Wann reicht ein einfacher Produktpreis nicht mehr?
Ein einzelnes Preisfeld pro Produkt funktioniert, solange sich nichts ändert. Das hört typischerweise auf, sobald eine oder mehrere der folgenden Situationen zutreffen:
- Einkaufspreise ändern sich regelmäßig
- mehrere Lieferanten liefern dasselbe Produkt zu unterschiedlichen Kosten
- Margen unterscheiden sich nach Produktfamilie
- B2B-Kunden erhalten andere Preise als Endkunden
- Mengenstaffeln müssen berücksichtigt werden
- unterschiedliche Kanäle brauchen unterschiedliche Preislogik
- Preise müssen automatisch psychologisch gerundet werden (19,99 € statt 20,04 €)
- Mindestmargen dürfen nicht unterschritten werden
- Aktionspreise brauchen einen Vergleichspreis bzw. eine Preishistorie
Trifft nur ein Punkt zu, reicht oft noch eine Tabelle. Kommen mehrere zusammen, wird die Tabelle zur Fehlerquelle - genau der Punkt, an dem eine Pricing Engine anfängt, sich zu lohnen.
Wie eine regelbasierte Preisengine arbeitet
Im Kern folgt jede regelbasierte Preisberechnung demselben Ablauf:
Kostenbasis
↓
passende Regel auswählen
↓
Marge / Aufschlag anwenden
↓
Rundung
↓
Preisart (Verkauf, UVP, Vergleich, B2B)
↓
Ausgabe an Shop / ERP / Marktplatz
Kostenbasis: der Ausgangswert, meist der Einkaufspreis - bei mehreren Lieferanten muss zuerst geklärt werden, welcher Kostenwert gilt (siehe unten).
Regel auswählen: von mehreren möglicherweise zutreffenden Regeln gewinnt die spezifischste (siehe Regelhierarchie).
Marge/Aufschlag anwenden: die eigentliche Formel, die aus Kosten einen Preis macht.
Rundung: der berechnete Rohwert wird auf eine sinnvolle Endziffer gebracht.
Preisart: dieselbe Formel kann für unterschiedliche Preistypen unterschiedlich ausfallen - der B2B-Preis ist selten einfach ein Rabatt auf den Verkaufspreis.
Formelbeispiele
PIMSuite-Preisregeln sind Formeln, keine Freitext-Prozentsätze. Das macht sie lesbar und nachvollziehbar:
| Ziel | Beispiel |
|---|---|
| 40 % Aufschlag | cost * 1.4 |
| 40 % Marge | cost / 0.6 |
| Mindestpreis | max(cost / 0.7, 19.90) |
| psychologische Rundung | Ergebnis → nächste .99 |
| Währungsaufschlag | cost * exchange_rate * 1.35 |
Aufschlag ist nicht dasselbe wie Marge
Das ist eine der häufigsten Fehlerquellen in der Preisgestaltung, und der Unterschied ist größer, als er klingt.
Ausgangskosten: 60 €
- 40 % Aufschlag (
cost * 1.4) → Verkaufspreis 84 €, Marge ≈ 28,6 % - 40 % Marge (
cost / 0.6) → Verkaufspreis 100 €, Marge = 40 %
Wer "40 % drauf" mit "40 % Marge" verwechselt, kalkuliert je nach Fall deutlich zu knapp oder zu großzügig. Weil PIMSuite-Regeln explizite Formeln statt einem einzelnen Prozentfeld sind, ist beim Schreiben der Regel eindeutig, welches der beiden gemeint ist.
Regelhierarchie und Präzedenz
Regeln gelten auf vier Spezifitätsstufen: Standard (alle Produkte), Familie (ein Produkttyp), Lieferant (alle Produkte eines Lieferanten) und Produkt (eine spezifische SKU). Die spezifischste zutreffende Regel gewinnt automatisch.
Ein durchgerechnetes Beispiel:
- Standard: 30 % Marge auf alle Produkte
- Familie "Accessoires": 45 % Marge
- Lieferant X: mindestens 35 % Marge
- SKU ABC123: fixe Ausnahmeregel, 24,99 €
Für ein normales Produkt ohne Sonderregel greift die 30 %-Standardmarge. Gehört es zur Familie "Accessoires", überschreibt die 45 %-Regel den Standard. Kommt es zusätzlich von Lieferant X, gilt die Lieferantenregel nur, wenn sie spezifischer ist als die Familienregel - sonst gewinnt die spezifischere Familienregel. Für SKU ABC123 gilt unabhängig von allen anderen Regeln immer 24,99 €, weil Produktregeln die höchste Spezifität haben.
So lässt sich eine globale Basismarge festlegen und gezielt für bestimmte Familien, Lieferanten oder Einzelprodukte überschreiben, ohne jedes Produkt einzeln anzufassen.
Mehrere Lieferanten, mehrere Kostenquellen
Wenn ein Produkt mehrere Lieferantenzuordnungen hat, wählt ihr, welcher Kostenwert als Berechnungsbasis dient: bevorzugter Lieferant, niedrigster Preis, höchster Preis oder Durchschnitt.
Ein Beispiel: Produkt P wird von drei Lieferanten geführt.
- Lieferant A: 11,20 €
- Lieferant B: 10,50 €
- Lieferant C: 12,00 €
Bevorzugter Lieferant ist die berechenbarste Wahl - der Preis ändert sich nur, wenn sich der Preis dieses einen Lieferanten ändert, unabhängig davon, was die anderen tun.
Niedrigster Preis maximiert die theoretische Marge, ist aber riskant, wenn Verfügbarkeit nicht berücksichtigt wird - der günstigste Lieferant ist nicht zwangsläufig der, von dem tatsächlich geliefert wird.
Höchster Preis kalkuliert konservativ und lässt Marge auf dem Tisch, sobald tatsächlich günstiger eingekauft wird.
Durchschnitt glättet Preisschwankungen, kann aber echte Kostenänderungen einzelner Lieferanten verschleiern.
Ändert Lieferant A morgen seinen Preis, wirkt sich das bei der Strategie "bevorzugter Lieferant" direkt und ausschließlich auf diesen Fall aus; bei "Durchschnitt" nur anteilig; bei "niedrigster Preis" möglicherweise gar nicht, wenn A ohnehin nicht der günstigste war.
Gängige B2B-Preismodelle
B2B-Preisgestaltung ist selten ein einzelner Rabattsatz. Verbreitete Modelle sind:
- Listenpreis
- Kundengruppenpreis
- kundenindividueller Preis
- Staffelpreis (Menge)
- Vertrags- bzw. Preislistenpreis
- kostenbasierter Preis
- Mindestmargenregel
- temporärer Aktionspreis
PIMSuite unterstützt aktuell: kostenbasierte Formelregeln mit der oben beschriebenen Spezifitätshierarchie (Standard/Familie/Lieferant/Produkt) sowie einen eigenständigen B2B/Großhandelspreis pro Produkt.
Modelle, die darüber hinausgehen - etwa kundenindividuelle Vertragspreise oder Mengenstaffeln pro Kunde - liegen häufig näher am ERP oder CRM, das die jeweilige Kundenbeziehung führt. Wo das der Fall ist, integrieren wir eher, als die Logik zu duplizieren (siehe unten).
Rundung
Legt fest, wie berechnete Preise gerundet werden: auf, ab oder zur nächsten Stelle, mit benutzerdefinierter Präzision. Preise wie 19,99 € statt 20,04 € entstehen automatisch als letzter Schritt der Berechnung, nicht als manuelle Korrektur danach.
Preishistorie und die EU-Omnibus-Richtlinie
Für Preisermäßigungen gegenüber Verbrauchern in der EU können die Vorgaben der Omnibus-Richtlinie verlangen, den niedrigsten Preis der letzten 30 Tage vor der Ermäßigung anzugeben. Die genauen Pflichten hängen vom Einzelfall und von der jeweiligen nationalen Umsetzung ab - das ist keine Rechtsberatung, sondern eine allgemeine Einordnung.
Technisch verfolgt PIMSuite jede Preisänderung mit Zeitstempel und berechnet den 30-Tage-Tiefstwert neben dem aktuellen Preis, abrufbar über die API. Die direkte Einbindung dieses Werts in Kanalexporte und -integrationen ist in Arbeit, aber noch nicht live.
Was passiert bei fehlenden oder widersprüchlichen Daten?
Ein produktives Preissystem muss auch mit unvollständigen Eingaben umgehen: fehlender Kostenwert, mehrere gleich spezifische Regeln, ein Rechenergebnis unter der Mindestmarge oder eine nicht verfügbare Währungsumrechnung. Wie robust ein System das abfängt, entscheidet oft darüber, ob ein falscher Preis unbemerkt in einem Shop landet oder rechtzeitig auffällt.
Die Spezifitätshierarchie von PIMSuite löst den häufigsten Konfliktfall - mehrere zutreffende Regeln - deterministisch: Es gewinnt immer die spezifischste Regel. Für die übrigen Fälle (fehlende Kosten, verletzte Mindestmargen, fehlende Wechselkurse) empfehlen wir, Berechnungen vor der Veröffentlichung zu prüfen; eine automatisierte Validierungsschicht dafür ist etwas, das wir je nach Bedarf im Rahmen individueller Entwicklung ergänzen.
Nachvollziehbarkeit
Bei jedem berechneten Preis sollte im Idealfall nachvollziehbar sein, warum er zustande kam - etwa in dieser Form:
Lieferantenkosten: 72,00 €
Regel: Familie "Accessoires" / EU
Formel: cost / 0.58
Berechnet: 124,14 €
Rundungsregel: nächste .99
Endpreis: 124,99 €
PIMSuite speichert jede Preisänderung mit Zeitstempel, und Produktdatensätze führen ein Audit-Log samt Versionshistorie. Eine dedizierte Aufschlüsselung nach Regel und Formel pro Endpreis - wie im Beispiel oben - ist derzeit nicht als fertiger Report verfügbar; wo das für ein B2B-Team entscheidend ist, ist es eine naheliegende Erweiterung.
Wo sollte Preislogik leben - ERP, PIM, Shop oder eigene Engine?
Das ist eine ehrliche Architekturfrage, keine, bei der die Antwort immer gleich lautet.
ERP: sinnvoll, wenn Kosten und Kundenverträge dort die maßgebliche Quelle sind.
PIM: sinnvoll, wenn Preise stark von Produkt- und Lieferantendaten abhängen und an mehrere Kanäle verteilt werden müssen - genau der Fall, für den PIMSuites Engine gebaut ist.
E-Commerce-Plattform: gut geeignet für kanalspezifische Aktionen, Warenkorblogik, Gutscheine und sitzungsbezogene Regeln.
Dedizierte Pricing Engine: sinnvoll bei hochdynamischer, kanalübergreifender Preisbildung mit vielen wechselnden Signalen.
PIMSuites Engine ist dann nützlich, wenn die Regeln in die Produktdatenebene gehören. Ist euer ERP die eigentliche kaufmännische Quelle der Wahrheit, würden wir diese Logik in der Regel eher integrieren als in PIMSuite duplizieren.
Pricing Engine vs. Dynamic Pricing
Eine regelbasierte Pricing Engine berechnet Preise deterministisch aus bekannten Eingaben - Kosten, Marge, Regelspezifität. Dieselbe Eingabe ergibt immer denselben Preis.
Dynamic Pricing verändert Preise anhand sich ändernder Signale wie Nachfrage, Lagerbestand, Wettbewerberpreisen oder Zeit.
KI-gestützte Preisoptimierung geht potenziell noch weiter in Richtung Vorhersage und Optimierung, braucht dafür aber deutlich mehr Kontrolle und Nachvollziehbarkeit.
PIMSuites Engine ist die erste Kategorie: nachvollziehbar und regelbasiert, nicht wettbewerbs- oder nachfragegetrieben.
Pricing Engine vs. CPQ
Ein CPQ-System (Configure, Price, Quote) konfiguriert komplexe, oft kundenindividuelle Angebote - in der Regel vertriebsgestützt und für Sonderfälle gedacht.
Eine Pricing Engine löst Preise programmatisch und im großen Maßstab auf, für den gesamten Katalog statt für ein einzelnes Angebot.
Beide können sich überschneiden, sind aber nicht dasselbe: Ein CPQ-System braucht oft eine Pricing Engine im Hintergrund, aber eine Pricing Engine ersetzt kein CPQ für komplexe Sonderangebote.
Wie PIMSuite das konkret umsetzt
PIMSuite verwaltet vier eigenständige Preise pro Produkt - Verkaufspreis, UVP, Vergleichspreis und B2B-Preis, jeweils mit eigener Währung. Preisregeln sind Formeln (cost * 2.4, round(cost / 0.6, 2)), lesbar und nachvollziehbar. Sie gelten auf den vier oben beschriebenen Spezifitätsstufen, mit automatischer Auflösung nach Spezifität. Bei mehreren Lieferanten wählt ihr die Kostenquellen-Strategie. Rundung ist konfigurierbar. Und eine Regel lässt sich auf Tausende Produkte in einem Vorgang anwenden - die Engine berechnet und speichert jeden betroffenen Preis neu, ohne dass irgendwo eine Tabellenformel gepflegt werden muss. Die Regeln werden zentral in PIMSuite verwaltet.