Medusa Pro­cure­ment: Not a Turnkey Fea­ture — and That's Ex­act­ly Where the Work Be­gins

Medusa is an out­stand­ing com­merce core, and it still ships no turnkey pro­cure­ment. Hold both halves of that sen­tence in one breath and you have un­der­stood the ar­chi­tec­ture — and spared your­self an ex­pen­sive dis­ap­point­ment mid-project.

The con­fu­sion has a name: the Medusa b2b-starter. It looks like a B2B prod­uct, it lists com­pa­ny man­age­ment, spend­ing lim­its, quotes and ap­proval work­flows, and that is ex­act­ly why ten­der doc­u­ments end up say­ing "Medusa does B2B pro­cure­ment." It does — in the sense of "you can build it on top." Not in the sense of "it is built in and main­tained for you." That dis­tinc­tion is not pedantry. It de­cides the ef­fort, the main­te­nance load, and whether your busi­ness case holds.

Let's be pre­cise, be­cause sales con­ver­sa­tions hap­pi­ly treat "B2B" and "pro­cure­ment" as syn­onyms. B2B means cor­po­rate cus­tomers, vol­ume pric­ing, cus­tomer groups, quotes. Pro­cure­ment means the for­malised buy­ing process on the pur­chaser's side — req­ui­si­tion, ap­proval chain, an or­der booked against a cost cen­tre and a bud­get, rec­on­cil­i­a­tion with the ERP. One is a sales mod­el, the oth­er a reg­u­lat­ed process. Medusa cov­ers the first well; the sec­ond, not at all out of the box.

The ac­tive Medusa b2b-starter — now at github.com/medusajs/b2b-starter, with the old b2b-starter-medusa repo archived — gives you a sol­id base­line. Com­pa­ny and em­ploy­ee man­age­ment (cre­ate com­pa­nies, in­vite staff, as­sign roles), per-em­ploy­ee spend­ing lim­its with con­fig­urable re­set fre­quen­cies, ap­proval work­flows at com­pa­ny and mer­chant lev­el be­fore the or­der, quote man­age­ment with ne­go­ti­a­tion mes­sag­ing, af­ter-the-fact or­der ed­its, bulk add-to-cart and pro­mo­tions. On top of that, the full com­merce base: prod­ucts, col­lec­tions, cart, check­out, or­der his­to­ry. That is more than many ex­pect, and it is a good start­ing point.

The de­ci­sive point is stat­ed in the repo it­self: the starter is "de­signed to be cus­tomized and ex­tend­ed," MIT-li­censed, al­most en­tire­ly Type­Script. Trans­lat­ed: fork­able ref­er­ence code that you main­tain your­self. Not a fea­ture flag in a SaaS con­sole, not a mod­ule Medusa keeps cur­rent for you. When a se­cu­ri­ty fix lands to­mor­row, or you want to move to a new Medusa ver­sion, that is your merge, your re­gres­sion, your test. I've writ­ten else­where about who Medusa suits as a plat­form in the first place, in my piece on head­less com­merce with Medusa and who it's for.

You might as­sume the B2B build­ing blocks come from the Medusa core. They don't. The core con­tains nei­ther a com­pa­ny nor a quote nor an ap­proval mod­ule. The of­fi­cial Com­merce Mod­ules doc­u­men­ta­tion lists as core mod­ules Cart, Cus­tomer, Or­der, Pay­ment, Pric­ing, Prod­uct, Pro­mo­tion, Re­gion, Tax and more — but noth­ing that re­sem­bles a com­pa­ny hi­er­ar­chy or an ap­proval chain (docs.medusajs.com/re­sources/com­merce-mod­ules).

The B2B foun­da­tion in the core is de­lib­er­ate­ly lean­er. The Cus­tomer mod­ule sup­ports B2B ac­counts and cus­tomer groups with spe­cial pric­ing; Pric­ing/price lists and Pro­mo­tions are core as well. Every­thing be­yond that — com­pa­ny, quote, ap­proval — the b2b-starter im­ple­ments as its own cus­tom mod­ules in the starter code. Medusa doc­u­ments even quote man­age­ment only as a how-to guide ("Im­ple­ment Quote Man­age­ment in Medusa"), a ref­er­ence im­ple­men­ta­tion, not a core fea­ture.

