Let us clear up the premise first, because it changes how you plan. There is no Medusa B2B module. Medusa’s commerce modules are Cart, Product, Order, Pricing, Inventory and the rest, and there is nothing in that list called B2B.
What exists instead is the Medusa B2B Starter: an official, open-source project template built on Next.js and Medusa, which assembles the standard modules plus some purpose-built ones into a working B2B storefront and admin.
That distinction matters more than it sounds. A module is a component you add to a system. A starter is a codebase you take ownership of on day one. It gives you a large head start, and it does not give you a product that someone else maintains for you. Everything in it becomes yours to run. With that established, here is what is in the box and what is not.
What the Medusa B2B starter ships
From Medusa’s own published feature list, the starter arrives with the following.
Buyer organisation structure. Company accounts, employee accounts, and the links between them. Employees belong to a company, and the company is the buying entity.
Spending controls. Per-employee spending limits, with a configurable reset frequency.
Cart approval flows. A company administrator can be required to approve an employee’s cart before it becomes an order. Merchants can also set their own approval step before fulfilment.
Quotes. A request-for-quote flow where a buyer requests pricing and the merchant can comment on, alter, accept or reject the quote.
Account-level pricing. Price lists attached to B2B accounts, plus custom line item pricing and automated promotions. Price lists can be uploaded by CSV and managed in a bulk editor.
Ordering conveniences that matter at wholesale volume. Bulk add-to-cart, bulk product uploads and draft orders.
Channel and market separation. Multiple sales channels and regions with different product and pricing rules, so DTC, B2B and offline orders can run from one system under different rules.
This is a genuinely substantial starting point. Most hosted platforms treat B2B as a tier you upgrade into; with Medusa B2B it is a codebase you start from, and the starter is public on GitHub.
It is also proven at scale. Medusa publishes B2B references including Redington, Makro, Material Bank and Campagnolo, citing figures such as one platform doing over $4bn GMV a year, and another handling more than 10,000 daily orders while integrating with 43 regional distributor ERPs. Those are Medusa’s published numbers rather than independently verified ones, but the scale claim is not speculative.
Company accounts and approvals
Worth looking at this in detail, because it is the part that most often decides whether a Medusa B2B build succeeds.
The model is straightforward. A company is the account, employees are users attached to it, and rules attach at both levels. Spending limits sit on the employee. Approval requirements sit on the company. A purchase that exceeds a limit or triggers a rule stops and waits for an administrator.
What this handles well is the common shape: a buying organisation where several people order, one or two people approve, and the business wants a ceiling on what any individual can commit.
Where it needs extension is organisational complexity. Multi-level approval chains, where a $5,000 order needs a department head and a $50,000 order needs finance as well, are described by Medusa as something you build as custom workflows rather than configure. The same applies to approval rules that vary by cost centre, by product category, or by delivery site.
That is not a gap so much as a boundary, and a sensible one. Approval hierarchies are among the most business-specific things in B2B, and a platform that tried to model every variation would be unusable. But it means that if your approval rules are genuinely complex, that is engineering work rather than configuration, and it belongs in the estimate from the start. We have written separately about custom quote approvals in B2B.
Price lists, and the limits of them
Price lists cover a great deal of real B2B pricing: this customer group pays this price, this account gets this discount, upload the whole thing by CSV and edit in bulk.
What price lists do not cover is pricing that is calculated rather than listed. Three examples come up constantly in wholesale and distribution.
Volume breaks tied to commitments. Not one to ninety-nine units at this price, which is a price list, but this price because you committed to 10,000 units this year, and we reconcile at year end.
Cost-plus pricing. Where the price is derived from a moving input cost, such as metals, currency or freight, rather than set as a number.
Contract pricing owned elsewhere. The price is whatever the ERP says it is, negotiated per account, and the commerce platform’s job is to ask rather than to store.
For the third case, Medusa publishes an ERP recipe covering exactly this shape: a workflow that syncs products from the ERP, and one that reads a variant’s price from the ERP so the cart can add custom-priced line items. That is the right answer architecturally, and it is integration work rather than a setting. Our note on Medusa ERP integration goes through what that involves.
What you still build with Medusa B2B
This is the section most evaluations skip and most budgets discover later. None of these are shortcomings. They are simply outside what the starter ships.
Credit limits and payment terms. Net 30, net 60, credit ceilings, orders held when an account is over its limit. The starter supports custom payment methods; it does not ship a credit engine. For distributors and wholesalers this is usually the single largest missing piece, because selling on account is the default in B2B rather than the exception.
Punchout. If you sell to enterprises whose buyers order through Coupa, Ariba or SAP, they will expect a punchout catalogue over cXML or OCI: the buyer starts in their own procurement system, browses your catalogue inside it, and returns with a filled basket. There is no built-in punchout support, so this is a custom build. It is also the kind of requirement that appears late in a procurement conversation and is non-negotiable when it does.
Customer-specific catalogues and entitlements. Restricting which products a company can even see, not just what they pay. Common in distribution, where contracts define an assortment.
ERP and PIM integration. Designed for, documented as a recipe, and still yours to build and maintain for your specific systems.
Tax handling specific to B2B. Reverse charge, VAT number validation, exemption certificates.
E-invoicing compliance. Increasingly not optional in this region: MyInvois in Malaysia, InvoiceNow in Singapore, e-invoicing mandates in the UAE. Each is its own integration, and each has a deadline attached that does not move because a build is late.
The storefront itself, beyond the starter’s shape. The starter frontend is a starting point. Most real B2B storefronts diverge significantly: reorder from history, saved lists, contract catalogues, quick order by SKU.
| Ships with the Medusa B2B starter | You build it |
|---|---|
| Company and employee accounts | Credit limits and payment terms |
| Per-employee spending limits | Multi-level approval chains |
| Single-step cart approval | Punchout over cXML or OCI |
| Account price lists and CSV upload | Calculated and cost-plus pricing |
| Request for quote and draft orders | ERP and PIM integration |
| Multiple sales channels and regions | Customer-specific catalogues and entitlements |
| Bulk add-to-cart and bulk uploads | B2B tax handling and e-invoicing compliance |
A Medusa B2B fit assessment
Rather than a verdict, here is the shape of the decision.
Where the Medusa B2B starter fits comfortably. A business whose B2B requirements are organisational rather than financial: companies, employees, spending limits, approvals, negotiated price lists, quotes. That is precisely what the starter models, and starting from it saves months over building the same thing on a platform that assumes one buyer per account.
Where it fits with planned engineering. A business whose pricing or catalogue lives in an ERP, or which sells on credit terms, or which needs punchout. All of this is buildable, and the modular architecture is designed for it. The point is that it is a build, so it belongs in the plan and the budget rather than arriving as a surprise in month four.
Where the fit is worth questioning. Where B2B requirements are light, such as a handful of trade accounts with a standard discount, the starter brings machinery that will not be used, and a simpler setup will cost less to run. And where there is no ongoing engineering capacity, the customisability that makes Medusa B2B suitable for complex wholesale is capability nobody is available to use.
The most useful diagnostic we know is a single question: when your customer places an order, what has to be true before you will ship it?
If the answer is they paid, a standard checkout covers it. If the answer involves a credit check, an approval chain, a contract price, a purchase order number, or a system that is not the commerce platform, that answer is your build scope. It is also, usually, the reason a hosted platform was not going to work in the first place.
Frequently asked questions
Is there a Medusa B2B module?
No. Medusa’s commerce modules are Cart, Product, Order, Pricing, Inventory and the rest. What exists is the Medusa B2B Starter, an official open-source project template that assembles standard and purpose-built modules into a working B2B storefront and admin.
What does the Medusa B2B starter include out of the box?
Company and employee accounts, per-employee spending limits, cart approval flows, request for quote, account-level price lists with CSV upload, bulk add-to-cart and bulk uploads, draft orders, and multiple sales channels and regions.
Does Medusa B2B handle credit limits and payment terms?
Not out of the box. The starter supports custom payment methods but does not ship a credit engine, so net terms, credit ceilings and holding orders over a limit are a build. For distributors this is usually the largest missing piece.
Can Medusa B2B do punchout for Coupa, Ariba or SAP?
There is no built-in punchout support, so a cXML or OCI catalogue is a custom build. Plan for it early, because enterprise buyers tend to raise it late in procurement and treat it as non-negotiable.
Can price lists handle contract or cost-plus pricing?
Price lists handle listed pricing well. Pricing that is calculated, such as volume breaks tied to annual commitments or a price derived from a moving input cost, needs custom work, or the price should stay in the ERP and be retrieved at cart time.
We build B2B commerce on Medusa, including the parts above that the starter does not ship. If you are evaluating Medusa B2B for a wholesale or distribution build, we are glad to go through your requirements and give you a straight read on what comes out of the box and what has to be built. See our B2B ecommerce development services and Medusa.js development services, or request a B2B commerce review.