Adobe Commerce B2B Module: What It Can and Can’t Do

Adobe Commerce ships with a B2B module that promises to handle company accounts, shared catalogs, negotiated quotes, requisition lists, and purchase order workflows out of the box. For some businesses, it delivers exactly that. For others, it becomes the most expensive part of a project nobody budgeted for.

We have tested this module across dozens of implementations – from straightforward distributors running a single catalog to complex manufacturers with multi-tier pricing, custom approval chains, and ERP-driven inventory. The gap between what the module handles natively and what real B2B operations actually need is where most projects run into trouble.

This is not a feature overview pulled from Adobe’s documentation. It is a field report based on implementations we have worked on, problems we have solved, and workarounds we have built when the module could not do the job on its own.

Key Takeaways

• Adobe Commerce B2B covers the fundamentals – company accounts, shared catalogs, requisition lists, quotes, and purchase orders – but each feature has hard limits that surface during real implementations.
• Company hierarchy support is shallow. If your org chart goes deeper than two levels or requires per-division permissions, you are writing custom code.
• Shared catalogs work well at small to medium scale but cause significant performance problems once you exceed a few hundred catalogs or tens of thousands of SKUs with custom pricing.
• The quote workflow is rigid. You get a single back-and-forth negotiation flow with no support for multi-approver chains, line-item-level negotiation, or automated pricing rules.
• Payment terms, net-30/60/90 invoicing, and credit limit enforcement are not included. Every B2B implementation we have worked on needed at least one of these, and all required custom development or third-party extensions.
• The module works best for businesses with simple hierarchies, moderate catalog sizes, and straightforward approval processes. The more complex your B2B requirements, the more custom work you should budget for.
• Implementation cost for the B2B module itself is typically 20-40% of total project cost when significant customization is needed. Plan for this from the start.

What the B2B Module Handles

Company Accounts

The module lets you create company accounts with a hierarchical structure. A company admin can manage their own users, assign roles and permissions, and control who can place orders, request quotes, or manage the company profile.

Each company gets a single admin who serves as the primary contact. That admin can create teams and sub-users, assigning them to different roles with granular permissions – view orders only, place orders up to a spending limit, manage quotes, edit company information, and so on.

The permission system covers most basic scenarios. You can restrict users to specific actions, set spending thresholds that trigger approval workflows, and control visibility into order history and account information.

What works well here is the self-service aspect. Company admins can handle their own user management without calling your sales team. New employees, role changes, departures – the company handles it themselves. For distributors and manufacturers with hundreds of customer accounts, this alone can save significant support overhead.

The company account also serves as the container for shared catalog assignments, negotiated quotes, and purchase order settings. Everything ties back to the company entity, which keeps things organized from an administrative perspective.

Shared Catalogs

Shared catalogs let you control which products each company can see and what prices they pay. You create a catalog, assign products to it, set custom prices at the product or category level, and then assign companies to that catalog.

The base concept is straightforward: Company A sees Catalog A with their negotiated prices, Company B sees Catalog B with different products and pricing. You can have a public catalog for guest browsing and multiple custom catalogs for specific customers or customer groups.

Pricing can be set as a fixed amount, a percentage discount off the base price, or a specific price per product. You can apply discounts at the category level (all products in category X get 15% off) or at the individual SKU level. Category-level pricing cascades down to products, and product-level overrides take precedence.

For businesses with tiered pricing – gold, silver, bronze customer levels – this works reasonably well. Create three catalogs, set the appropriate discount levels, assign companies to the matching tier. The admin interface for managing this is functional if not elegant.

Requisition Lists

Requisition lists are essentially saved shopping lists that B2B buyers use repeatedly. A purchasing agent who orders the same 50 items every month can save them as a requisition list and reorder with a few clicks instead of searching for each item individually.

Users can create multiple lists, share them within their company, and add items from product pages, search results, or previous orders. The list tracks quantities and allows quick “add all to cart” functionality.

This is a simple feature, but it is one that B2B buyers genuinely use and appreciate. The implementation is clean and does not require much customization for most use cases. It handles most reordering scenarios without modification.

