B2B-Preise in Magento Open Source: drei Architektur-Muster

B2B-Preise in Magento sind selten ein Standardthema. Sobald ein Shopbetreiber „wir brauchen Staffelpreise pro Kunde” sagt, sind drei Folgefragen schon im Raum: Sind die Preise Netto oder Brutto, wo kommen sie her, und wie individuell müssen sie pro Kunde sein. Adobe Commerce mit dem B2B-Modul liefert dafür Companies, Negotiable Quotes und Shared Catalogs als fertige Features — aber für die allermeisten österreichischen B2B-Shops, mit denen wir arbeiten, ist Adobe Commerce keine realistische Option. Die Lizenzkosten beginnen im fünfstelligen Bereich pro Jahr und der Funktionsumfang ist deutlich größer als das, was die Shops tatsächlich brauchen. Magento Open Source bringt mit Customer Groups und Tier Prices die Grundlagen mit; alles darüber baut man entweder per Konfiguration, per externer Datenquelle oder per eigenem Modul. In diesem Beitrag gehen wir drei Architektur-Muster durch, die wir in laufenden Shops umgesetzt haben — vom Standard bis zur vollständig eigenen Preislogik.

Was Magento Open Source für B2B-Preise mitbringt — und was nicht

Magento Open Source enthält keines der prominenten Adobe-Commerce-B2B-Features: keine Companies-Hierarchie, keine Negotiable Quotes, keine Shared Catalogs, keine Purchase-Order-Workflows. Was es mitbringt, reicht für die meisten realen B2B-Anforderungen trotzdem:

• Customer Groups — frei definierbar, eine „NOT LOGGED IN”-Gruppe plus beliebig viele angemeldete
• Tier Prices pro Customer Group und Mengenschwelle, direkt am Produkt hinterlegt
• Catalog Price Rules mit Conditions auf Customer Group, Kategorie und Attribute
• Special Prices mit Datumsfenster
• Tax Class pro Customer Group — die Grundlage jeder Netto-/Brutto-Logik
• Price Scope pro Website — eine separate B2B-Storefront kann eigene Preis-Sets fahren
• Extension Points im Pricing-Stack: Magento\Catalog\Pricing\Price\FinalPrice ist plugin-fähig, eigene PriceModel-Implementierungen lassen sich registrieren

Mit diesen Bausteinen sind drei sehr unterschiedliche Architektur-Muster machbar. Wir gehen sie der Reihe nach durch — von der schlankesten zur aufwändigsten Variante.

Muster 1: Customer Groups + Tier Prices, ERP-synchronisiert

Das einfachste Muster — und für viele Shops völlig ausreichend. Bei einem Multi-Country-Versender mit gemischtem B2C/B2B-Geschäft, den wir Anfang 2026 von Magento 1 auf Magento 2.4.8 migriert haben, sieht das so aus:

• Vier Store-Views: B2C DE und EN (Brutto inkl. MwSt) sowie B2B DE und EN (Netto exkl. MwSt), die B2B-Views unter eigener Subdomain
• Eigene Customer Groups für das B2B-Segment, zugewiesen beim Registrierungs-Workflow
• Tier Prices pro Customer Group, am Produkt hinterlegt
• Synchronisation der Tier Prices aus dem ERP über dessen API: ein eigenes Modul liest die kundenspezifischen Konditionen aus dem Warenwirtschaftssystem und schreibt sie als Tier Prices in catalog_product_entity_tier_price

Vorteile:

• Reine Standard-Mittel, keine Preis-Plugins im Stack
• Frontend zeigt Preise aus dem Index — keine Laufzeit-Berechnung pro Request
• Cache-Verhalten ist „normal”: Full Page Cache funktioniert ohne Sonderlogik
• Migrationspfad nach oben — etwa auf ein Hyvä-Frontend — bleibt geradeaus

Grenzen: Tier Prices in der Standard-Tabelle skalieren bei tausenden Produkten und einer überschaubaren Zahl von Customer Groups problemlos. Sobald wirklich jeder einzelne Kunde eigene, individuell ausgehandelte Preise pro Produkt hat — und sich diese Preise täglich aus dem ERP ändern — sprengt das Standard-Modell Performance und Wartbarkeit. Dann wechselt man auf Muster 2.