This is not care­less­ness; it fol­lows from Medusa's ar­chi­tec­ture. A mod­ule is an iso­lat­ed, reusable pack­age for one do­main; mod­ule links con­nect data mod­els across mod­ule bound­aries with­out break­ing that iso­la­tion; work­flows or­ches­trate mul­ti-step process­es with built-in roll­back. That toolk­it ex­ists pre­cise­ly so you can dock do­mains like pro­cure­ment on clean­ly — not to pre­scribe them for you. If you want to place Medusa as a whole, the overview lives on our Medusa pil­lar page.

Now the un­com­fort­able part. The b2b-starter con­tains no turnkey en­ter­prise-pro­cure­ment func­tions. No pun­chout, no cXML, no OCI, no req­ui­si­tion-to-PO, no cost cen­tres, no real ERP bud­gets, no net terms with pur­chase-on-ac­count in­voic­ing, no ERP or­der rec­on­cil­i­a­tion. These terms are demon­stra­bly ab­sent from the fea­ture list. What the starter de­liv­ers is sim­ple com­pa­ny ap­provals and per-em­ploy­ee spend­ing lim­its — not mul­ti-step ap­proval chains with cost-cen­tre and bud­get log­ic, and not the hook into an ex­ter­nal ePro­cure­ment sys­tem.

Why does that mat­ter? Be­cause real en­ter­prise pro­cure­ment does­n't pri­mar­i­ly hap­pen in your shop at all. The buy­er sits in their ePro­cure­ment or ERP sys­tem — Ari­ba, Coupa, Jag­gaer, SAP — and "punch­es out" from there live into your sup­pli­er shop, sees their con­tract-spe­cif­ic prices and stock, fills a cart and sends it back. The req­ui­si­tion, the ap­proval and the ac­tu­al pur­chase or­der all run in the buy­er's sys­tem, not on your side (trade­cen­tric.com). For that, your shop has to speak two pro­to­cols serv­er-side: cXML (cre­at­ed by Ari­ba in 1999, now with SAP, dom­i­nant in North Amer­i­ca) and OCI (Open Cat­a­log In­ter­face, orig­i­nal­ly SAP, the de fac­to stan­dard for ERP-dri­ven pro­cure­ment in the DACH re­gion).

That is the heart of the pun­chout-OCI top­ic: an en­ter­prise-grade cat­a­logue im­ple­ments both pro­to­cols, and Medusa brings nei­ther. Then there is the pay­ment side. Medusa ships only a man­u­al "sys­tem" pay­ment provider — a place­hold­er for bank trans­fer or in­voice with no set­tle­ment log­ic. Medusa names net terms with ERP in­voic­ing ex­plic­it­ly as an ex­am­ple of a cus­tom pay­ment provider you build your­self via Ab­stract­Pay­ment­Provider. None of this is hid­den or un­doc­u­ment­ed. Medusa po­si­tions these en­ter­prise ca­pa­bil­i­ties open­ly as a build-it-your­self toolk­it. You just have to read the docs be­fore you plan the roadmap.

Let's count hon­est­ly, be­cause "open source" does not mean "free." What's free is the MIT soft­ware, not the op­er­a­tion and not the de­vel­op­ment. A pro­duc­tion stack re­quires Post­greSQL and Re­dis, runs in two modes — serv­er for API/ad­min, work­er for back­ground jobs — and wants at least 2 GB of RAM and Node 20+. Self-host­ed on Het­zn­er, GDPR-com­pli­ant in Ger­many, that is fea­si­ble at en­try lev­el for €20–50/month, and high­ly avail­able with a sep­a­rate data­base more like €150–400/month. These run­ning costs tend to fall over time — un­like SaaS, where trans­ac­tion fees grow with your rev­enue. (Fig­ures as of mid-2026, ver­i­fy against cur­rent pric­ing.)

The heavy item is­n't the host­ing; it's the pro­cure­ment lay­er it­self. A clean first im­ple­men­ta­tion of a self-host­ed Medusa stack runs a one-off €5,000–20,000; the pun­chout/OCI/ERP lay­er sits on top and is the real en­gi­neer­ing work. Over three years, a mid-mar­ket Medusa ap­pli­ca­tion lands rough­ly at a €40,000–80,000 to­tal cost of own­er­ship — with­out the in­dus­try-spe­cif­ic pro­cure­ment log­ic, which weighs in heav­i­ly de­pend­ing on your ERP land­scape. These num­bers are ex­pe­ri­ence-based es­ti­mates, not a price list; the ex­act fig­ure hangs on your in­te­gra­tion depth. If you want to run the full sum against SaaS, the method is in our com­par­i­son Medusa vs Shopi­fy Plus.

