Adobe Commerce B2B is the add-on feature set that turns a standard Adobe Commerce storefront into a wholesale ordering system: company accounts with buyer hierarchies, negotiable quotes, shared catalogs with customer-specific pricing, requisition lists, quick order, purchase-order approvals and company credit. Adobe ships it as a separate module (the B2B extension) that installs on top of Adobe Commerce, and it does not run on Magento Open Source. This guide walks through what each piece does in day-to-day operation, how the pieces fit together, what it realistically costs to run, and when a lighter B2B portal is the better buy.
In short
- Six core capabilities make up the Adobe Commerce B2B module: company accounts, shared catalogs, negotiable quotes, requisition lists and quick order, purchase orders with approval rules, and payment on account with company credit.
- Company accounts are the foundation: one legal customer becomes a company with an administrator, teams, users and roles, and every other B2B feature keys off that structure.
- Shared catalogs control both visibility and price per company; they replace the older customer-group pricing model and are the single biggest source of configuration mistakes.
- Negotiable quotes add a back-and-forth between buyer and sales rep inside the admin panel, with expiry dates, comments, line-level discounts and a one-click conversion to an order.
- Cost is mostly not the license: the B2B module is bundled into Adobe Commerce agreements, but the integration work (ERP pricing sync, PO numbers, credit terms) is where six-figure budgets go.
What does the Adobe Commerce B2B feature set actually include?
The B2B module is a bundle of roughly a dozen Magento modules, distributed together as the magento/extension-b2b package, that add wholesale workflows on top of the core Adobe Commerce storefront. Adobe documents the package as “B2B for Adobe Commerce” and versions it separately from the platform (the 1.4.x and 1.5.x lines pair with Adobe Commerce 2.4.6 through 2.4.8). It is installed via Composer, enabled per website, and configured through Stores, Configuration, General, B2B Features in the admin panel.
The feature set targets a specific kind of seller: a manufacturer, distributor or brand that sells to trade customers who order repeatedly, negotiate price, pay on terms and need more than one person inside their organization to place or approve orders. If that description does not match the business, most of the module goes unused, which is the central point in the Magento in 2026 overview of who still needs Adobe Commerce. A retailer with a handful of wholesale accounts can usually get by with customer groups and tier pricing that already exist in the core platform.
Choosing a platform around one feature set is rarely wise, and the broader trade-offs are covered in the guide to choosing the right e-commerce platform for your store. Within that decision, the question this article answers is narrower: once a business has decided that Adobe Commerce is the right base, what does the B2B layer actually deliver, and what does it demand in return?
| Capability | What it does | Who configures it | Typical dependency |
|---|---|---|---|
| Company accounts | Groups buyers under one legal customer with an admin, teams, users and roles | Merchant admin approves; company admin manages users | ERP customer master for account numbers |
| Shared catalogs | Sets which products a company can see and what it pays | Merchant admin (catalog and pricing team) | ERP or PIM price lists |
| Negotiable quotes | Buyer requests a quote from the cart; sales rep counters, comments and locks the price | Sales reps in the admin; buyers on the storefront | CRM or quoting tool, optional |
| Requisition lists | Saved reorder lists (up to 999 items each) that persist beyond a single cart | Buyers self-serve | None |
| Quick order | SKU entry, autocomplete and CSV upload directly into the cart | Buyers self-serve | Clean SKU data |
| Purchase orders | Approval rules by order total, shipping cost or SKU count before an order is placed | Company admin defines rules and approvers | None, but often mirrors internal procurement policy |
| Payment on account | Company credit limit, invoice-style checkout, reimbursements tracked in admin | Merchant admin sets the limit per company | ERP accounts receivable |
Every capability except quick order and requisition lists depends on the company-account structure, and the module is versioned and upgraded independently of the platform, so it belongs in the same change window; the process is laid out in the guide to planning an Adobe Commerce version upgrade without downtime.
How do company accounts and buyer role hierarchies work?
A company account in Adobe Commerce is a container that links one legal buyer to a set of storefront users, a payment configuration and a shared catalog. It is created either by a prospective buyer through the storefront “Create a company account” form, which then waits for merchant approval, or directly by the merchant in the admin under Customers, Companies. On approval, the company is assigned a status (Active, Pending Approval, Rejected or Blocked), a sales representative from the admin user list and a customer group, which in turn determines its shared catalog.
The person who registers the company becomes the company administrator. That role can add users, build a team structure (a simple tree of teams and sub-teams), assign roles with granular permissions and manage the company profile. Everyone else in the company is a company user whose permissions come from an assigned role.
What can roles and permissions control?
The default role set includes a company administrator, a default user and any custom roles the admin defines. Permissions are grouped into resources: viewing and managing orders, placing quotes, managing the company profile, managing users and teams, managing purchase orders and approval rules, and seeing company credit. A field sales rep, for example, can be given the right to submit quotes but not to view the credit balance, while a finance user gets the reverse.
Where does this break down in the real world?
The most common friction is the mapping between Adobe’s company model and the ERP’s customer model. Many ERPs distinguish bill-to and ship-to accounts, sometimes with dozens of ship-to locations under one bill-to. Adobe Commerce has a single company entity with multiple shipping addresses, so integrators typically map bill-to to the company and ship-to to the address book, then enforce which users can ship to which addresses through custom code or an extension.
How does the negotiable quote workflow run from request to order?
Negotiable quotes let a buyer turn a cart into a quote request, and let a sales rep negotiate inside the admin before the buyer checks out at the agreed price. The feature is switched on per website and per company (the company profile has an “Allow quotes” toggle), and buyers need a role with quote permissions. Once enabled, the storefront cart gains a “Request a Quote” button next to the checkout button.
The workflow runs in a fixed sequence, and each step changes the quote’s status in the admin panel:
- The buyer builds a cart, clicks Request a Quote, names the quote, adds a comment and optionally attaches files (PDFs, spreadsheets, drawings) up to a configurable size.
- The quote appears in the admin under Sales, Quotes with status Pending, and the assigned sales rep is notified by email.
- The rep opens the quote, can add or remove products, change quantities, apply a percentage discount, a fixed amount or a proposed total, set an expiration date and reply with comments. Line-item cost and margin are visible to the rep, not the buyer.
- The rep sends the quote back, and its status becomes Submitted. The buyer sees it under My Quotes, can accept it and proceed to checkout, or reopen it with a counter-comment, which sets the status to Updated and returns it to the rep.
- On acceptance, the buyer checks out at the locked price, with the quote’s shipping method and address. The order references the quote, and the quote status becomes Ordered.
A few operating rules matter. Once a rep touches the quote, prices on it are locked against catalog price changes and cart price rules until the quote is reopened, so promotions do not silently alter negotiated numbers. Expired quotes cannot be checked out; the rep has to extend the date. Since B2B 1.4, comments and file attachments are threaded, and reps can decline a quote with a reason rather than letting it expire.
What does the quote workflow not do?
Negotiable quotes are not a CPQ (configure, price, quote) system. There is no multi-level internal approval of the discount on the seller side, no margin floor enforcement beyond what the rep chooses to respect, and no proposal document generation beyond a printable quote page. Sellers that need those controls typically keep quoting in Salesforce CPQ or a similar tool and use Adobe Commerce quotes only for simpler, buyer-initiated negotiations, or push the accepted CPQ price into a shared catalog instead.
How do shared catalogs and customer-specific price lists set what each buyer pays?
A shared catalog is the Adobe Commerce B2B mechanism for controlling two things at once: which products a company can see, and what prices it sees. When the B2B module is enabled with shared catalogs turned on, the storefront stops using the standard “all products are visible, price by customer group” model and instead requires every company (and the guest and general public) to be assigned to a shared catalog.
There are two types. The single public shared catalog is what guests and non-company customers see; it can be the full catalog or a narrower retail subset. Custom shared catalogs are private and assigned to one or more companies. Each custom catalog has its own category structure selection, product selection and pricing, so a distributor can run a “Contractor” catalog with trade prices on 4,000 SKUs and a “Key Accounts” catalog with deeper discounts on 800 SKUs, both served from one product database.
How is pricing set inside a shared catalog?
Pricing within a shared catalog is applied through a wizard in the admin. Prices can be adjusted for a whole category or for selected products, as a percentage discount from the base price, a fixed new price or a percentage markup. Tier pricing (quantity breaks) is layered on top and can be defined per customer group, which, because each shared catalog creates its own customer group behind the scenes, effectively means per catalog. The result is a price matrix of catalog by product by quantity tier.
| Pricing scenario | Core Adobe Commerce (no B2B module) | With B2B shared catalogs |
|---|---|---|
| Trade price for all wholesale buyers | Customer group price on each product | One custom shared catalog with a percentage discount across categories |
| Different prices for 40 named accounts | 40 customer groups, product-level group prices, heavy admin effort | Up to 40 custom catalogs, or fewer catalogs plus negotiable quotes for exceptions |
| Hide restricted lines from some buyers | Not native; requires extension or category permissions workarounds | Native: leave the products out of that catalog |
| Quantity breaks per account tier | Tier prices per customer group per product | Tier prices per shared catalog, set in the wizard or by import |
| Prices synced from ERP nightly | Group price import via CSV or API | Shared catalog price import via API (companies and prices endpoints) |
Where do shared catalogs go wrong?
Three failure modes recur. First, indexing: every price change in a shared catalog needs the price and category indexers to run, and large catalogs with dozens of shared catalogs generate index tables that grow multiplicatively, which slows admin saves and can stretch full reindexes past acceptable windows. Second, ERP price sync: most distributors already maintain contract pricing in the ERP, and the integration has to translate that into shared catalog prices without creating a catalog per contract. Third, the public catalog: forgetting that guests are served the public shared catalog, and accidentally exposing trade prices or hiding retail products, is a launch-day classic.
Budgeting for those integration and performance issues is a large part of the cost picture, which the guide to total cost of ownership for Magento beyond licenses breaks down line by line. The short version: shared catalog pricing is powerful precisely because it is granular, and granular means more data to sync, index and keep consistent.
What do requisition lists and quick order change for repeat buyers?
Requisition lists are saved product lists that persist independently of the cart, designed for the buyer who orders the same 60 SKUs every two weeks with small variations. Each company user can create multiple lists (Adobe’s documentation cites a limit of 999 items per list, with a configurable cap on the number of lists per customer), name them, and add items from the product page, the cart or an order. Adding a list to the cart does not empty the list, which is the difference from a wishlist or a saved cart.
How does quick order work?
Quick order is a storefront page where a buyer types or pastes SKUs with quantities, gets autocomplete suggestions and adds everything to the cart at once. It also accepts a CSV upload of SKU and quantity columns, which is how buyers who run their own procurement spreadsheets tend to use it. Quick order is available to guests and retail customers as well if the merchant turns it on, because it does not depend on company accounts.
The constraint is data quality. Quick order matches on exact SKU, so a buyer whose internal part numbers differ from the seller’s SKUs gets no match. Sellers solve this either by loading customer part numbers as an alternative SKU attribute (which requires an extension or customization to search) or by giving buyers a requisition list that maps their numbers to the seller’s items once, at onboarding.
How do company credit limits and purchase-order payment work?
Two features cover the “buy now, pay later” side of trade: payment on account and purchase orders. They are frequently confused because both involve the phrase “purchase order,” but they solve different problems. Payment on account is a payment method backed by a credit limit that the seller extends to the company. Purchase orders in Adobe Commerce are an internal approval workflow on the buyer’s side before an order is submitted.
Payment on account and company credit
When payment on account is enabled, the merchant sets a credit limit per company in the company profile (in the base currency, or a specified currency with conversion), and can allow the company to exceed the limit if desired. At checkout, eligible buyers see “Payment on Account” as a method and can enter a PO number as a reference. The order total is deducted from the available credit, and the admin’s Company Credit tab tracks the balance, with a history of allocations, purchases, reimbursements and refunds. Reimbursements are recorded manually or via API when the ERP marks an invoice as paid.
Purchase order approval rules
The purchase order feature, when enabled for a company, inserts an approval step between “place order” and “order created.” The company administrator defines approval rules with three possible conditions (order total, shipping cost, or number of SKUs), each with a comparison operator and threshold, and assigns approvers by role. A rule such as “orders above 5,000 dollars require approval from the Purchasing Manager role” means that when a junior buyer submits such an order, it becomes a purchase order in Pending Approval status, the approver is emailed, and only after approval does the buyer complete payment and the order enter the standard order flow.
| Rule condition | Operators available | Example rule | Effect on buyer |
|---|---|---|---|
| Order total | More than, less than, equal, more or equal, less or equal | Total is more than 5,000 in base currency | Order waits for approver before payment |
| Shipping cost | Same set of comparison operators | Shipping is more than 250 | Flags expedited freight for review |
| Number of SKUs | Same set of comparison operators | SKU count is more or equal to 50 | Catches bulk orders for a second look |
| Multiple rules | All matching rules apply; each needs its approver | Total above 5,000 and shipping above 250 | Two approvals may be required in sequence |
Purchase orders and payment on account combine naturally: a company can require internal approval above a threshold and then pay the approved order against its credit line. Where they do not combine is with online card payment, because an approved purchase order that then requires the original buyer to enter a card can sit unpaid for days. Adobe added the ability for approvers to complete payment in later B2B releases, and integrators should verify the behavior on the version being deployed.
What does Adobe Commerce B2B cost, and how does it compare to Shopify Plus and BigCommerce?
The license question comes first because it is the one most people ask and the one with the least public information. Adobe prices Adobe Commerce on a quoted basis tied to gross merchandise value and average order value, and the B2B module has historically been included in Adobe Commerce and Adobe Commerce on cloud agreements rather than sold as a separate line item. Adobe does not publish rate cards, so any figure quoted online should be treated as a reported estimate; the reliable number is the one on the seller’s own proposal.
The costs that are predictable are implementation and operation. A B2B rollout on an existing Adobe Commerce store commonly involves ERP integration for companies, contract pricing and credit balances; theme work for the company dashboard, quotes and quick order pages; performance tuning for shared catalog indexing; and training for sales reps who will live in the quotes screen. Agencies quoting B2B implementations tend to scope them in the low six figures for a mid-market distributor, with the integration layer as the largest single item. That is consistent with the pattern in the Magento total cost of ownership breakdown: the platform is rarely the biggest line, the people and integrations around it are.
How does the feature set compare with the main alternatives?
Shopify Plus ships B2B natively with company profiles, price lists, quantity rules, net payment terms and draft-order quoting, and BigCommerce offers a B2B Edition with company accounts, quotes, price lists and sales-rep masquerading. Both are lighter than Adobe’s model on approval workflows and buyer hierarchies, and both are far quicker to launch. The comparison in BigCommerce versus Shopify for B2B and high-SKU catalogs covers those two head to head; the table below adds Adobe Commerce and the Open Source plus extensions route.
| Capability | Adobe Commerce B2B | Shopify Plus B2B | BigCommerce B2B Edition | Magento Open Source + extensions |
|---|---|---|---|---|
| Company accounts with roles and teams | Yes, with team tree and granular permissions | Companies with locations and permission levels | Company accounts with user roles | Via third-party extension, varies in depth |
| Negotiable quotes | Native, threaded, with expiry and attachments | Draft orders and quote apps | Native quotes in B2B Edition | Via extension |
| Customer-specific pricing | Shared catalogs, per-catalog tiers | Price lists per company location | Price lists per customer group | Customer group prices and tier prices |
| Purchase-order approval rules | Native, condition-based | Limited; app-dependent | Limited; app-dependent | Via extension |
| Credit limit and pay on account | Native company credit | Net terms per company | Net terms in B2B Edition | Via extension |
| Product visibility per account | Native through shared catalogs | Company-specific catalogs | Customer group visibility | Via extension or category permissions |
| Hosting and upgrade burden | High; version-locked module | None | None | High; extension compatibility |
| Typical fit | Complex trade with approvals and ERP contracts | Brands adding wholesale to DTC | Mid-market catalogs with straightforward pricing | Budget-constrained sellers with a capable dev team |
The pattern in that table is that Adobe Commerce wins on depth of workflow (approvals, hierarchies, quotes) and loses on time to launch and operating burden. A distributor with contract pricing per account, multi-person purchasing and net-30 terms is where Adobe’s module earns its keep; a brand with twenty retailers ordering four times a year would ship faster on either SaaS option.
When is a standalone B2B portal cheaper than Adobe Commerce B2B?
A standalone B2B portal here means a purpose-built wholesale ordering application, either a SaaS product or an ERP vendor’s own web storefront, that runs separately from the retail site and reads pricing and inventory directly from the ERP. Vendors in this space range from ERP-native storefronts to independent wholesale platforms, and several are considerably cheaper to run than a full Adobe Commerce B2B deployment.
The portal route tends to be cheaper in four situations. When the retail site is on another platform (Shopify, BigCommerce or a custom stack) and Adobe Commerce would be adopted only for B2B, the license and hosting cost of a second enterprise platform is hard to justify. When contract pricing is complex but lives cleanly in the ERP, a portal that renders ERP prices in real time avoids the entire shared catalog sync problem.
Two more cases favor the portal. When buyers are few and known, the self-service onboarding, public catalog and marketing features of Adobe Commerce go unused. And when the seller has no in-house Magento capability, the ongoing patching and upgrade cycle is a recurring cost that a SaaS portal simply removes.
When is Adobe Commerce B2B the cheaper option?
The calculation flips when the seller already runs Adobe Commerce for retail and the B2B module is included in the existing agreement, because the incremental cost is implementation only. It also flips when B2B buyers need the same merchandising, search, content and promotions the retail site has, since duplicating that in a portal costs more than reusing it. And it flips when the seller wants one product database, one order pipeline and one set of integrations feeding both channels, which is the strongest operational argument for a single platform.
Sellers weighing Open Source against the licensed edition should also note that the B2B module is one of the clearest dividing lines between the two: it is not available on Magento Open Source, and rebuilding it with extensions is possible but fragmented. The honest comparison of Magento Open Source versus Adobe Commerce puts that difference in context alongside the other licensed-only features.
What are the most common mistakes in an Adobe Commerce B2B rollout?
The mistakes below show up across implementations of different sizes, and most of them are avoidable with an extra week of planning before configuration begins.
- Turning on shared catalogs without designing the catalog structure. Enabling the feature immediately hides products from anyone not assigned to a catalog. Plan the public catalog, the custom catalogs and the assignment rules before flipping the switch on a live site.
- Creating one shared catalog per customer. A catalog per account works for ten accounts and collapses under indexing load at two hundred. Group accounts into pricing tiers and use negotiable quotes or ERP-driven price overrides for genuine exceptions.
- Treating company credit as accounts receivable. Without a reimbursement sync from the ERP, the storefront credit balance drifts and buyers get blocked or over-extended.
- Leaving quotes unattended. Quotes route to a named sales rep; if that rep is on leave and no reassignment process exists, the quote expires and the buyer walks. Set expiry defaults and a reassignment routine.
- Skipping role design. Companies onboarded with every user as an administrator have no approval controls, and retrofitting roles later means re-educating buyers.
FAQ on Adobe Commerce B2B
Is the B2B module included with Adobe Commerce, or is it a separate purchase?
Adobe has historically bundled B2B for Adobe Commerce into Adobe Commerce and Adobe Commerce on cloud infrastructure agreements rather than selling it as a separate SKU, and the module is downloaded from the Adobe Commerce Marketplace or Composer repository under the existing license. Adobe does not publish pricing, and entitlements can differ by contract and region, so the definitive answer is on the seller’s own agreement or from an Adobe account representative. It is not available for Magento Open Source under any license.
What is the difference between shared catalogs and customer group pricing?
Customer group pricing is a core platform feature that sets a price per product per group, with all products visible to everyone. Shared catalogs, part of the B2B module, control both visibility and pricing per catalog, and each shared catalog automatically creates a customer group behind the scenes. Once shared catalogs are enabled, every company and the public must be assigned to one, and product visibility follows the catalog rather than the standard catalog settings. Sellers moving from group pricing should expect the same outcomes through a different configuration path.
Can a buyer negotiate a quote without a company account?
No. Negotiable quotes require the buyer to be a user of an active company account with a role that includes quote permissions, and the company profile must have quotes enabled. Retail customers and guests see the standard cart and checkout only. Sellers who want non-company customers to request pricing typically use a contact form or a third-party quote extension for that segment.
How many company users, teams and requisition lists does the module support?
Adobe does not impose a hard limit on users or teams per company in its documentation; the practical constraints are usability of the hierarchy tree and admin performance. Requisition lists are capped at 999 items each, and the number of lists per customer is set by the merchant in configuration (the default is a small number, commonly adjusted upward for heavy reorder accounts). Very large companies are usually imported and maintained through the REST or GraphQL API rather than by hand.
Does Adobe Commerce B2B handle net-30 or net-60 payment terms?
Partly. The payment on account method extends a credit limit per company and records purchases and reimbursements against it, which is the storefront half of net terms. Invoicing schedules, statements, dunning and cash application are not part of the module and are expected to run in the ERP or accounting system, with reimbursements synced back to Adobe Commerce so the available credit stays accurate. Treat the module as a credit ledger, not an accounts receivable system.
Can approval rules require more than one approver?
Yes, indirectly. Each approval rule names one or more approver roles, and if a purchase order matches several rules, each rule must be approved. A company can therefore require a manager’s approval for any order above a threshold and a finance approval for orders where shipping exceeds a limit, and an order that hits both waits for both. Rules are defined by the company administrator, not the merchant, so the seller can offer the capability without managing every buyer’s policy.
How does the module affect site performance?
The main impact is on indexing. Each shared catalog adds a customer group, and price and category permission indexes scale with the number of groups multiplied by products and websites. A store with 50,000 SKUs and 30 shared catalogs is indexing far more rows than the same store with one catalog, which lengthens full reindexes and admin saves. Mitigations include limiting the number of catalogs, using scheduled (asynchronous) indexing, and keeping the search and cache layers properly sized.
What to read next
Deciding whether Adobe Commerce is the right base for a wholesale business is a platform question before it is a feature question, and the e-commerce platform selection guide lays out how the main options compare on cost, scale and operating model. From there, the Magento Open Source versus Adobe Commerce comparison is the natural next step for anyone weighing whether the licensed edition’s B2B module justifies the price gap over building on Open Source with extensions.