If you’re evaluating BigCommerce for a B2B project, the question that determines most of your build is whether you’re using B2B Edition. It’s the layer that turns BigCommerce from a B2C platform with B2B add-ons into something that genuinely belongs in a B2B conversation. After several B2B Edition builds, here’s the practical view.
What B2B Edition gives you out of the box
Company accounts and buyer hierarchy
The fundamental B2B feature is that a "customer" isn’t a person. It’s a company with multiple people inside it, each with different permissions. B2B Edition models this natively:
- A Company is the account (usually mapped to your ERP customer). Companies can also be nested as parents and children, up to five layers deep, which fits chains, franchises and customers with many locations.
- Inside the company are Buyers, each with a role. There are three built-in roles. A Junior Buyer can request quotes and build Shopping Lists but cannot place orders. A Senior Buyer can place orders, approve Shopping Lists and see the company order history. An Admin can do all of that, plus manage addresses and users and pay invoices. There is no built-in view-only role, but you can create one as a custom role.
- Every buyer in a company shares the company’s address book, and address permissions apply to the whole company, not to individual buyers. If the buyer for the Cleveland warehouse must never ship to Dallas, set up each location as a child company with its own addresses and buyers, and turn off new addresses at checkout so buyers can only pick a saved one.
If your business sells to companies-as-customers and not consumers, this alone is worth the B2B Edition license.
Quote-to-order workflow
Buyers can request a quote on a cart, sales reps can edit pricing and approve, and the quote becomes a converted-order with the agreed prices. The flow is built in. What you customize is who gets quote requests, what overrides are allowed, and how approvals flow through ERP.
Price lists
Each company is placed in a customer group, and a price list is assigned to that group. The price list can set completely different prices for any variant, with separate prices for each currency. Which products a company can see is set separately, through the customer group’s category access. Price lists together with customer group category access are the workhorse for "Customer A sees a different catalog than Customer B" without needing a separate site.
Shopping Lists (requisition lists)
Frequent re-orderers (warehouses, MRO buyers, anyone who orders the same SKUs every month) can save Shopping Lists, share them with teammates, and move the items to the cart in a few clicks. Lists built by a Junior Buyer go to a Senior Buyer or Admin for approval first. Buyers can also re-order from a past order, or from their previously purchased products in Quick Order. This is the single feature that’s most loved in our user testing: buyers actually appreciate when their daily workflow is shorter.
Buyer Portal
Company-wide order history for buyers with permission, filterable by who placed the order. An invoices view with open and overdue balances and online payment. Order details that list each shipment with its tracking number. Standard, but real. There is no general contact form for the sales rep: buyers reach the rep through quote requests and the message thread on each quote.
What B2B Edition doesn’t do
Equally important to scope honestly:
- Real-time ATP from your ERP. B2B Edition uses cached inventory like the rest of BigCommerce. If your B2B model demands real-time available-to-promise from the ERP at request time, you’ll need a custom integration (or you’re really looking at Sana Commerce, not BigCommerce).
- Complex pricing formulas. Price lists store a set price per variant and per currency, with optional quantity tiers (percent off, amount off per unit, or a fixed unit price). They do not hold list-relative rules. If your pricing rule is "5% off list, then 2% if quantity ≥ 100, then a customer-specific override," the quantity break can live in a tier, but the list discount and the override get resolved into prices on the price list.
- Per-product visibility for one customer. Visibility comes from the company’s customer group, not the price list, and it works by category: each group can see all categories, a chosen set, or none. A product stays visible if it sits in any category the group can access, so hiding one SKU from one customer means keeping it out of every category that customer’s group can see.
- Multi-currency credit for a single company. A company has no currency of its own. Buyers choose from your transactional currencies, and price lists carry a separate price for each currency, so one company can buy in EUR and USD. The catch is company credit: it is set in one currency, and a buyer who checks out in another currency cannot use the Purchase Order payment method. If the customer needs PO terms in both currencies, that still means two companies.
Integration patterns that hold up
ERP → BigCommerce sync
Most B2B Edition projects pull customer + price list data from the ERP on a schedule (hourly is typical, real-time for high-stakes data). The integration we recommend is:
- A small middleware service (.NET or Node, your choice: we usually pick .NET because the rest of the stack is .NET) that owns the sync logic, not the ERP and not BigCommerce.
- Idempotent syncs keyed on a stable customer/SKU identifier, never on names or addresses.
- An audit log of every sync action so when a customer says "my price changed yesterday and nobody told me," you can answer.
Quote-to-order → ERP back-flow
When a quote converts, you need that order to land in the ERP. The order comes from a checkout built on the quote, so it carries the agreed prices, and the ERP should create a sales order with those prices and skip its own pricing engine. Check how a fixed-amount discount on the whole quote comes through, since B2B Edition does not fold it into the quote’s line prices. This is one of the few places we routinely build custom: every ERP’s sales-order API has its quirks.
Buyer SSO
For mid-market and up, buyers expect to log in via their corporate identity provider. B2B Edition supports buyer SSO, but there is no built-in SAML switch. Your own service (or a marketplace SSO app) accepts the login from the customer’s identity provider, such as Okta or OneLogin, then signs the buyer in through BigCommerce’s Customer Login API or a B2B storefront token. Production-ready integration is meaningful work. Plan 1 to 2 weeks for it, plus the configuration in the customer’s IdP that you don’t control.
Stencil vs Catalyst with B2B Edition
We’ve covered Stencil vs Catalyst more broadly. For B2B Edition specifically: Stencil has more polished out-of-the-box B2B Edition UI integration. Catalyst can run the same Buyer Portal, so quote management and masquerade come with it, but BigCommerce still labels the Catalyst integration experimental and its B2B starter template is marked alpha. Your team wires the login handoff, the portal startup and the product page buttons such as "Add to quote" in the Catalyst codebase. If B2B Edition is core to your launch and your team is small, that’s a Stencil tilt. If you have a frontend platform team and B2B Edition support in Catalyst is "good enough" for your screens, Catalyst gives you headless freedom.
The takeaway
B2B Edition is genuinely good. It’s also a layer of complexity you don’t need if your business is closer to B2C-with-bulk-orders than to multi-buyer corporate accounts. Be honest about which you are. The wrong reason to buy B2B Edition is "we’re B2B so we should." The right reason is "our customers buy in teams, and the storefront has to model that or our reps will keep doing the work manually."
Sizing a B2B Edition build? Talk to us. We’ve done several, and we’ll tell you which features actually move the needle for your buyers.