Preislogik zwischen ERP und Shop: Wo B2B-Preise modelliert werden

Listenpreise sind im B2B die Ausnahme. Jeder Einkäufer bringt eigene Konditionen mit, ausgehandelt, vertraglich fixiert, über Jahre gewachsen. Wie können komplexe Preismodelle so orchestriert werden, dass sie sowohl ERP als auch Shop gerecht werden? 

Während das ERP-System das "System of Record" bleibt, wird häufig versucht, ERP-Logik im Shop nachzubauen oder Preislisten in den Shop zu kopieren. 10.000 SKUs × 150 Kunden ergeben potenziell 1,5 Mio. Preis-Kombinationen. Spätestens hier wird klar: Preislogik ist kein Shop-Feature und kein Exportproblem. Der Shop braucht Geschwindigkeit und Kontext, das ERP Verbindlichkeit und Kontrolle. Dazwischen braucht es eine Entscheidungsebene, die Preise in Echtzeit orchestriert, also mit Daten wie Kunde, Vertrag, Menge, Lieferland, Währung, Sortiment, Bonusstaffel, Rabattgruppe, Kampagne, Verfügbarkeit, Marge verknüpft. Dazu Regeln kanalübergreifend konsistent anwendet und verhindert, dass aus gewachsenen Konditionen im digitalen Vertrieb gefährliche doppelte Wahrheiten entstehen.

Dieser Beitrag klärt, wo kundenspezifische Preise, Staffeln, Rahmenverträge und Net-Price-Kaskaden im B2B modelliert gehören. Du erfährst, warum weder das ERP allein noch das Shopsystem allein trägt, ab welcher Schwelle die Preisbildung im Frontend kippt und wie eine Orchestrierungsschicht zwischen ERP und Kanälen die Kombinatorik konsistent ausspielt.

Kurz zur Einordnung: Kundenspezifische Preise verdichten sich zum Net Price, dem tatsächlich zu zahlenden Nettopreis ohne Umsatzsteuer. Aus welchen Dimensionen B2B-Preise bestehen, welche Preismodelle es gibt und wie Preis und Sortiment zusammenhängen, darauf geht der Überblicksbeitrag Komplexe B2B-Preise und Sortimente digital steuern ein. Die grundlegenden Methoden der Preisbildung vertieft der Glossarbeitrag zur Preisgestaltung.

Hier geht es um die Frage, wo Preise tatsächlich modelliert werden, um doppelte Wahrheiten zu vermeiden und gleichzeitig Schnelligkeit und Agilität zu erreichen. Doch zunächst: Wie werden Preise moduliert?

Welche Preisgranularität braucht dein Geschäft? Kundengruppen oder Einzelkundensatz

Die erste Architekturentscheidung ist die Granularität. Auf welcher Ebene werden unterschiedliche Preise verlangt? Kundengruppen bündeln Konditionen nach Segment, etwa Fachhändler, Großkunde oder OEM, und bleiben wartbar. Einzelkundensätze bilden jeden Debitor exakt nach Vertrag ab, treiben aber Pflege und Synchronisation in die Höhe. Die Wahl bestimmt, wie viele Preissätze dein System dauerhaft konsistent halten muss.

In der Praxis koexistieren beide Stufen: Gruppen als Basis, Einzelsätze für die Schlüsselkunden. Jede zusätzliche Staffel, jeder Rahmenvertrag und jede befristete Aktion legt eine weitere Dimension darüber. Dieselbe Position trägt dann je nach Menge, Kundengruppe und Gültigkeitszeitraum einen anderen Preis. Damit das eindeutig bleibt, braucht es zwei Dinge, die Standard-Regelwerke selten sauber lösen: Gültigkeitszeiträume und eine klare Vorrangordnung, welche Kondition eine andere aussticht.

Vom Listenpreis zum Net Price: die Reihenfolge entscheidet