So the ques­tion is­n't "ex­pen­sive or cheap," it's make-or-buy. With the build you buy con­trol over the data mod­el, the ap­proval log­ic and the ERP in­te­gra­tion — and the op­er­a­tional re­spon­si­bil­i­ty along with it. For a shop whose down­time costs rev­enue di­rect­ly, that is a real ven­dor-risk and re­silience trade-off, not a gut feel­ing.

Now the the­sis that com­pli­cates my own ar­gu­ment. The b2b-starter cre­ates the im­pres­sion of "B2B ready," and who­ev­er writes it into the project plan as a fin­ished prod­uct sys­tem­at­i­cal­ly un­der­es­ti­mates the ef­fort and the main­te­nance. That is one trap. The oth­er is its mir­ror im­age: not every com­pa­ny needs a be­spoke pro­cure­ment lay­er at all.

If your pro­cure­ment process­es fol­low the mar­ket norm — stan­dard­ised and reg­u­lat­ed, clas­sic ap­proval stages, com­mon pun­chout hooks, net-30 pur­chase-on-ac­count, no spe­cial cas­es — then SAP Ari­ba, com­merce­tools B2B or Shopi­fy B2B sim­ply give you more out of the box. Shopi­fy has re­cent­ly opened its B2B of­fer­ing be­yond the Plus tier: com­pa­ny pro­files, net terms, vol­ume pric­ing and mul­ti­ple cat­a­logues are no longer re­served ex­clu­sive­ly for Plus (as of mid-2026, ver­i­fy). If you only need the stan­dard, with Medusa you pay for a build you did­n't need — and then car­ry its main­te­nance.

That is not an ar­gu­ment against Medusa. It's an ar­gu­ment for an hon­est re­quire­ments analy­sis be­fore the tool choice. The break runs along a sin­gle line: does your pro­cure­ment log­ic de­vi­ate from the stan­dard? Do you have sev­er­al cat­a­logue seg­ments, cus­tomer-spe­cif­ic ap­proval chains, an ERP land­scape that no stan­dard suite maps clean­ly, or reg­u­la­to­ry de­mands on data own­er­ship? Then the re­place­able core turns from a cost line into an ad­van­tage. It's at ex­act­ly that bound­ary that the larg­er ques­tion is set­tled too — whether Medusa can re­place your SAP Com­merce.

Treat the miss­ing pro­cure­ment turnkey-ness not as a bug but as a de­sign de­ci­sion — and check whether that de­ci­sion match­es yours. The Medusa core is ex­cel­lent as a D2C/B2C com­merce foun­da­tion, and the b2b-starter gives you an hon­est head start on com­pa­ny man­age­ment, spend­ing lim­its, quotes and sim­ple ap­proval work­flows. But write "pun­chout," "OCI," "cost cen­tres" or "net terms" into a re­quire­ment, and you are plan­ning a build — with bud­get, time­line and a team that com­mands Post­greSQL, Re­dis, Node and the Medusa mod­ule world.

The de­ci­sion is ul­ti­mate­ly not tech­ni­cal but strate­gic: do you want to sub­or­di­nate your pro­cure­ment log­ic to a ven­dor's stan­dard and go live fast in re­turn — or is that log­ic ex­act­ly your dif­fer­en­tia­tor, the one that tol­er­ates no ven­dor lock-in? For the first case, the suites ex­ist. For the sec­ond, Medusa is the right core, be­cause you build the pro­cure­ment lay­er that fits your op­er­at­ing mod­el in­stead of bend­ing your mod­el to a suite.

That lay­er — pun­chout/OCI in­te­gra­tion, cost-cen­tre and bud­get log­ic, ERP rec­on­cil­i­a­tion, net-terms in­voic­ing on a clean Medusa core — is what we build at hap­py­cod­ing. Not be­cause Medusa is "miss­ing" some­thing, but be­cause it is the core you dock ex­act­ly that onto. Un­der­stand this and you aren't buy­ing a half-fin­ished prod­uct; you're buy­ing a foun­da­tion with a clear edge to build against.