B2B-Preisfindung: kundenspezifische Preise, Caching und Audits

Eine B2B-Preis-Engine entscheidet, welchen Nettopreis ein angemeldeter Käufer für eine SKU sieht, abhängig davon, wer er ist, welchen Vertrag seine Firma hat, wo er kauft, wie viele Einheiten er bestellt, in welcher Währung und an welchem Datum. Die Berechnung ist die leichte Hälfte. Die schwere Hälfte ist der Betrieb: Preise cachen, die je Kunde verschieden sind, ohne sie dem falschen Kunden zu zeigen, einen Preis drei Monate später im Streitfall erklären und die Umsatzsteuer genauso runden wie die Rechnung.

Dieser Artikel zeigt, wie die großen Plattformen kundenspezifische Preise auflösen (Spryker, Pimcore, die SAP-Konditionstechnik, commercetools, Adobe Commerce und Shopify B2B), und behandelt dann Caching, Audit, Tests und Umsatzsteuer. Wie ein Konfigurator Optionen bepreist, steht in Headless-Produktkonfiguratoren im B2B; wie Preise hinter einem Login als strukturierte Daten ausgeliefert werden, steht in schema.org-Daten für B2B-Shops.

Wie werden B2B-Preise bestimmt?

Meist bestimmen sieben Dimensionen einen B2B-Preis: der Kunde, die Kundengruppe oder Firma, der Vertrag, die Region oder der Vertriebskanal, die Mengenstaffel, die Währung und das Gültigkeitsdatum. Eine Preis-Engine sucht die spezifischste Regel, die zu allen passt, und fällt Schritt für Schritt auf einen allgemeinen Basispreis zurück, wenn es nichts Spezifischeres gibt.

• Kunde: ein individueller Preis für ein Käuferkonto, oft für eine Handvoll Kernartikel.
• Kundengruppe oder Firma: eine Preisliste für ein Segment, etwa Händler, Installateure oder alle Töchter einer Firma.
• Vertrag: eine verhandelte Vereinbarung mit Laufzeit, manchmal mit eigenen Mengenzusagen.
• Region oder Kanal: Land, Store oder Vertriebskanal, der auch die steuerliche Behandlung bestimmt.
• Mengenstaffel: die Staffelstufe, die die bestellte Menge erreicht.
• Währung: Preise werden je Währung gepflegt, nicht spontan umgerechnet.
• Gültigkeitsdatum: Start- und Enddatum, damit die Preise des nächsten Quartals vorab geladen werden können.

Die Dimensionen multiplizieren sich. Sprykers Leitfaden zu ERP-geführten Preisen rechnet ein Beispiel vor: 1.000 Kunden mal 25.000 Produkte, gezählt für abstrakte und konkrete Produkte, ergeben 50 Millionen theoretische Preissätze. Bei 20 Prozent Vertragsabdeckung sind es noch etwa 20 Millionen, der Punkt, an dem laut Leitfaden die Standard-Sync-Pipeline „ernsthaft nachzulassen beginnt“ (Spryker). Deshalb sind die Fragen, wo Preise liegen und wie sie gecacht werden, wichtiger als die Formel.

Wo Preise liegen und in welcher Reihenfolge sie aufgelöst werden

Preise haben meist drei mögliche Orte: das ERP, das verhandelte Konditionen hält und meist das führende System ist; das PIM, das Listenpreise als Produktattribute halten kann; und die Commerce-Plattform, die Preislisten oder Preisdimensionen für schnelle Lesezugriffe hält. Entscheidend ist, welches System maßgeblich ist und wie veraltet eine Kopie in einem anderen System sein darf. Bei Produktdaten stellt sich dieselbe Frage, siehe den Pimcore-ERP-Delta-Sync.

In SAP S/4HANA entscheidet die Konditionstechnik. Das System wählt ein Kalkulationsschema aus Verkaufsbereich, Verkaufsbelegart und Auftraggeber. Jede Konditionsart im Schema hat eine Zugriffsfolge, die Konditionstabellen der Reihe nach durchsucht, vom spezifischsten zum allgemeinsten Schlüssel, bis sie einen gültigen Konditionssatz findet. Mengenstaffeln wählen dann die Staffelstufe, und Kopfkonditionen werden nach Nettowert auf die Positionen verteilt, sofern nichts anderes eingestellt ist (SAP Learning).

