How B2B extends B2C

In B2B commerce, the person placing an order acts on behalf of a company, not as an individual shopper. That single shift cascades into everything else: a company has many buyers with different responsibilities, prices are negotiated per company, large orders need approval, and each buyer sees only the products they are entitled to.

In B2C, a Customer is the profile of a single shopper. In B2B, your customers are the companies you transact with, so account management becomes the defining concern: you model each buyer organization, its internal hierarchy, and the people who buy on its behalf, and then layer purchasing and approval flows on top. That is why this module starts with the buyer organization before moving on to Associates, pricing, and approvals in later modules.

commercetools models this by adding a B2B layer on top of the same resources you already use for B2C, rather than replacing them.

The parallel layer principle

The B2B layer adds a few more resources of its own (Associate Roles, Approval Rules, and Approval Flows), and the Store still resolves which Products it offers through Product Selections and Channels exactly as it does in B2C. Those details are covered later; the diagram shows only the relationships that define the layering.

{
  "id": "a1b2c3d4-0000-0000-0000-000000000000",
  "version": 3,
  "customerId": "f8a4e2c1-1111-2222-3333-444455556666",
  "businessUnit": {
    "typeId": "business-unit",
    "key": "horizon-hotels"
  }
}

The new resources B2B brings into play are introduced across this learning path:

• BusinessUnit: models the buyer organization (this module).
• Associate and AssociateRole: model who can act for the company and what they can do (Module 2).
• QuoteRequest, StagedQuote, and Quote: model negotiated purchasing (Module 6).
• ApprovalRule and ApprovalFlow: model spending governance (Module 7).
• RecurringOrder: models automated repeat purchasing (Module 6).

Five things that change in B2B

Use these five shifts as a checklist when you evaluate a B2B requirement. You do not need to absorb the details now; each shift maps to a specific platform capability that a later module covers in full.

1. The caller acts on behalf of a company. A buyer is an Associate of a company, so requests are made through the as-associate endpoint pattern (Module 2).
2. One company has many accounts and roles. Instead of one shopper with one account, a company has many buyers, each holding one or more roles (Associate Roles, Module 2).
3. Prices are negotiated per company. A list price or discount code is replaced by company-specific negotiated pricing, scoped through Channels and Customer Groups (Module 5).
4. Purchases may need approval. Above a spending threshold, an order requires sign-off through Approval Rules and Approval Flows before it can be placed (Module 7).
5. Assortments are restricted per account. Instead of any product being available to any shopper, each buyer sees a restricted assortment scoped through Stores and Product Selections (Module 3).

The Zen Electron Trade scenario

Three buyers recur throughout this learning path, each introduced when its complexity becomes relevant and each adding a new layer of B2B requirements:

One project or two?

A common early decision is whether to run B2B in the same Project as your B2C business, or in a separate Project.

• Complete data segregation between the two businesses is mandatory.
• Regional or compliance separation is required, for example GDPR or HIPAA boundaries.
• The business is too large to manage comfortably in a single Project.

The Architect's decision framework

As you evaluate each B2B requirement in this learning path, apply a consistent three-layer lens. This framework is a learning aid for this path, not official commercetools guidance, but it helps you reason about how to meet a requirement with the platform.

To see the lens in action, apply it to the "restricted assortments" requirement: each buyer sees only the products they are entitled to.

The framework is designed to cover the majority of B2B implementations. Rather than cataloging gaps, it guides you to evaluate what you can build by composing Stores, Channels, Custom Fields, Custom Objects, pricing, and API patterns to meet B2B requirements.

Two clarifications keep the lens honest:

• Native and configurable overlap. Much of what is configurable is configured on native resources, so treat the three layers as a sequence you work through, not rigid boxes a requirement falls into.
• Business logic sits on top. commercetools provides the native commerce resources; the customer-specific rules that real B2B adds, such as vetting a new buyer, enforcing contract terms, or deciding which accounts and users sync in from a CRM, typically live in an orchestration or middle layer that calls the platform APIs. Naming that boundary sets realistic expectations without turning this module into an integration guide.

• Budget management and credit-limit enforcement.
• Punchout catalogs (cXML/OCI) and EDI document exchange.
• CPQ for complex configurable products, and marketplace order routing.
• Invoice-based payment and reconciliation through a PSP or ERP.
• Order management (OMS), returns, and RMA handling.
• ERP-sourced historical order data, sometimes used to drive pricing tiers or approval triggers.

These are not gaps in the platform. commercetools governs the commerce transaction and exposes the data these systems need through native and custom fields and Custom Objects; the external systems own the surrounding processes. You name these boundaries as they arise rather than model around them.

Key takeaways

• In B2B, the caller acts on behalf of a company, which changes how identity, pricing, approvals, and assortments work.
• The five things that change in B2B are: acting on behalf of a company, many accounts and roles, negotiated per-company pricing, purchase approval, and restricted assortments.
• The Parallel Layer Principle: B2B sits on top of B2C. An Associate is a Customer, and a B2B resource is a Cart, Order, Quote, Quote Request, Recurring Order, or Shopping List with its businessUnit field set.
• Prefer a single Project for B2B alongside B2C; use separate Projects only for full data segregation, compliance boundaries, or extreme scale.
• Apply the Native / Configurable / Modeling strategy lens to evaluate each B2B requirement.
• The platform provides native commerce resources; customer-specific business logic such as buyer vetting and contract terms sits on top in an orchestration or middle layer.
• Some requirements cross an integration boundary (budget and credit enforcement, punchout, EDI, CPQ, PSP and ERP payment, OMS); commercetools exposes the data and external systems own the process.

Test your knowledge