Quote Management

The quote system lets buyers request a negotiated price on their cart. They submit a quote request, your sales team reviews it, adjusts prices or adds discounts, and sends it back. The buyer can accept, reject, or counter-propose. Once agreed upon, the quote converts to an order.

The workflow supports adding comments and file attachments at each stage, which is useful for RFQs that involve specifications, drawings, or other documentation. Expiration dates ensure quotes do not stay open indefinitely.

For businesses that handle negotiations on a per-order basis – custom manufacturing quotes, volume discount requests, project-based pricing – this covers the basic back-and-forth. The buyer gets visibility into quote status, and the sales team has a centralized place to manage negotiations.

Purchase Orders

Purchase orders add an approval layer to the ordering process. When enabled, orders are not placed immediately. Instead, they generate a purchase order that routes through an approval workflow before becoming a real order.

You can configure approval rules based on order value thresholds, user roles, or both. An order under $500 might auto-approve, orders between $500 and $5,000 require manager approval, and anything over $5,000 needs executive sign-off.

The system tracks PO numbers, approval status, and the full chain of who approved what and when. Buyers can reference their internal PO numbers, and the data flows through to order records and invoices.

Feature Maturity Table

Feature	Maturity	Customization Typically Needed
Company Accounts	Solid	Low to moderate – mostly role/permission extensions
Shared Catalogs	Functional	Moderate – performance optimization and pricing logic
Requisition Lists	Solid	Low – usually works as-is
Quote Management	Basic	High – workflow extensions almost always required
Purchase Orders	Functional	Moderate – approval chain customization common
Payment Terms	Not included	Build or buy – always required for real B2B
Credit Limits	Not included	Build or buy – frequently required
Company Hierarchy	Basic	High – deep hierarchies always need custom work
Customer-Specific Pricing	Basic (via catalogs)	Moderate to high depending on complexity
Sales Rep Portal	Not included	Build from scratch if needed

Where the B2B Module Falls Short

Advanced Company Hierarchy

The module supports a company with teams and sub-users, but the hierarchy is shallow. You get a company, teams within that company, and users within those teams. That is essentially two levels deep.

Real B2B organizations are more complex. A manufacturer selling through distributors might need: corporate headquarters, regional offices, individual branches, and departments within each branch – each with different ordering permissions, catalogs, pricing, and approval chains.

The module cannot represent this natively. Parent-child company relationships, where a corporate account manages multiple subsidiary accounts with independent budgets and orders, require custom development. Multi-level approval chains that follow the org chart – branch manager, then regional VP, then corporate procurement – are not supported out of the box.

We have built custom hierarchy extensions on multiple projects, and the effort is substantial. You are essentially replacing the company account management system while trying to maintain compatibility with the rest of the B2B module.

Shared Catalog Performance

Shared catalogs start showing performance problems as you scale. The issue is architectural – the way pricing overrides are stored and calculated creates database queries that grow exponentially with the number of catalogs and products.

With 10 catalogs and a few thousand SKUs, everything is fine. With 50 catalogs and 20,000 SKUs, you will notice slower page loads on category and search pages. With 200+ catalogs and 100,000+ SKUs, you are looking at serious performance engineering – custom indexing, aggressive caching, and potentially rearchitecting how prices are resolved.

The root cause is that each shared catalog creates pricing entries for every product in that catalog. If you have 200 catalogs and 50,000 products, you are potentially dealing with millions of pricing records that need to be indexed and queried on every page load.

We typically recommend keeping shared catalog count under 50 for standard infrastructure. Beyond that, plan for dedicated performance optimization work and potentially Elasticsearch or OpenSearch integration for catalog browsing.

Quote Workflow Rigidity

The built-in quote system handles a simple negotiation: buyer requests, seller responds, buyer accepts or counters, deal closes. For many businesses, this is not enough.

Common requirements that the native quote system cannot handle:

• Multi-approver workflows: A quote from your sales rep needs approval from a sales manager before going to the customer. Not supported natively.
• Line-item negotiation: The buyer wants to negotiate prices on specific items, not the whole cart. The module treats the quote as a single entity.
• Automated pricing rules: If a customer orders more than 1,000 units, automatically apply tier pricing in the quote. You have to do this manually or build custom logic.
• Quote templates: Save commonly used quote configurations for quick reuse. Not available.
• Multi-currency quotes: For international B2B, generating quotes in the buyer’s currency with your margin calculations. Requires custom work.
• Integration with CPQ tools: Complex product configuration and pricing needs are beyond what this module was designed for.

Every implementation we have worked on that involved the quote module required at least some customization to the workflow. Most required significant reworking.

Payment Terms

This is the most glaring omission. B2B commerce runs on payment terms – net-30, net-60, net-90, 2/10 net-30, and countless variations. The B2B module does not include payment terms functionality.

That means no credit limits per company, no automated invoice generation on terms, no aging reports, no credit hold workflows, and no integration with AR systems for balance tracking. You cannot set up a company with a $50,000 credit line and net-30 terms without building it yourself or buying a third-party extension.

Every single B2B implementation we have worked on required payment terms in some form. This is not an edge case – it is a core B2B requirement. Budget for it from day one.

Third-party extensions exist, and some are decent. But they add complexity, require their own maintenance, and introduce another vendor dependency. For enterprise implementations, most teams end up building custom payment terms integrated with their ERP.

No Native Configurator

If you sell products that require configuration – custom dimensions, material selections, option combinations with pricing implications – the B2B module does not help. Adobe Commerce has configurable products, but that is a different thing entirely.

A true product configurator handles rules (if you choose material A, you cannot choose finish B), visual rendering, dynamic pricing based on selections, and BOM generation. This is common in manufacturing B2B scenarios, and it requires either a dedicated CPQ extension or a custom-built solution.

Customer-Specific Pricing at Scale

While shared catalogs handle tiered pricing, real customer-specific pricing is more nuanced. A large distributor might negotiate prices on 500 individual SKUs, with different discount structures – some percentage-based, some fixed price, some volume-tiered.

The shared catalog approach of creating a unique catalog for each customer with custom pricing does not scale. You end up with hundreds of catalogs, each with thousands of pricing overrides, and the performance problems described above. The alternative is building a custom pricing engine that resolves prices based on customer, quantity, contract, and other factors without relying on the shared catalog architecture.

Self-Service Portal Limitations

B2B buyers expect more self-service than what ships out of the box. Common requests that require custom development include:

• Order tracking with carrier integration: Real-time shipment tracking from multiple carriers, not just order status updates.
• Invoice payment portal: Viewing and paying outstanding invoices online, applying credits, downloading statements.
• Return/RMA management: Submitting return requests with reason codes, tracking return status, receiving credits.
• Document center: Accessing contracts, certificates of compliance, SDS sheets, product documentation tied to their account.
• Budget management: Setting and tracking departmental budgets, with alerts when approaching limits.

Each of these is a separate development effort, ranging from moderate to significant depending on complexity and integration requirements.

Implementation Mistakes We See Repeatedly

1. Underestimating Shared Catalog Complexity

Teams plan for five customer tiers and end up needing 50 customer-specific catalogs because every major account has negotiated unique pricing. The architecture that worked for five catalogs collapses under the weight of 50. Start by mapping your actual pricing scenarios – not the idealized version – and load test with realistic data volumes.

2. Ignoring the Payment Terms Gap Until Late in the Project

Because the B2B module covers so many other areas, teams assume payment terms are included or will be simple to add. They discover the gap during UAT when a customer asks “where do I set up net-30 for this account?” Budget for payment terms integration from the requirements phase.

3. Treating the Quote Module as a CPQ Solution

The quote module handles simple price negotiation. It is not a configure-price-quote system. If your sales process involves product configuration, complex pricing rules, margin calculations, or multi-step approvals, you need a dedicated CPQ tool – either built custom or integrated from a third party like Oracle CPQ or Salesforce CPQ.