Muster 2: Externe Pricing-Datenbank mit Custom-Modul

Bei einem internationalen B2B-Shop mit Multi-Country-Setup haben wir genau diesen Schritt gemacht. Die Preise sind kunden- und länderspezifisch und kommen direkt aus dem ERP — das Magento-Standard-Modell wäre dafür weder schnell genug noch wartbar geblieben. Die Architektur:

• Eigene MySQL-Datenbank parallel zur Magento-Datenbank, gefüllt aus dem ERP via separatem Sync-Job
• Zwei Custom-Module:
  • Das erste Modul klinkt sich per Plugin in Magento\Catalog\Pricing\Price\FinalPrice ein und liest den Preis für die Kombination Kunde × Produkt aus der externen DB statt aus der Magento-Tabelle. Damit ist der ganze Standard-Pricing-Stack (Produktdetailseite, Warenkorb, Checkout) transparent versorgt.
  • Das zweite Modul ergänzt denselben Lookup für die ElasticSuite-Suche, damit Preisfilter und Sortierungen in der Layered Navigation denselben Datenstand verwenden wie die Produktdetailseite.
• Preise nur nach Login: für nicht eingeloggte Besucher zeigt der Shop keine Preise

Vorteile:

• Preis-Updates wirken sofort — keine Magento-Indexer-Latenz auf dem Pricing-Pfad
• Eine Zeile pro Kunde × Produkt ist in einer separaten, dafür optimierten DB problemlos handhabbar
• ERP bleibt Single Source of Truth, Magento ist nur Anzeige- und Bestellschicht

Stolperfallen:

• Caching wird komplexer: jede Änderung im externen Preis-Sync muss die betroffenen Produkt- und Kategorie-Seiten im FPC invalidieren. Das läuft bei uns über Cache-Tags auf Modulebene.
• ElasticSuite muss konsistent gehalten werden — der Preisfilter in der Layered Navigation muss denselben Preis anzeigen wie die Produktdetailseite. Daher das zweite Modul.

Muster 3: Vollständig eigene Preislogik mit Gebinde- und Fallback-Regeln

Das aufwändigste Muster, das wir im Einsatz haben. Bei einem B2B-Shop im Chemikalien-/Wasseraufbereitungs-Umfeld sind die Preise nicht nur kundenspezifisch, sondern hängen zusätzlich an Gebindegrößen, einer kundenindividuellen Rabattlogik mit Fallback-Hierarchie und einer Listenpreis-/Nettopreis-Toggle-Logik im Frontend. Technisch:

• Eigene Preistabelle im Magento-DB-Schema, nicht über die Standard-EAV-Pfade
• Eigene Kundennummer als zusätzlicher Schlüssel für die Preisberechnung — die Magento-Customer-ID reicht nicht, weil das ERP eigene Identifikatoren führt
• Rabatt-Berechnung als Kaskade: kundenspezifischer Preis → Kundengruppen-Preis → Listenpreis, jeweils mit Mengen-/Gebinde-Logik. Greift die kundenspezifische Regel nicht, fällt das System eine Stufe weiter zurück
• Gebindelogik: jedes Produkt hat in der Preistabelle definierte Gebinde (etwa 20-Liter-Kanister oder 200-Liter-Fass), die im Frontend automatisch als Mengen-Optionen erscheinen. Der Kunde kann zwischen den definierten Gebinden wählen, nicht aber freie Mengen
• Vertriebsmitarbeiter-Rolle: Sales-User können sich für ihren Kunden einloggen und Bestellungen aufgeben — sie haben die Gebinde-Beschränkung nicht und können freie Mengen eingeben
• Frontend-Toggle Listenpreis ↔ tatsächlicher Preis: die Wahl wird am Kunden-Account gespeichert und steht beim nächsten Login wieder
• Manueller Freigabe-Workflow: neue Registrierungen landen unter Customers → Temporary Registrations und müssen vom Backoffice freigeschaltet werden, bevor der Kunde Preise sieht oder bestellen kann
• Backend-Übersicht: unter Sales → Price Overview ist die aktive Preismatrix pro Kunde einsehbar — entscheidend, wenn das Backoffice eine Support-Anfrage beantworten muss
• Import & Export: ein eigenes Modul holt Kunden, Produkte und Preise per HTTP-GET aus der ERP-Pipeline; ein zweites schreibt fertige Bestellungen als CSV-Datei zurück, die das Warenwirtschaftssystem dann weiterverarbeitet

