Medusa ist ein hervorragender Commerce-Kern und liefert trotzdem kein schlüsselfertiges Procurement. Wer beides in einen Satz packen kann, hat die Architektur verstanden – und spart sich eine teure Enttäuschung im Projekt.
Der Grund für die Verwirrung hat einen Namen: den Medusa b2b-starter. Er sieht aus wie ein B2B-Produkt, listet Company-Management, Spending Limits, Quotes und Approval-Workflows, und genau deshalb landen in Ausschreibungen Sätze wie „Medusa kann B2B-Beschaffung". Kann es – im Sinne von „lässt sich darauf bauen". Nicht im Sinne von „ist eingebaut und wird für Sie gewartet". Diese Unterscheidung ist keine Wortklauberei. Sie entscheidet über Aufwand, Wartungslast und darüber, ob Ihr Business Case trägt.
Was heißt Medusa Procurement überhaupt – und was liefert der b2b-starter?
Reden wir präzise, denn „B2B" und „Procurement" werden im Vertrieb gern synonym benutzt. B2B heißt: Firmenkunden, Mengenpreise, Kundengruppen, Angebote. Procurement heißt: die formalisierte Beschaffung auf der Käuferseite – Requisition, Freigabekette, Bestellung gegen Kostenstelle und Budget, Abgleich mit dem ERP. Das eine ist ein Verkaufsmodell, das andere ein regulierter Prozess. Medusa deckt das erste Feld gut ab und das zweite gar nicht out-of-the-box.
Der aktive Medusa b2b-starter – inzwischen unter dem Pfad github.com/medusajs/b2b-starter, das alte Repo b2b-starter-medusa ist archiviert – liefert eine solide Grundausstattung. Company- und Employee-Management (Firmen anlegen, Mitarbeiter einladen, Rollen zuweisen), per-Mitarbeiter Spending Limits mit konfigurierbaren Reset-Frequenzen, Approval-Workflows auf Company- und Merchant-Ebene vor der Bestellung, Quote-Management mit Verhandlungs-Messaging, nachträgliche Order-Edits, Bulk-Add-to-Cart und Promotions. Dazu die volle Commerce-Basis: Produkte, Collections, Cart, Checkout, Order-History. Das ist mehr, als viele erwarten – und es ist ein guter Startpunkt.
Der entscheidende Punkt steht im Repo selbst: Der Starter ist „designed to be customized and extended", MIT-lizenziert, nahezu vollständig in TypeScript. Übersetzt: forkbarer Referenzcode, den Sie selbst pflegen. Kein Feature-Flag in einer SaaS-Konsole, kein Modul, das Medusa für Sie aktuell hält. Wenn morgen ein Security-Fix ansteht oder Sie auf eine neue Medusa-Version wollen, ist das Ihr Merge, Ihre Regression, Ihr Test. Für wen Medusa als Plattform grundsätzlich passt, habe ich an anderer Stelle sortiert – siehe Headless Commerce mit Medusa.js: für wen?.
Warum die Beschaffungslogik nicht im Core steckt
Man könnte meinen, die B2B-Bausteine kämen aus dem Medusa-Core. Tun sie nicht. Der Core enthält weder ein Company- noch ein Quote- noch ein Approval-Modul. Die offizielle Commerce-Modules-Dokumentation listet als Core-Module unter anderem Cart, Customer, Order, Payment, Pricing, Product, Promotion, Region, Tax – aber nichts, was nach Firmenhierarchie oder Freigabekette aussieht (docs.medusajs.com/resources/commerce-modules).
Das B2B-Fundament aus dem Core ist bewusst schlanker: Das Customer-Modul unterstützt B2B-Accounts und Customer-Groups mit Spezialpreisen, Pricing/Price-Lists und Promotions sind ebenfalls Core. Alles, was darüber hinausgeht – Company, Quote, Approval – implementiert der b2b-starter als eigene Custom-Module im Starter-Code. Auch Quote-Management dokumentiert Medusa selbst nur als How-to-Guide („Implement Quote Management in Medusa"), also als Referenzimplementierung, nicht als Core-Feature.
Das ist keine Nachlässigkeit, sondern die Konsequenz aus Medusas Architektur. Ein Modul ist ein isoliertes, wiederverwendbares Paket für eine Domäne; Module Links verbinden Datenmodelle über Modulgrenzen, ohne die Isolation zu brechen; Workflows orchestrieren mehrstufige Prozesse mit eingebautem Rollback. Genau dieser Baukasten ist gemacht, um Domänen wie Procurement sauber anzudocken – nicht, um sie vorzugeben. Wer Medusa als Ganzes einordnen will, findet die Übersicht auf unserer Medusa-Pillarseite.
Punchout, OCI, Kostenstellen: die reale Procurement-Lücke
Jetzt zum unbequemen Teil der Faktenlage. Der b2b-starter enthält keine schlüsselfertigen Enterprise-Procurement-Funktionen. Kein Punchout, kein cXML, kein OCI, keine Requisition-to-PO, keine Kostenstellen, keine echten ERP-Budgets, keine Net-Terms mit Rechnungskauf-Invoicing, keinen ERP-Bestellabgleich. Diese Begriffe fehlen nachweislich in der Feature-Liste. Was der Starter liefert, sind einfache Company-Approvals und per-Mitarbeiter-Spending-Limits – nicht mehrstufige Freigabeketten mit Kostenstellen- und Budget-Logik und nicht die Anbindung an ein externes eProcurement-System.
Warum zählt das? Weil echtes Enterprise-Procurement gar nicht primär in Ihrem Shop stattfindet. Der Einkäufer sitzt in seinem eProcurement- oder ERP-System – Ariba, Coupa, Jaggaer, SAP – und „puncht" von dort live in Ihren Lieferanten-Shop, sieht seine kundenspezifischen Preise und Bestände, füllt einen Warenkorb und schickt ihn zurück. Requisition, Freigabe und die eigentliche Purchase Order laufen im Käufersystem, nicht bei Ihnen (tradecentric.com). Ihr Shop muss dafür serverseitig zwei Protokolle sprechen: cXML (1999 von Ariba geschaffen, heute bei SAP, dominant in Nordamerika) und OCI (Open Catalog Interface, ursprünglich SAP, der De-facto-Standard für ERP-getriebene Beschaffung im DACH-Raum).
Das ist der Kern des Punchout-OCI-Themas: Ein enterprise-fähiger Katalog implementiert beide Protokolle, und keines davon bringt Medusa mit. Dazu kommt der Zahlungsteil. Medusa liefert nur einen manuellen „system"-Payment-Provider – einen Platzhalter für Überweisung oder Rechnung ohne Abwicklungslogik. Net-Terms mit ERP-Invoicing nennt Medusa ausdrücklich als Beispiel für einen Custom Payment Provider, den Sie über AbstractPaymentProvider selbst bauen. Nichts davon ist versteckt oder undokumentiert. Medusa positioniert diese Enterprise-Fähigkeiten offen als Baukasten zum Selbstbauen. Man muss die Doku nur lesen, bevor man die Roadmap plant.
Was der Eigenbau kostet – und wann er sich rechnet
Rechnen wir ehrlich, denn „Open Source" heißt nicht „kostenlos". Kostenlos ist die MIT-Software, nicht der Betrieb und nicht die Entwicklung. Ein Produktiv-Stack braucht zwingend PostgreSQL und Redis, läuft in zwei Modi – Server für API/Admin, Worker für Background-Jobs – und will mindestens 2 GB RAM und Node 20+. Self-hosted auf Hetzner, DSGVO-konform in Deutschland, ist das im Einstieg mit 20–50 €/Monat machbar, hochverfügbar mit separater DB eher 150–400 €/Monat. Diese laufenden Kosten sinken tendenziell über die Zeit – anders als bei SaaS, wo Transaktionsgebühren mit dem Umsatz mitwachsen.
Der Brocken ist nicht das Hosting, sondern der Procurement-Layer selbst. Eine saubere Erstimplementierung eines self-hosted Medusa-Stacks liegt einmalig bei 5.000–20.000 €; der Punchout-/OCI-/ERP-Layer kommt obendrauf und ist die eigentliche Ingenieursarbeit. Über drei Jahre landet eine mittelständische Medusa-Anwendung grob bei 40.000–80.000 € Gesamtbild – ohne die branchenspezifische Beschaffungslogik, die je nach ERP-Landschaft deutlich zu Buche schlägt. Diese Zahlen sind Erfahrungswerte, keine Preisliste; die genaue Höhe hängt an Ihrer Integrationstiefe. Wer die Gesamtrechnung gegen SaaS führen will, findet die Systematik in unserem Vergleich Medusa vs. Shopify Plus.
Die Frage ist also nicht „teuer oder billig", sondern Make-or-Buy. Sie kaufen mit dem Eigenbau Kontrolle über Datenmodell, Freigabelogik und ERP-Anbindung – und die Betriebsverantwortung gleich mit. Bei einem Shop, dessen Ausfall direkt Umsatz kostet, ist das eine reale Vendor-Risk- und Resilienz-Abwägung, kein Bauchgefühl.
Der unbequeme Punkt: nicht jeder braucht diesen Layer
Jetzt die These, die mein eigenes Argument kompliziert. Der b2b-starter erweckt den Eindruck „B2B ready", und wer ihn als fertiges Produkt in den Projektplan schreibt, unterschätzt Aufwand und Wartung systematisch. Das ist die eine Falle. Die andere ist die spiegelbildliche: nicht jedes Unternehmen braucht überhaupt einen eigenen Procurement-Layer.
Wenn Ihre Beschaffungsprozesse standardisiert und reguliert dem Marktstandard folgen – klassische Freigabestufen, gängige Punchout-Anbindung, Net-30-Rechnungskauf, keine Sonderlocken – dann bekommen Sie mit SAP Ariba, commercetools B2B oder Shopify B2B schlicht mehr out-of-the-box. Shopify hat sein B2B-Angebot zuletzt über die Plus-Stufe hinaus geöffnet: Company Profiles, Net Terms, Volume Pricing und mehrere Kataloge sind nicht mehr ausschließlich der Plus-Stufe vorbehalten. Wer nur Standard braucht, zahlt bei Medusa einen Eigenbau, den er nicht bräuchte – und trägt danach dessen Wartung.
Das ist kein Argument gegen Medusa. Es ist ein Argument für eine ehrliche Anforderungsanalyse vor der Toolwahl. Der Bruch verläuft entlang einer einzigen Linie: Weicht Ihre Procurement-Logik vom Standard ab? Haben Sie mehrere Katalogsegmente, kundenindividuelle Freigabeketten, eine ERP-Landschaft, die keine Standard-Suite sauber abbildet, oder regulatorische Anforderungen an Daten-Ownership? Dann wird der austauschbare Kern vom Kostenpunkt zum Vorteil. Genau an dieser Grenze entscheidet sich auch die größere Frage, ob Medusa Ihr SAP Commerce ablösen kann.
Was ich Entscheidern rate
Behandeln Sie die fehlende Procurement-Schlüsselfertigkeit nicht als Bug, sondern als Designentscheidung – und prüfen Sie, ob diese Entscheidung zu Ihrer passt. Der Medusa-Core ist als D2C/B2C-Commerce-Fundament exzellent, und der b2b-starter gibt Ihnen einen ehrlichen Vorsprung bei Company-Management, Spending Limits, Quotes und einfachen Approval-Workflows. Aber schreiben Sie „Punchout", „OCI", „Kostenstellen" oder „Net-Terms" in eine Anforderung, dann planen Sie Eigenbau ein – mit Budget, Timeline und einem Team, das PostgreSQL, Redis, Node und die Medusa-Modulwelt beherrscht.
Die Entscheidung ist am Ende keine technische, sondern eine strategische: Wollen Sie Ihre Beschaffungslogik dem Standard eines Anbieters unterordnen und dafür schnell live gehen – oder ist genau diese Logik Ihr Differenzierungsmerkmal, das keinen Vendor-Lock-in verträgt? Für den ersten Fall gibt es die Suiten. Für den zweiten ist Medusa der richtige Kern, weil Sie den Procurement-Layer bauen, der zu Ihrem Operating Model passt, statt Ihr Modell einer Suite anzupassen.
Diesen Layer – Punchout/OCI-Anbindung, Kostenstellen- und Budget-Logik, ERP-Abgleich, Net-Terms-Invoicing auf einem sauberen Medusa-Kern – bauen wir bei happycoding. Nicht, weil Medusa etwas „fehlt", sondern weil es der Kern ist, an den man genau das andockt. Wer das versteht, kauft kein halbfertiges Produkt, sondern ein Fundament mit klarer Baukante.
