B2B ecommerce is often described as “selling to businesses online.” That definition is correct but incomplete.

A real B2B commerce system has to understand relationships that consumer ecommerce can ignore: companies, users, locations, permissions, catalogs, contract prices, volume pricing, minimum quantities, payment terms, approval rules, orders, ERP data and sales teams. The storefront is only the visible part. The real product is the system connecting those rules.

That means agreeing on account, product, pricing and order rules before choosing a storefront, then deciding which existing system owns each one.

At a glance

  • B2B ecommerce is a rules system first and a storefront second.
  • Seven layers define it: identity, organisations, catalog, pricing, ordering, payment and operations.
  • Self-service removes repetitive admin work; it does not replace salespeople.
  • Start with one complete journey, not twenty partial features.

B2B ecommerce versus D2C ecommerce

Both models may involve products, carts and orders. The similarity ends quickly. A consumer represents themselves; a B2B user represents an organisation. That single difference changes the entire data model.

Dimension D2C B2B
Buyer An individual A user on behalf of a company
Pricing Public and uniform Contract, segment or quantity based
Access Open Authenticated and often approved
Ordering Add to cart and pay Quotes, approvals, purchase orders
Payment Card, instant Invoice, net terms, transfer
Data owner The store Shared with ERP, CRM and PIM

B2B ecommerce is therefore closer to a commercial operating system than to a traditional storefront:

USER
↓
COMPANY
↓
LOCATION / ACCOUNT
↓
PERMISSIONS
↓
CATALOG
↓
CONTRACT PRICE
↓
ORDER RULES
↓
APPROVAL
↓
PAYMENT TERMS

The seven layers of a B2B commerce system

A useful way to design one is to separate the problem into seven layers.

1. Identity

The system needs to know who is using it: login, invitation, registration, business verification, company assignment and account activation. Public registration is not always appropriate. A distributor may prefer registration, internal validation, approval and only then access. The registration workflow is part of the business process, not a formality. Account structure, access and approval decisions are explored in the B2B customer portal architecture.

2. Organisations and permissions

A professional account can contain multiple users with different permissions — owners, buyers, approvers and viewers. A manufacturer selling to chains may also need account locations, each with its own commercial rules:

COMPANY
├── Madrid branch
├── Barcelona branch
└── Valencia branch

3. Catalog

Not every customer sees every product. A catalog can depend on segment, geography, contract, distributor level, brand agreement or market. “The catalog” is often a computed view of the master product database rather than a fixed list.

4. Pricing

The final price can be influenced by base price, customer group, specific contract, product, quantity, promotion, currency, market and tax treatment. The data model must answer one question clearly: what is the source of truth for price? Hard-coding customer prices into frontend logic is rarely sustainable. For precedence, catalog and payment-term decisions, see B2B pricing architecture.

5. Ordering

Professional buyers may need SKU quick ordering, CSV upload, repeat orders, saved lists, bulk quantity entry, purchase order numbers, quotes, approval or scheduled replenishment. The right interface follows how customers already buy.

6. Payment

Immediate card payment is only one possibility. B2B terms can include bank transfer, Net 30, Net 60, deposit, credit terms or invoice after approval. The payment model belongs in discovery, not at the end of implementation.

7. Operations and integrations

Orders may need to reach an ERP, inventory may originate elsewhere, accounts may live in a CRM and product data in a PIM. Set ownership and recovery rules before choosing a sync pattern; the ERP/CRM integration guide works through those decisions:

CUSTOMER INTERFACE → COMMERCE LAYER → INTEGRATION LAYER → ERP / CRM / PIM / ACCOUNTING

Self-service does not mean removing salespeople

One of the most common misunderstandings around B2B ecommerce is that self-service should replace the commercial team. It often does the opposite.

Digital self-service removes repetitive administrative work — order status, invoice resends, price checks, availability and repeat orders — so salespeople can focus on account development, negotiations and new opportunities. The objective is not “no humans.” It is using humans where they create the most value.

Product discovery matters more in B2B

Large professional catalogs create specific usability problems. The buyer often knows exactly what they want and searches by SKU, reference, model, manufacturer code, dimensions, compatibility or technical specification.

That makes structured product data essential. If a buyer searches for an exact reference and the system cannot find it, the platform has failed even if the homepage looks excellent. Exact reference matching is a catalog requirement, not a substitute for the account, pricing and ordering architecture described here.

Platform, custom system or hybrid

There are three broad approaches. Commerce platform first uses Shopify or a similar platform for most buying functionality, best when the process fits established primitives. Custom application first builds the workflow around the business, best when ordering logic is specialised. Hybrid combines both for many established businesses. Platform features are not interchangeable: Shopify documents native company accounts and plan-specific catalogs, payment terms and checkout behavior in its B2B plan comparison; that is evidence about Shopify, not a universal B2B requirement.

What should be in the MVP

A B2B project can become enormous very quickly. A useful MVP replaces the highest-friction process end to end:

Company registration → validation → login → private catalog → correct pricing → order

Later releases add order history, reordering, documents, CRM integration, advanced permissions, quotes and reporting. Digitisation works better when the first release solves a complete business problem rather than implementing fragments of twenty features.

Metrics worth measuring

The system should be measurable from launch. Useful B2B commerce metrics include adoption, digital order share, repeat ordering, order errors, time to order, manual touches and search success. Not every project needs every KPI; measurement should follow the original operational problem.

The real starting point

The most useful first workshop for B2B ecommerce is not about design. It is about rules:

CUSTOMERS → PRODUCT ACCESS → PRICING → ORDERING → PAYMENT → FULFILMENT → DATA

Only then choose the platform. A strong implementation does not merely put a catalog online; it turns commercial rules into a usable system.

Continue reading

FRN.Q builds this kind of system under B2B Systems and Commerce. If the rules are still unclear, that is the right moment to talk through them on the contact page.