Der Net Price entsteht aus einer Kaskade. Vom Listenpreis gehen nacheinander ein allgemeiner Rabatt, ein kundenspezifischer Rabatt, der Mengenrabatt aus der Staffel und gegebenenfalls ein Aktionsrabatt ab. Dazu kommen Zu- und Abschläge, etwa ein tagesaktueller Materialzuschlag oder ein Gefahrgutzuschlag. Die Reihenfolge dieser Schritte ist nicht beliebig, denn sie verändert das Ergebnis.

So berechnet sich der Net Price

Net Price = Listenpreis - allgemeiner Rabatt - kundenspezifischer Rabatt - Mengenrabatt - Aktionsrabatt +/- Zu- und Abschläge

Ein Beispiel: Listenpreis 100 Euro, allgemeiner Rabatt 10 Prozent, kundenspezifischer Rabatt 5 Prozent, Mengenrabatt 3 Prozent. Kaskadiert gerechnet ergibt das 100 auf 90 auf 85,50 auf 82,92 Euro. Würdest du dieselben Prozente addieren und einmal 18 Prozent abziehen, lägest du bei 82,00 Euro. Die Differenz wirkt klein, summiert sich über tausende Positionen aber zu echtem Geld.

Hier sitzt der Kern des Problems: Solange nicht eindeutig definiert ist, welcher Rabatt zuerst greift und welcher einen anderen aussticht, produziert das System Preise, die im Audit nicht standhalten. An diesem Punkt wird aus einer Liste von Rabatten eine echte Konditionstechnik, und genau diese Technik braucht einen festen Ort.

Welche Preise gehören vor den Login, welche dahinter?

Viele Hersteller zeigen im B2B-Frontend ungern Preise, aus Sorge vor dem Wettbewerb. Dagegen wollen Einkäufer eine preisliche Orientierung bekommen, bevor sie in einen Dialog einsteigen, und springen ohne jegliche Preisangabe ab.

Ein möglicher Weg, um beiden Anforderungen gerecht zu werden, ist folgender: Im öffentlichen Bereich steht ein klar bezeichneter Listenpreis, der Interessenten und Neukunden Orientierung gibt und der Suchmaschine ein indexierbares Signal liefert, ohne eine ausgehandelte Kondition preiszugeben. Nach dem Login sieht der Bestandskunde seine kundenspezifischen Preise, Staffeln und Rahmenvertragskonditionen aus derselben zentralen Quelle, netto und exakt so, wie der Vertrieb sie nennen würde. Der Listenpreis bedient damit die Orientierung vor dem Erstkontakt, die individuelle Kondition den angemeldeten Bestandskunden.

Wann stoßen ERP und Shop bei der Preisbildung an Grenzen?

Manche B2B-Shopsysteme können einzelne komplexe Preisregeln durch Regelwerke durchaus abbilden. Die Grenze liegt nicht in der einzelnen Regel, sondern in der Fülle an Regeln, deren Reihenfolge und Zusammenhänge reine Shopsysteme schnell überfordern. Diese Schwelle solltest du kennen, bevor du immer mehr Logik ins Frontend verlagerst. Woran kannst du die Grenzen erkennen?

Der erste Effekt ist die Menge. Eine Regel-Engine prüft bei jedem Seitenaufruf, jedem Warenkorb-Update und jedem Checkout alle aktiven Regeln. Bei tausenden kundenspezifischen Sätzen mit Staffeln und Gültigkeiten wird die Synchronisation teuer und die Fehlersuche bei Abweichungen zäh. Nicht die einzelne Regel bremst, sondern die Masse redundanter Sätze.

Der zweite Effekt ist die Kombinatorik. Sobald mehrere Rabatte, Zu- und Abschläge und befristete Aktionen zusammentreffen, stellt sich bei jeder Position die Vorrangfrage. Ein Wenn-dann-Werkzeug stößt hier an seine Logik, erst recht bei identischen Preisen über Außendienst, Frontend, Marktplatz und EDI hinweg.