4. Building a Custom Hierarchy Before Exploring Alternatives

Some businesses rush to build complex company hierarchies in Adobe Commerce when the better solution is managing that hierarchy in their ERP or CRM and syncing relevant data to Commerce. The storefront does not always need to represent the full organizational structure. Sometimes a flatter model with smart integrations is simpler and more maintainable.

5. Not Testing with Real User Volumes

A B2B instance with 5 test companies and 100 products performs very differently from one with 500 companies, 50,000 products, and 30 shared catalogs. Load testing with production-scale data is essential, particularly for shared catalog pricing resolution and company account switching.

Configuration and Customization

Module Configuration Basics

The B2B module is enabled by default in Adobe Commerce but requires configuration to function. Key settings live in Stores > Configuration > General > B2B Features, where you toggle company accounts, shared catalogs, quotes, requisition lists, and purchase orders independently.

This modularity is genuinely useful. Not every B2B business needs quotes, and turning off unused features reduces complexity and potential performance overhead. Start with only the features you actually need and enable additional ones as requirements demand.

Each feature also has its own configuration section with options for email notifications, default settings, and behavioral controls. The quote module, for example, lets you set default expiration periods, minimum order amounts for quote requests, and which file types can be attached to quotes.

Extension Points

The module provides standard Magento extension points – plugins (interceptors), events, and API endpoints. If you need to modify behavior without changing core code, plugins on the B2B module’s service contracts are the right approach.

Common customization points include:

• Company account creation: Adding custom fields, triggering external system sync, implementing custom validation.
• Quote workflow: Adding approval steps, implementing custom pricing logic, integrating with external CPQ or CRM systems.
• Shared catalog pricing: Custom pricing resolution for complex scenarios, performance optimization for large catalogs.
• Purchase order approval: Custom approval rules beyond value thresholds, integration with ERP approval workflows.

The API coverage is reasonable. REST and GraphQL endpoints exist for most B2B operations, which is important for headless implementations and external system integrations. However, the GraphQL coverage for B2B specifically has historically lagged behind the REST API, so check current coverage if you are building a headless storefront.

Upgrade Considerations

Adobe releases B2B module updates with each Commerce version. These updates sometimes change database schemas, API behavior, or admin interfaces. If you have customized the B2B module heavily, upgrades require careful testing and potentially reworking customizations.

We recommend keeping customizations as decoupled as possible – using plugins rather than preferences, extending rather than replacing classes, and avoiding direct database modifications. This reduces upgrade friction significantly.

For heavily customized implementations, budget 20-40 hours per major version upgrade just for B2B module compatibility testing and fixes. This is on top of the general Commerce upgrade effort.

Real-World Implementation Experience

Distributor with 200+ Customer Accounts

A building materials distributor needed company accounts with custom pricing for each major customer, plus tiered pricing for smaller accounts. We started with shared catalogs but hit performance issues at 80 catalogs. The solution was a hybrid approach – shared catalogs for the five pricing tiers and a custom pricing override table for customer-specific exceptions. This kept the catalog count manageable while supporting thousands of customer-specific prices.

Manufacturer with Complex Approval Chains

A manufacturing company needed purchase orders to route through a four-level approval chain that varied by product category and order value. The native purchase order system only supports single-level approval with value thresholds. We built a custom approval workflow engine that integrated with the PO module, adding category-based routing and multi-level sequential approvals. The effort was approximately 300 development hours.

Multi-Brand B2B with Shared Customer Base

A company operating three brands on a single Commerce instance needed customers to see different catalogs and pricing depending on which brand site they were browsing. The shared catalog system does not natively support multi-store scoping well. The solution involved custom catalog resolution logic that factored in both the company assignment and the current store view. This was approximately 200 hours of development and ongoing maintenance with each upgrade.

Implementation Strategy

Start Simple, Extend Deliberately

The most successful B2B implementations we have seen follow a phased approach:

Phase 1 – Core Commerce: Company accounts, basic shared catalogs (tier pricing only), requisition lists. Get buyers logging in, seeing correct prices, and placing orders.

