B2B is not B2C with a purchase order attached. The architecture is fundamentally different. Yet most Magento B2B implementations start with a B2C mindset — a product catalog, a cart, a checkout — and then bolt on approval workflows and custom pricing as afterthoughts. The result is a B2C system wearing a B2B costume.
If you’ve ever inherited a “B2B project” that was really just a B2C store with company accounts and a PDF quote button, you know exactly what I mean.
Why the Confusion Exists
The confusion is understandable. Adobe Commerce ships a B2B module. Turn it on, and you get company accounts, shared catalogs, requisition lists, and negotiable quotes. It looks like B2B. But the difference between having B2B features and having a B2B architecture runs deep.
Three forces push teams toward the B2C-with-extras pattern:
- Agencies scope from B2C experience. Most Magento agencies built their expertise on B2C. They estimate B2B projects by adding line items to a B2C build — “add company accounts, add approval workflows” — instead of redesigning from the ground up.
- The platform defaults are B2C. Magento’s core architecture — catalog, cart, checkout, order — was designed for individual consumers. B2B layers sit on top, not beside.
- Stakeholders think in storefronts. Business owners describe what they want as “an online store for our dealers.” That framing already biases toward B2C patterns.
The Five Architectural Differences That Actually Matter
1. Pricing Is Not a Catalog Problem — It’s a Relationship Problem
In B2C, pricing is straightforward: a product has a price, maybe a sale price, maybe a tier price for quantity. The catalog owns the truth.
In B2B, pricing is a negotiation artifact. The same SKU might have:
- A list price nobody pays
- A contract price per customer, locked for 12 months
- Volume breaks that differ per account
- Formula-based pricing (cost + margin + freight surcharge)
- Negotiated quotes that override everything
Magento’s shared catalogs and tier pricing handle the simple cases. But the moment you need contract-level pricing tied to ERP agreements, customer-specific formulas, or quantity breaks that vary by product group and account — you’ve outgrown the catalog model.
The architectural split: pricing logic belongs in a pricing service or ERP, not in Magento’s catalog tables. Magento should display the price, not compute it.
2. The Buyer Is Not a Person — It’s an Organization
B2C has users. B2B has organizational hierarchies.
A single B2B “customer” might involve:
- A procurement team that builds requisition lists
- A department manager who approves orders up to €5,000
- A finance director who approves above that threshold
- A regional admin who manages catalog visibility for that division
Magento’s B2B module provides company structures with roles and permissions. It works for basic hierarchies. It breaks when:
- Approval routing depends on order value + product category + division
- Different subsidiaries share a parent account but have separate credit limits
- Users belong to multiple organizational units with different roles
The native model assumes a clean tree structure. Real B2B organizations are messier — matrix structures, temporary delegations, escalation paths when approvers are on holiday.
3. Orders Are Not Transactions — They’re Workflows
In B2C, checkout is a transaction. Click, pay, done. The order exists.
In B2B, an “order” might go through:
- Requisition — someone adds items to a requisition list
- Quote request — the list becomes a negotiable quote
- Internal approval — one or more approvers sign off
- Purchase order — a PO number is attached
- Order placement — the approved PO becomes an order
- Fulfillment tracking — with partial shipments, backorders, and split deliveries
- Invoicing — on terms (Net 30, Net 60), not at checkout
Each step has its own business rules, visibility requirements, and failure modes. A rejected quote goes back to the buyer. A timed-out approval escalates. A partial shipment generates a partial invoice.
Magento handles basic requisition lists and negotiable quotes. But the orchestration — the rules that govern transitions between states, the notifications, the escalation paths — that’s where custom work begins. And it’s where most B2B projects underestimate scope by 2-3x.
4. Catalog Segmentation Is Mandatory, Not Optional
In B2C, everyone sees the same catalog. Maybe you hide some products by customer group.
In B2B, catalog visibility is a core business requirement:
- Dealer A sees products from Category X at Contract Price Set A
- Dealer B sees products from Category X and Y at Contract Price Set B
- Internal staff sees everything at cost price
- Distributor Z sees a white-label catalog with different product names
Magento’s shared catalogs solve the basic case — assign different catalogs to different companies. But shared catalogs are all-or-nothing at the product level. They don’t handle:
- Attribute-level visibility (hide cost price from dealers, show it to internal)
- Dynamic catalog rules (show products only if the customer has purchased the prerequisite SKU)
- Regional catalog variations (same product, different descriptions and compliance data per country)
The more segmented your catalog needs, the more you push toward an external PIM feeding Magento per-customer catalog views — rather than managing it all inside Magento’s shared catalog tables.
5. Integration Complexity Is the Default, Not the Exception
A B2C Magento store might integrate with a payment gateway, a shipping carrier, and maybe a marketing platform. Three integrations, well-documented APIs, stable contracts.
A B2B Magento implementation typically integrates with:
- ERP — for pricing, inventory, order sync, credit limits (SAP, Microsoft Dynamics, Oracle)
- CPQ — for complex product configuration and quoting
- CRM — for account data, sales rep assignments, customer history
- PIM — for product data across catalogs and regions
- Logistics/WMS — for warehouse allocation, partial shipments, backorder management
- EDI — for customers who submit orders via electronic data interchange, not a browser
- Credit management — for payment terms, credit checks, and collections
Each integration has its own sync cadence, failure modes, and data ownership questions. The ERP is the pricing master. The PIM is the product data master. Magento is the commerce experience layer — not the system of record for any of them.
This is the architectural insight most B2C-trained teams miss: in B2B, Magento is the frontend for a system of systems. In B2C, Magento often is the system.
Where Magento B2B Module Gets You
The native B2B module covers more ground than most teams realize:
- Company accounts with hierarchical structures and role-based permissions
- Shared catalogs with custom pricing per company
- Requisition lists for repeat ordering
- Negotiable quotes with a basic back-and-forth workflow
- Purchase orders as a payment method
- Quick order forms for SKU-based entry
- Order approval rules based on order total
This gets you to about 60% of a typical B2B implementation. The remaining 40% — complex pricing rules, multi-level approvals with conditional routing, ERP-driven catalog segmentation, and integration orchestration — is where architecture decisions define project success or failure.
When to Keep It in Magento, When to Move It Out
Keep in Magento when:
- Your company hierarchy is a clean tree (parent → child → users)
- Pricing is tier-based or shared-catalog-based, without ERP contract overrides
- Approval workflows are simple (single threshold, single approver level)
- You have fewer than 5 integrations
- Your catalog segmentation maps cleanly to Magento’s shared catalog model
Move it out when:
- Pricing logic requires real-time ERP lookups or formula-based computation
- Approval routing depends on multiple dimensions (value + category + division + geography)
- You need EDI support or non-browser ordering channels
- Catalog segmentation requires attribute-level or rule-based visibility
- Integration orchestration involves retry logic, dead-letter queues, or reconciliation
The decision is not about capability — Magento can technically do almost anything with enough custom code. The decision is about maintainability. A custom approval workflow engine inside Magento works until you need to upgrade. A pricing calculation service in Magento works until the ERP pricing rules change quarterly and nobody wants to touch the Magento code.
The Leadership Question
If you’re a tech lead or CTO evaluating a B2B commerce build, the first question isn’t “which features do we need?” It’s “where does the truth live?”
- Pricing truth: ERP or Magento?
- Customer hierarchy truth: CRM or Magento?
- Product data truth: PIM or Magento?
- Inventory truth: WMS or Magento?
Every answer of “Magento” increases coupling. Every answer of “external system” requires an integration contract.
The second question is scope: how much of the order lifecycle lives in Magento? If the answer is “quote to cash,” you’re building an ERP frontend, not an e-commerce store. That’s fine — but price it, staff it, and architect it accordingly.
B2B projects don’t fail because the technology is wrong. They fail because the team assumed B2C patterns would stretch. They won’t. The architecture is fundamentally different — not because the platforms are different, but because the business processes are.
Start from the business process. Map the order lifecycle. Identify the system of record for each data domain. Then decide what Magento should own — and more importantly, what it shouldn’t.
Continue reading: Part 2 — Stop Forcing B2B on a B2C Platform: Choose the Right Tool for the Job