Der dritte Effekt ist organisatorisch und wird am häufigsten unterschätzt. Das ERP behält zu Recht die Preishoheit, ist aber oft in der Verantwortung einer commerce-fernen IT oder einem externen Dienstleister. Änderungswünsche laufen über Tickets und Releasezyklen, der Vertrieb hat keinen direkten Zugriff auf die Modellierung. Diese fehlende Beweglichkeit bremst kundenspezifische Preise stärker als jede Rechenlast, und die unkontrollierten Rabatte, die aus Zeitdruck statt aus einer Regel entstehen, zählen zu den größten Margenkillern im B2B.

Daraus folgen zwei naheliegende Auswege, die beide in eine Sackgasse führen. Wird die Preislogik ins Shopsystem kopiert, entstehen doppelte Wahrheiten. Die Rechnung sagt dann etwas anderes als der Warenkorb, der Außendienst sieht andere Konditionen als der Kunde im Portal, Vertragsänderungen kommen verzögert an, und jede neue Rabattregel wird zum Frontend-Projekt. Bleibt umgekehrt die gesamte Last im ERP, schlägt die Performance zu. Kategorieseiten mit hundert Artikeln werden zu hundert Preisabfragen, Warenkörbe werden langsam, Caches riskant. Dann hängt der digitale Vertriebserfolg an der Antwortzeit einer Schnittstelle statt an der Preisstrategie.

Preismodellierung abseits von ERP und Shop

Die Auflösung liegt zwischen den beiden Polen, und sie entmachtet weder das ERP noch verbiegt sie das Frontend. Das ERP bleibt die kaufmännische Wahrheit für Grundpreise, Konditionen und Kosten. Das Zusammensetzen, Vorberechnen und Pflegen der Preislogik wandert in eine eigene Preis-Orchestrierungsschicht, die der Handel ohne Code-Eingriff steuert. So bleibt die Hoheit, wo sie hingehört, und die Modellierung dort, wo Geschwindigkeit sitzt.

Diese Schicht respektiert das ERP als kaufmännische Wahrheit und macht Preisentscheidungen kanalübergreifend verfügbar, für Frontend, Kundenportal, Außendienst-App, CPQ, Marktplatz, EDI oder PunchOut. Sie arbeitet wie eine Datendrehscheibe: Sie zieht die Konditionen aus dem ERP, verdichtet sie zu einer konsistenten Preismatrix und orchestriert für jeden Kanal genau die Preise, die für ihn gelten. Die Kombinatorik aus Rabatten, Staffeln, Zu- und Abschlägen und Gültigkeiten wird einmal definiert und überall identisch angewendet, statt in jedem Kanal neu nachgebaut zu werden. Das Frontend bleibt schnell, weil es fertige Preise abruft statt sie live zu errechnen, und das ERP bleibt von Last verschont, für die es nie gebaut war.

Tausende Kataloge, über 3.500 Staffeln, ein SAP: das manroland-Projekt

Wie weit dieses Muster trägt, zeigt das B2B-Portal von manroland goss web systems, einem weltweiten Hersteller von Rollenoffset-Druckmaschinen. Jede Maschine ist ein Unikat, jeder Kunde bestellt seine spezifischen Ersatz- und Verschleißteile zu eigenen Konditionen. Nach dem Login stehen tausende kundenspezifische Produktkataloge mit live verfügbaren Beständen bereit, über 3.500 Rabatt-Staffeln steuern die Einpreisung für Kunden und Kundengruppen. Aus dieser Kombinatorik ergeben sich über zehn Millionen einzelne Preis-Produkt-Kombinationen, die mit der Vorgängerversion von Hublify verwaltet wurden. 

Die Architektur folgt exakt der Trennung von Hoheit und Modellierung. Das SAP-System bleibt führend und speist Produkt-, Katalog-, Preis- und Kundendaten über eine Schnittstelle ein, Bestellungen laufen denselben Weg zurück. Im öffentlichen Bereich steht ein Katalog ohne Preise für die Auffindbarkeit, hinter dem Login die vollen individuellen Konditionen. Internationale Marktorganisationen bestellen über dieselbe Oberfläche auf eigene Rechnung für ihre Kunden. Die Komplexität ließ sich hier abbilden, weil die Logik an der richtigen Stelle verankert war.