Phase 2 – Workflow: Purchase orders with simple approval rules, basic quote functionality. Layer on operational workflows once the core buying experience is solid.

Phase 3 – Advanced Features: Custom pricing logic, extended approval chains, payment terms integration, advanced self-service. Build these based on real usage data and user feedback from Phases 1 and 2.

This approach limits risk, delivers value early, and ensures customization investment is guided by actual user needs rather than assumptions.

Integration Planning

The B2B module does not operate in isolation. Plan integrations early:

• ERP: Company accounts, pricing, credit limits, payment terms, and order data all typically sync with an ERP. Define the system of record for each data type before development starts.
• CRM: Company hierarchy, contacts, and quote/opportunity data often need to sync with Salesforce or similar. Determine which system owns the relationship data.
• PIM: If you use a PIM for product data, shared catalog management may conflict with PIM-driven pricing. Establish clear ownership.
• Payment processor: B2B payment methods – invoicing, purchase orders, credit lines – require payment gateway integration that the module does not provide.

Performance Budgeting

Set performance budgets early and test against them regularly:

• Category page load with shared catalog pricing resolution: under 2 seconds
• Company account switching (admin): under 3 seconds
• Quote creation with 50+ line items: under 5 seconds
• Shared catalog reindex: establish baseline and monitor for degradation

These are targets, not guarantees. Hitting them depends on infrastructure, catalog size, customization complexity, and caching strategy.

Adobe Commerce B2B vs Alternatives

Adobe Commerce B2B vs Shopify Plus B2B

Shopify Plus added B2B features relatively recently, and the functionality is more limited than Adobe Commerce. Shopify Plus handles basic company accounts, customer-specific pricing, and payment terms through a simpler interface. It does not have shared catalogs, quote management, requisition lists, or purchase order workflows.

Choose Shopify Plus B2B if your requirements are straightforward – you need customer-specific pricing and a clean buying experience without complex workflows. Choose Adobe Commerce if you need quote negotiation, purchase order approvals, complex catalog management, or deep ERP integration.

Adobe Commerce B2B vs BigCommerce B2B Edition

BigCommerce B2B Edition offers company accounts, quote management, purchase orders, and customer-specific pricing. The quote system is more flexible than Adobe’s in some ways, with better support for sales rep workflows. However, BigCommerce is a SaaS platform with less customization depth – if you need highly custom approval chains or pricing logic, you have less flexibility.

Choose BigCommerce B2B for mid-market businesses that want solid B2B features without managing infrastructure. Choose Adobe Commerce for complex B2B scenarios that require deep customization and full control over the tech stack.

Adobe Commerce B2B vs OroCommerce

OroCommerce was built specifically for B2B from the ground up, unlike Adobe Commerce where B2B was added to a B2C platform. Oro has stronger native support for complex pricing (price lists, negotiated prices, volume tiers), multi-organization hierarchies, and workflow automation. Its quote and RFQ system is significantly more capable out of the box.

Choose OroCommerce if B2B is your sole focus and you need advanced features without extensive customization. Choose Adobe Commerce if you run both B2C and B2B on the same platform, need the broader Magento ecosystem of extensions and integrators, or have existing Magento expertise on your team.

Adobe Commerce B2B vs Commercetools with B2B Extensions

Commercetools takes a composable approach – you build B2B functionality using its API-first platform and extensions. There is no prebuilt B2B module; instead, you assemble the features you need from APIs, microservices, and your own code. This gives maximum flexibility but requires significantly more development effort for comparable functionality.

Choose Commercetools for large enterprises building a custom composable commerce stack with dedicated development teams. Choose Adobe Commerce if you want B2B features out of the box with the option to customize, and your team is more comfortable with a monolithic architecture.

Frequently Asked Questions

Is the Adobe Commerce B2B module included in the license, or is it an additional cost?

The B2B module is included with Adobe Commerce (formerly Magento Commerce) at no additional license cost. It is not available in Magento Open Source. You get the full module – company accounts, shared catalogs, quotes, requisition lists, and purchase orders – as part of your Adobe Commerce license.