commercetools dokumentiert seine Preisauswahl als achtstufigen Fallback, von Kundengruppe plus Kanal plus Land bis hinunter zum Basispreis. Innerhalb jeder Stufe gewinnen Preise mit Gültigkeitszeitraum gegen Preise ohne, und passen danach noch mehrere, gewinnt der günstigste. Staffelpreise werden ignoriert, wenn bereits ein Produktrabatt greift (commercetools).

Spryker speichert Preise als Ganzzahlen in der kleinsten Währungseinheit, jeweils mit Preistyp sowie Brutto- und Nettowert pro Preismodus. Beim Lesen wird zuerst das konkrete Produkt geprüft, dann auf das abstrakte zurückgefallen. Staffelpreise folgen derselben Vererbung: Die eigenen Staffelpreise eines konkreten Produkts überschreiben die abstrakten, und sie unterstützen nur den Standardpreistyp (Spryker-Preise, Spryker-Staffelpreise). Kundenspezifische Preise entstehen über Preisdimensionen: Der dokumentierte Weg erweitert die Kunden- und Preistabellen um eine Gruppen-ID und exportiert Preise pro Gruppe in den Key-Value-Store.

Pimcores E-Commerce-Framework gibt jedem Produkt ein Preissystem, das PriceInfo-Objekte liefert. Das eingebaute AttributePriceSystem liest den Preis aus einem Produktattribut, und alles, was aus dem ERP kommt, wird ein eigenes, in der Konfiguration registriertes Preissystem (Pimcore). Preisregeln wenden dann Rabatte als Paare aus Bedingung und Aktion auf diesen Preis an.

Plattformen im Vergleich

Die Plattformen sind sich einig, dass die spezifischste Regel gewinnt, und unterscheiden sich darin, wo Gleichstände entschieden werden und was sie für Audits bieten. Die Tabelle fasst zusammen, was jede Stand Oktober 2026 dokumentiert.

Zwei dokumentierte Regeln überraschen viele. In Adobe Commerce erhöht ein fester Sonderpreis in einem Shared Catalog den Preis nie: Verwendet wird das Minimum aus Basispreis und Festwert (Adobe). In Shopify B2B wird der Preis fest, sobald ein Staffelpreis greift, sodass eine katalogweite prozentuale Anpassung ihn nicht mehr senkt, und Mengenregeln gelten pro Variante, sodass ein Käufer Varianten nicht kombinieren kann, um ein Minimum zu erreichen (Shopify).

Personalisierte Preise cachen, ohne sie preiszugeben

Ein personalisierter Preis lässt sich cachen, solange jede Dimension, die den Preis ändert, Teil des Cache-Schlüssels ist. Ist der Schlüssel nur die URL, bestimmt der erste Käufer, der eine Produktseite lädt, den Preis für alle späteren Käufer. Das ist zugleich ein falscher Preis und ein Datenleck: Der Vertragspreis eines Kunden wird einem anderen gezeigt.

• Schlüssel nach Preisdimensionen, nicht nach Benutzer. Cachen Sie pro Preisliste oder Kundengruppe, nicht pro Benutzer-ID, sonst bricht die Trefferquote ein. Cloudflare erlaubt Header, Cookies und Nutzermerkmale in eigenen Cache-Schlüsseln, aber diese Optionen gibt es nur im Enterprise-Tarif, und die Doku warnt, dass eigene Schlüssel den Cache zersplittern können (Cloudflare).
• Antworten für die Invalidierung taggen. Mit dem xkey-Modul von Varnish versieht das Backend jede Antwort mit Surrogate Keys wie SKU und Preisliste. Ein Purge-Aufruf leert jedes Objekt mit diesem Schlüssel, softpurge behält sie für den Grace-Modus, und die README rät, den Purge-Endpunkt per ACL zu schützen (xkey).
• Beim Geschäftsereignis leeren. Eine Vertragsänderung, ein neuer Preisimport oder ein ERP-Delta sendet die betroffenen SKU- und Preislisten-Tags. Eine TTL allein lässt den alten Vertragspreis bis zum Ablauf live.
• Den Cache nie zum einzigen Speicher machen. Sprykers Leitfaden warnt, dass Preise, die nur in einen Cache geschrieben werden, ein Datenverlustrisiko darstellen, wenn der Cache verloren geht (Spryker).

