# 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

If you already know the B2C core (the [Customer](/api/projects/customers.md), the [Cart](/api/projects/carts.md) and [Order](/api/projects/orders.md), the [Store](/api/projects/stores.md) and [Channel](/api/projects/channels.md), and the Products and prices they expose), B2B adds a company layer above it. The same Customer authenticates, and resources such as the Cart, Order, and Quote gain a `businessUnit` reference that ties each one to the company it belongs to.

In the data model, that reference lives **on** the B2C resource: a Cart, Order, or Quote carries a `businessUnit` field that points to its Business Unit. The diagram below places the B2B layer on top to show the scoping; in the data, the `businessUnit` field is stored on each resource, as the Cart example further down shows.

```mermaid
graph TB
 subgraph B2B["B2B layer"]
	BU[BusinessUnit]
	AS[Associate]
 end

 subgraph B2C["B2C core"]
	CU[Customer]
	RES["Cart, Order, Quote,<br/>Shopping List, and more"]
	ST[Store]
	PROD[Product]
 end

 AS -->|references| CU
 BU -->|scopes| RES
 BU -->|references| ST
 ST -->|offers| PROD
```

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.

An Associate **is** a Customer. A B2B resource is simply a Cart, Order, Quote, Quote Request, Recurring Order, or Shopping List that has its `businessUnit` field set. The following abbreviated Cart response shows the principle: the `customerId` is the buyer's existing Customer identity, and the `businessUnit` reference is the B2B scoping layer added on top.

```json
{
  "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](/api/associates-overview.md#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

Throughout this learning path, you model **Zen Electron Trade**, the wholesale division of Zen Electron, the multi-brand Australian electronics retailer you already know from the B2C learning paths. Zen Electron Trade sells to business buyers such as hotels, corporate offices, and property developers.

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

| Buyer | Structure | Buying mode | Complexity |
| --- | --- | --- | --- |
| **Horizon Hotels** | Flat: one Company, no Divisions | Self-service: procurement staff reorder known products directly | Simplest B2B setup |
| **Pacific Property Group** | Company + two Divisions (Residential, Commercial) | Hybrid: divisions order independently with company oversight | Hierarchy, division-specific assortments |
| **Atlas Corporate Solutions** | Company + two Divisions (APAC, EU), multi-currency | Quote-based: orders go through quote and approval cycles | Full B2B complexity |

The **buying mode** reflects how each organization interacts with the platform, not just how it is structured. Horizon Hotels uses the platform as a fast replenishment tool. Pacific Property Group's divisions operate semi-autonomously but require company-level visibility. Atlas Corporate Solutions requires full negotiation and formal approval chains. These modes determine which architectural patterns apply to each buyer.

## 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.

In most cases, a **single Project is recommended**. B2B features are extensions of B2C functionality on a shared data model, so a single Project lets you reuse Products, Customers, and configuration across both.

Choose **separate Projects** only when requirements demand it:

- **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.

commercetools offers [B2X Commerce](/offering/commerce-b2x.md) as a branded product for running B2C, B2B, and B2B2C on a single platform with Stores and Business Units. B2X is a valid pattern but is out of scope for this learning path.

## 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.

| Layer | Question |
| --- | --- |
| **Native** | What does commercetools handle out of the box? |
| **Configurable** | What can be configured or extended within commercetools? |
| **Modeling strategy** | How can you model this requirement using commercetools resources and patterns? |

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

| Layer | Applied to restricted assortments |
| --- | --- |
| **Native** | Stores scope a buyer's commercial context, and Product Selections define which products a Store offers. |
| **Configurable** | Assign a dedicated Store and Product Selection to a Business Unit so its buyers see only that assortment. |
| **Modeling strategy** | Give each Division its own Store and Product Selection where assortments differ, or share the parent Company's Store where they do not (Module 3). |

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.

Most requirements resolve within the three layers, but some genuinely cross an **integration boundary** to an external system. Recognizing them early sets realistic expectations, and you will meet examples of each in later modules:

- 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.

## Related pages

- [Area overview page with navigation](/learning-model-b2b-commerce.md)
- [Previous page: Overview](/learning-model-b2b-commerce/model-buyer-organizations/overview.md)
- [Next page: Business Units: Company and Division](/learning-model-b2b-commerce/model-buyer-organizations/business-units-company-and-division.md)