Can we use the B2B module alongside B2C on the same Adobe Commerce instance?

Yes, and many businesses do. You can run B2C storefronts and B2B storefronts on the same instance using multi-store functionality. B2B features are enabled per website or store view. However, shared catalog pricing interacts with standard Magento pricing, so test thoroughly to ensure B2C customers see the correct prices and B2B customers see their negotiated prices.

How does the B2B module handle tax-exempt B2B customers?

The module itself does not handle tax exemption directly. Tax exemption is managed through Magento’s customer group and tax rule system, or through a tax calculation service like Avalara or Vertex. You assign B2B companies to tax-exempt customer groups, and the tax rules handle the rest. For businesses with customers in multiple jurisdictions with varying exemption statuses, a dedicated tax service is strongly recommended.

Can the quote module integrate with our existing CPQ system?

Not natively. The quote module has its own pricing and workflow logic. To integrate with an external CPQ system, you need custom development to sync quotes between the systems. This typically involves API integration where the CPQ system sends configured products and pricing to Commerce, which creates or updates the quote. The complexity depends on the CPQ system and how tightly coupled you want the integration.

What happens when a company account is deactivated?

When a company is set to inactive, all users associated with that company lose access to the storefront. They cannot log in, and any active quotes are suspended. Open orders are not affected – they continue processing. If the company is reactivated, users regain access and suspended quotes resume. This is useful for managing delinquent accounts or seasonal customers.

How do shared catalogs affect site performance?

Shared catalogs add database queries and indexing overhead proportional to the number of catalogs and products. Each catalog creates pricing index entries for its products. With fewer than 20 catalogs and under 10,000 products, the impact is typically negligible. Beyond that, you will need to monitor indexing times, implement Varnish caching strategically, and potentially optimize the pricing resolution queries. Full-page cache hit rates are critical – if most pages are served from cache, the underlying query complexity matters less.

Can B2B customers see and manage their own invoices through the storefront?

The module provides order history and order detail views, but it does not include a dedicated invoice management portal. Customers can see order information, but features like paying invoices online, viewing statements, downloading invoice PDFs, or managing credits require custom development or a third-party extension. If invoice self-service is a requirement, plan for this as a separate workstream.

Does the B2B module support EDI (Electronic Data Interchange)?

No. EDI integration requires separate middleware or an EDI-specific extension. B2B businesses that receive orders via EDI (common in manufacturing and distribution) need to set up an EDI translator that converts EDI documents to Commerce API calls. Several third-party providers offer Magento-compatible EDI solutions, but this is always a custom integration effort.

How long does a typical B2B module implementation take?

For a standard implementation using mostly native features – company accounts, two to three shared catalogs, requisition lists, and basic purchase orders – expect 8 to 12 weeks of development alongside the broader Commerce build. For implementations requiring significant customization – custom hierarchies, extended quote workflows, payment terms, ERP integration – the B2B-specific work can add 12 to 20 weeks. These are development timelines and do not include discovery, design, content migration, or UAT.

Can we migrate from Magento Open Source to Adobe Commerce to get B2B features?

Yes, but it is not a simple module installation. The migration involves upgrading from Open Source to Commerce edition, which requires a license change and codebase migration. The B2B module then needs to be configured and populated with company accounts, catalogs, and pricing. If you have existing customer accounts that need to become company accounts, plan for a data migration effort. The complexity depends on your current customizations and how they interact with Commerce-edition features.

Ready to Evaluate Adobe Commerce B2B for Your Business?

Choosing the right B2B commerce platform is a decision that affects your operations for years. If you are evaluating Adobe Commerce and want a realistic assessment of how well its B2B module fits your specific requirements – including what you will need to customize and what it will cost – we can help.

We have implemented Adobe Commerce B2B for distributors, manufacturers, and multi-brand operations. We know where it excels, where it struggles, and when a different platform might be a better fit. Contact us for a no-commitment technical assessment of your B2B requirements.