Für ERP-geführte Preise empfiehlt derselbe Leitfaden als Standard ein Hybridmodell: Ein lokales Lesemodell bedient Katalog und Warenkorb, und der Checkout prüft erneut gegen das ERP, sodass der endgültige Preis bei der Bestellung bestätigt wird. Altern gecachte ERP-Preise, zeigt die Seite einen Aktualitätshinweis wie „Preis von 14:23“, statt so zu tun, als sei die Zahl live. Das Ziel im Leitfaden ist ein Preisabruf unter 100 ms pro Storefront-Anfrage.

Einen Preis prüfen und erklären

Früher oder später fragt jemand, warum Kunde X an einem bestimmten Tag Preis Y gesehen hat. Muss man dafür die heutigen Regeln auf die heutigen Daten anwenden, gibt es keine Antwort, denn Vertrag, Staffeltabelle und Basispreis haben sich seitdem geändert. Die Antwort muss in dem Moment gespeichert werden, in dem der Preis verwendet wird.

Speichern Sie an jeder Auftragsposition einen Preis-Snapshot zum Bestellzeitpunkt: den aufgelösten Nettopreis, die siegreiche Regel und die unterlegenen Kandidaten, Preislisten- und Vertrags-IDs mit Versionen, die Mengenstaffel, die Währung, den Steuersatz und den Rundungsmodus. Der Snapshot kostet einige hundert Byte pro Position und macht aus einem Streitfall ein Nachschlagen. Das Beispiel unten ist illustrativ, Beträge in Cent.

{
  "orderLine": "SO-2026-104233/3",
  "sku": "VLV-200-DN50",
  "quantity": 24,
  "resolvedAt": "2026-10-07T09:14:03Z",
  "currency": "EUR",
  "unitNet": 18350,
  "winningRule": { "type": "contract", "id": "CT-7781", "version": 4, "tier": "20+" },
  "candidates": [
    { "type": "customerGroup", "id": "PL-INSTALLERS", "unitNet": 19100 },
    { "type": "base", "id": "PL-BASE-EUR", "unitNet": 22400 }
  ],
  "taxRate": "19.00",
  "rounding": "HALF_UP per line",
  "priceSource": "erp-read-model",
  "priceAgeSeconds": 412
}

Die Plattformen liefern einen Teil des Rohmaterials. commercetools erzeugt Messages für Änderungen an Ressourcen, darunter eigene Pricing- und Discount-Messages für eigenständige Preise, aber Messages werden standardmäßig nicht gespeichert und müssen aktiviert werden (commercetools Messages). Pimcore kann die auf ein PriceInfo angewandten Preisregeln auflisten, und in SAP trägt jede Belegposition die Konditionssätze, die ihre Zugriffsfolgen gefunden haben. Nichts davon ersetzt einen Snapshot unter Ihrer Kontrolle, denn diese Quellen ändern sich oder verfallen nach eigenem Zeitplan.

Preisanomalien sind ein guter Ort für Automatisierung, die ihre Grenzen kennt. Eine Prüfung, die Positionen markiert, deren berechneter Preis um mehr als eine Toleranz vom aufgelösten abweicht, sollte den Fall an einen Menschen geben, nicht automatisch korrigieren. Mein Skill jev-decide folgt demselben Muster: Eine Entscheidung mit niedriger Konfidenz geht an einen Menschen, statt angewendet zu werden.

Preislogik mit Golden Snapshots testen