Die Preishoheit bleibt im ERP, die Modellierung gehört in die Schicht dazwischen

Kundenspezifische Preise im B2B sind kein Feature, das man aktiviert. Sie sind ein Modellierungsprozess, der eine saubere Datenbasis braucht und einen Ort, an dem die Logik schnell und ohne Politik gepflegt wird. Das ERP liefert die Wahrheit, das Frontend zeigt das Ergebnis, und dazwischen entsteht der eigentliche Wert: eine Schicht, die Konditionen, Staffeln, Verträge und Aktionen zu einem konsistenten Preis verdichtet und über alle Kanäle ausspielt.

„Produktinformationen aus dem SAP, aus verteilten Listen und Anwendungen werden bei uns in Hublify PIM zentral verwaltet und an den Shopify Shop und weitere Marktplätze ausgeleitet. Die Bestellungen kommen aus den verschiedenen Channels zurück und werden in Hublify weiterverarbeitet zur Übergabe ans SAP." 
Thomas, Atera GmbH

Genau diese Rolle übernimmt Hublify als Commerce-Backend. Es setzt sich wie Fugenkitt zwischen ERP und Verkaufsfrontend, verbindet die Systeme über offene Schnittstellen und modelliert die Preislogik dort, wo der Handel sie steuern kann. Wenn du gerade überlegst wie du komplexe Preise abbilden kannst und wo deine Preislogik künftig sitzen soll, lass uns gerne darüber sprechen.

Häufige Fragen zur Modellierung von B2B-Preisen

Wo sollte die Preislogik liegen, im ERP oder im Shop?

Die Preishoheit gehört in das ERP, weil dort die Konditionen und Kosten kaufmännisch geführt werden. Die Modellierung und Ausspielung gehört in eine Schicht zwischen ERP und Verkaufsfrontend. So bleibt das Frontend schnell, das ERP unbelastet, und die Logik muss nicht doppelt gepflegt werden.

Warum scheitern komplexe B2B-Preise im Shopsystem?

Nicht an der einzelnen Regel, sondern an der Skalierung: an der Masse kundenspezifischer Sätze, an der Vorrangfrage bei verschachtelten Konditionen und an der Konsistenz über mehrere Kanäle. Wird die Logik ins Frontend kopiert, entstehen doppelte Wahrheiten zwischen Warenkorb, Rechnung und Außendienst.

Was ist eine Preis-Orchestrierungsschicht?

Eine Ebene zwischen ERP und Verkaufskanälen, die Konditionen aus dem ERP bezieht, die vollständige Preislogik vorberechnet und jedem Kanal konsistente Preise ausspielt. Das ERP behält die Hoheit, die Modellierung erfolgt zentral, und Frontend, Marktplatz, Außendienst und EDI ziehen dieselben Konditionen. Üblicherweise übernimmt diese Rolle ein PIM-System.

Behält das ERP die Preishoheit, wenn Preise woanders modelliert werden?

Ja. Die kaufmännische Wahrheit über Grundpreise, Konditionen und Kosten bleibt im ERP. Die Orchestrierungsschicht setzt darauf auf, sie ersetzt das ERP nicht, sondern übersetzt seine Konditionen in eine kanalübergreifend nutzbare Preismatrix.

Wie berechnet sich der Net Price im B2B?

Der Net Price entsteht kaskadiert aus dem Listenpreis, von dem nacheinander allgemeiner Rabatt, kundenspezifischer Rabatt, Mengenrabatt und Aktionsrabatt abgehen, ergänzt um Zu- und Abschläge. Die Reihenfolge der Schritte ist entscheidend, weil kaskadierte und addierte Rabatte zu unterschiedlichen Ergebnissen führen.