Vorteile:

• Vollständige Flexibilität — alles, was sich fachlich begründen lässt, lässt sich auch abbilden
• Eine zentrale Backend-Übersicht macht Support-Anfragen („warum sieht Kunde X den Preis Y?”) in Sekunden klärbar
• ERP-Integration bleibt unidirektional und einfach: ein Import-Endpoint, ein Export-Job

Stolperfallen:

• Hoher Wartungsaufwand pro Magento-Update — eigene Plugins im Preis-Stack müssen mit jeder neuen Magento-Version validiert werden
• Onboarding neuer Entwickler dauert länger; die Preislogik ist nirgendwo in einer Magento-Doku beschrieben
• Bei Migrationen (etwa auf ein Hyvä-Frontend) muss die Logik für Gebinde-Auswahl und Listenpreis-Toggle mitgezogen werden

Welches Muster wann

Eine Faustregel-Tabelle:

Anforderung	Muster
Mengenbasierte Staffeln pro Customer Group, dieselben für alle Kunden einer Gruppe	Muster 1 (Tier Prices + Customer Groups)
Echte 1:1-Preise pro Kunde × Produkt, häufige ERP-Synchronisation	Muster 2 (externe Pricing-DB + Plugin)
Kundenspezifische Preise plus Gebinde-/Verpackungslogik, Vertriebsmitarbeiter-Stellvertretung, Listenpreis-Toggle	Muster 3 (vollständig eigene Logik)
Preise erst nach Login, manueller Freigabe-Workflow	unabhängig vom Muster — als Plus-Layer kombinierbar
Companies-Hierarchie, Negotiable Quotes, Shared Catalogs	kein Open-Source-Muster — Adobe Commerce B2B oder Avanta

Bei diesen Anforderungen lohnt sich der Wechsel weg von Magento Open Source. Adobe Commerce bringt das B2B-Modul mit, ist aber gleichzeitig auf viele weitere Themen ausgelegt — Page Builder, Content Staging, B2C-Komfortfunktionen. Eine deutlich B2B-spezifischere Alternative ist Avanta von Ecoplan, eine auf Magento aufsetzende B2B-Suite mit ausschließlichem B2B-Fokus. CopeX ist Avanta-Partner und kann beide Wege umsetzen.

Wichtig: jedes Muster ist eine Designentscheidung mit Folgen. Muster 1 lässt sich später nicht trivial in Muster 2 umbauen, ohne die Preis-Sync-Pipeline neu zu schreiben. Muster 3 erbt einen langfristigen Maintenance-Aufwand, der bei jedem Magento-Major-Release sichtbar wird. Die Wahl hängt deshalb weniger an „was kann Magento” und mehr an zwei anderen Fragen: was leistet das ERP, und wie individuell sind die Preise tatsächlich.

Was du als nächstes tun kannst

Wenn du gerade vor der Entscheidung stehst, wie du B2B-Preise in deinem Magento-Shop aufstellst, gibt es zwei pragmatische erste Schritte:

1. Ehrliche Preis-Bestandsaufnahme: Wie viele Customer Groups habt ihr realistisch? Wie viele Zeilen würden im Worst Case in catalog_product_entity_tier_price landen (Produkte × Kundengruppen × Mengen-Stufen)? Solange das im überschaubaren Bereich bleibt, ist Muster 1 ein guter Startpunkt — und der einzige, der ohne Custom-Code auskommt.
2. Architektur-Beratung anfragen: Wir prüfen euer ERP-Schema, das aktuelle Magento-Setup und die fachlichen Preis-Regeln in einem zwei- bis vierstündigen Termin. Ergebnis: konkrete Empfehlung für eines der drei Muster, inklusive Aufwandsabschätzung. Kontakt: office@copex.io oder Termin anfragen.

Verwandte Themen aus unserem Blog: Magento-Shop-Migration von AWS zurück nach Österreich, Composable Commerce in Magento 2, häufige Magento-Sicherheitslücken vermeiden. Und unsere Service-Seiten zu Magento-Entwicklung und laufender Magento-Betreuung.