Preislogik ist eine Matrix aus Kunde, Vertrag, Region, Menge, Währung und Datum. Wählen Sie je Dimension wenige repräsentative Werte, berechnen Sie den aufgelösten Preis für jede Kombination und legen Sie das Ergebnis als Golden File im Repository ab. Playwright schreibt beim ersten Lauf einen Golden Snapshot, vergleicht jeden späteren Lauf damit und aktualisiert ihn nur mit --update-snapshots; toMatchSnapshot() funktioniert mit beliebigem Text, nicht nur mit Screenshots (Playwright).

import { test, expect } from '@playwright/test'
import { resolvePrice } from '../src/pricing'
import { customers, skus, quantities, dates } from './price-matrix'

// One row per combination; the golden file is reviewed like code
test('price matrix matches the golden file', () => {
  const rows: string[] = []
  for (const c of customers) for (const sku of skus) for (const qty of quantities) for (const date of dates) {
    const p = resolvePrice({ customer: c, sku, quantity: qty, date, currency: 'EUR' })
    rows.push([c.id, sku, qty, date, p.unitNet, p.winningRule.id].join(';'))
  }
  expect(rows.join('\n')).toMatchSnapshot('price-matrix.txt')
})

Golden Files fangen Regressionen in konkreten Fällen; eigenschaftsbasierte Tests fangen Verstöße gegen die allgemeinen Regeln. Mit fast-check formulieren Sie Invarianten, und die Bibliothek erzeugt Hunderte Eingaben und schrumpft jeden Fehler auf einen minimalen Fall (fast-check). Nützliche Invarianten: Die Auftragssumme ist die Summe der gerundeten Positionssummen, eine höhere Staffel liefert nie einen höheren Stückpreis, brutto liegt bei positivem Steuersatz nie unter netto, und ein kundenspezifischer Preis liegt nie über dem Basispreis, wo die Geschäftsregel das verbietet.

Lassen Sie die Matrix nach jedem Preisimport und jedem ERP-Delta laufen, nicht nur bei Codeänderungen, denn die meisten Preisfehler kommen aus Daten, nicht aus Code. Auf der Storefront-Seite steuere ich mit Playwright MCP den echten Shop mit verschiedenen angemeldeten Rollen und vergleiche nach einer Vertragsänderung den angezeigten mit dem aufgelösten Preis.

Umsatzsteuer, Rundung und Preismodus-Fallen

B2B-Preise werden meist netto gepflegt und angezeigt, Verbraucherpreise brutto, und eine Plattform muss wissen, welche Variante sie speichert. Spryker hält den Preismodus, brutto oder netto, am Quote fest, und ein Quote kann nicht beide zugleich nutzen. Die Dokumentation zeigt auch die Folge: Im Bruttomodus bleibt ein Produkt mit €100 netto und 20 % Steuer in der Region des Stores beim Verkauf in eine Region mit 10 % Steuer bei €120 brutto, der Nettobetrag wird also €109,09 (Spryker).

Dieselben Schlussanträge halten fest, dass keine Vorschrift der EU-Mehrwertsteuerrichtlinien die Rundung ausdrücklich regelt, die Einzelheiten also nationales Recht im Rahmen der EU-Grundsätze sind, und dass bei Nettorechnungen zwischen Unternehmen die Verzerrungen entweder nicht entstehen oder stark abgeschwächt sind. Die HMRC-Regel ist ein konkretes Beispiel: Steuer unter 0,5 Pence wird abgerundet, ab 0,5 Pence aufgerundet, und andere Verfahren sind zulässig, wenn sie ein faires und angemessenes Ergebnis liefern (HMRC). Für Verbraucher verlangt die Preisangabenrichtlinie den Verkaufspreis einschließlich Umsatzsteuer, ein Grund, warum B2C-Shops brutto und B2B-Shops netto denken (Richtlinie 98/6/EG).

Machen Sie Rundung im Code explizit. commercetools bietet Rundung als Konfiguration an, mit den Modi HalfUp, HalfDown und HalfEven sowie getrennten Warenkorb-Einstellungen für Preisrundung, Steuerrundung und Steuerberechnung, und weist darauf hin, dass B2B-Preise oft Genauigkeit unter einem Cent brauchen. In PHP speichert moneyphp Beträge als Strings, und allocate() teilt €10,00 deterministisch in 334, 333 und 333 Cent auf (moneyphp). Speichern Sie Preise als Ganzzahlen in der kleinsten Einheit oder über eine Money-Bibliothek, nie als Gleitkommazahlen.

Wann Sie keine eigene Preis-Engine bauen sollten

Die meisten B2B-Shops sollten keine Preis-Engine bauen, sondern einen Preis-Adapter. Wenn das ERP Konditionen bereits korrekt auflöst, erzeugt eine Kopie dieser Logik im Shop zwei Engines, die auseinanderlaufen. Das Hybridmuster lässt das ERP maßgeblich: aufgelöste Preise in ein Lesemodell für den Katalog replizieren, im Checkout erneut prüfen und Veraltung zeigen statt verbergen.

Bauen Sie die Auflösung im Shop, wenn das ERP bei Ihrer Kataloggröße nicht schnell genug für das Browsen antwortet, wenn der Shop Dinge verkauft, die das ERP nicht bepreist, etwa konfigurierte Optionen oder Marktplatzangebote, oder wenn die ERP-Regeln so einfach sind, dass ein Preislistenimport sie abdeckt. Auch dann gilt: ein Eigentümer pro Preisregel, und das andere System ist eine Kopie mit bekanntem Höchstalter.

„Preis auf Anfrage“ verdient einen eigenen Geschäftszustand mit eigenem Ablauf, keinen Fehler. Passt keine Regel, ist eine Angebotsanfrage besser als ein Basispreis, auf den der Kunde keinen Anspruch hat, und besser als ein fehlender Preis, der wie ein Bug aussieht. Danach übernimmt die Angebotsbearbeitung, wie in RFQ-Automatisierung mit LLMs beschrieben.

Eine Checkliste, bevor Sie Preise anfassen

In meiner Arbeit mit Spryker und Pimcore ist die Frage, wo Preise liegen, die erste, die geklärt werden muss. Diese Liste sollte man durchgehen, bevor man Indizes, Caches oder Importer ändert, die Preise berühren.

1. Dimensionen und Auflösungsreihenfolge festhalten, einschließlich der Entscheidung bei Gleichstand innerhalb einer Stufe.
2. Für jede Preisregel einen Eigentümer und für jede Kopie ein Höchstalter benennen.
3. Jede preisverändernde Dimension in den Cache-Schlüssel aufnehmen, nichts pro Benutzer.
4. Gecachte Preise nach SKU und Preisliste taggen und bei Vertragsänderung leeren, nicht nur per TTL.
5. Im Checkout erneut prüfen und das Alter des Preises zeigen, wenn er nicht live ist.
6. Einen Preis-Snapshot zum Bestellzeitpunkt mit Regel-IDs, Versionen, Steuersatz und Rundungsmodus speichern.
7. Eine Golden-Preismatrix und Eigenschaftstests pflegen und nach jedem Import ausführen.
8. Eine Rundungsregel für Shop, ERP und Rechnung dokumentieren und Ganzzahlen oder eine Money-Bibliothek verwenden.
9. „Preis auf Anfrage“ als Zustand mit eigenem Ablauf behandeln.

Wenn Sie kundenspezifische Preise zwischen Shop und ERP entwirren, sehen Sie sich meine B2B-E-Commerce-Arbeit an. Vertriebsmitarbeiter, die einem Kunden einen Preis erklären müssen, profitieren von denselben Snapshot-Daten, siehe einen KI-Copiloten für den B2B-Vertrieb.

Quellen

1. Spryker docs: prices feature overview (Sep 2026)
2. Spryker docs: price explosion and ERP-owned pricing in B2B (Sep 2026)
3. Spryker docs: volume prices overview
4. commercetools docs: pricing and discounts overview
5. SAP Learning: introducing the condition technique
6. Pimcore docs: price systems and getting prices (2026.3)
7. Adobe Experience League: shared catalog pricing structure (Oct 2026)
8. Shopify Help Center: B2B quantity rules and volume pricing
9. Varnish libvmod-xkey README
10. Opinion of the Advocate General in Case C-484/06 (Koninklijke Ahold)
11. HMRC internal manual VATREC12030: rounding of VAT
12. Playwright docs: snapshot testing