B2B ecommerce architecture has to represent a trading relationship, not merely a consumer profile with a company name. One legal customer may contain regions, divisions, cost centers, ship-to sites, buyers, approvers, bill-to parties, and accounting contacts. Each can have negotiated assortments, prices, tax treatment, payment terms, credit, purchase-order requirements, and authority limits. A person may represent several business units in different roles.
The architecture should make the represented organization and buying authority explicit on every cart and order. It also needs effective-dated commercial terms and a clear boundary between commerce, CRM, ERP, identity, tax, and finance. The storefront can provide a coherent experience without becoming the source of every enterprise fact. Preserve the facts and approvals used at order acceptance so later master-data changes do not rewrite history.
Model legal customers, business units, sites, and people separately
Create stable identifiers for legal entity, business unit, site, customer account, person, and external master records. A business unit hierarchy supports policy inheritance but should not be treated as the legal hierarchy automatically. Define parent, ownership, effective interval, status, and source for every relationship. Support multiple bill-to and ship-to sites with validation and approval; do not copy addresses into user profiles as unmanaged text.
commercetools Business Units can organize companies and divisions, associate customers with roles, and inherit selected data and approval rules. That illustrates a useful pattern: users act as associates of a represented unit rather than owning company data personally. At sign-in and cart creation, establish an active account context and include it in authorization, price, inventory, tax, and audit requests.
| Object | Purpose | Likely authority | Order snapshot |
|---|---|---|---|
| Legal customer | Contracting and tax identity | ERP or customer master | Registered name, identifiers, terms reference |
| Business unit | Delegated organizational scope | Commerce or master-data service | Unit path and policy revision |
| Site | Ship-to, bill-to, service location | ERP with commerce validation | Address, restrictions, tax evidence |
| Person | Human identity and contact | Identity provider plus CRM | Name and contact needed for transaction |
| Role assignment | Permission to represent a unit | B2B authorization service | Role and approval authority used |
| Commercial agreement | Assortment, price, terms, obligations | Contract or pricing service | Agreement and price revision |
Authorize represented buyers with scoped roles and conditions
Define permissions as actions over resources in account context: view assortment, create cart, submit requisition, place order, approve, manage users, view invoices, use credit, or change addresses. Add conditions for business unit, site, category, amount, currency, cost center, and effective time. Enforce on the server for every operation. The UI can hide unavailable actions but is not an authorization boundary.
Adobe Commerce's company roles and permissions documentation describes role-controlled access to sales, quotes, profile, payment, and credit resources. Build lifecycle controls around roles: verified administrator bootstrap, invitation expiry, separation for high-risk administration, periodic review, immediate offboarding, and audit. A customer administrator may delegate buyers but should not be able to grant platform or finance-operations privileges.
Resolve contract pricing and assortment with reproducible precedence
Price resolution needs product and variant, quantity tier, unit of measure, account or group, contract, market, currency, channel, site, date, and promotion context. Establish precedence among customer-specific, business-unit, group, channel, country, list, and quoted prices. Return price value, tax basis, minimum quantity, break, validity, agreement id, source revision, and explanation. Never cache only by SKU; that leaks negotiated prices between accounts.
The commercetools pricing and discounts overview documents scoped prices and fallback behavior, including customer-group considerations. Regardless of platform, snapshot accepted unit price, allowances, charges, currency, tax inputs, and agreement reference on the order. Reprice a saved cart when terms expire and show differences before submission. Quote acceptance should create a controlled price commitment with validity and permitted quantity variance.
| Order | Rule source | Applies when | Conflict treatment |
|---|---|---|---|
| 1 | Accepted quote | Quote, buyer, items, quantity, and validity match | Reject silent substitution |
| 2 | Customer contract price | Effective agreement covers item and site | Use named contract revision |
| 3 | Business-unit or group price | Membership and scope are valid | Apply deterministic most-specific rule |
| 4 | Channel and market price | No negotiated price applies | Respect currency and country |
| 5 | Base list price | Eligible fallback | Disclose that contract price is unavailable |
| Separate | Promotion or allowance | Contract permits combination | Apply explicit stacking and cap rules |
Orchestrate requisition and purchase approval before order acceptance
Separate cart, requisition, approved purchase, and accepted sales order. Submission freezes an approval snapshot: items, quantities, prices, tax estimate, freight, ship-to, cost center, project, requested date, payment method, PO number, and rule version. Route by amount, category, budget, site, exception, and requester authority. Support serial, parallel, and any-of approvals with delegation and expiry. Approvers need the full commercial delta, not merely a total.
After approval, revalidate material facts before acceptance. Price validity, stock, credit, address, tax, sanctions, and product restriction may have changed. If a material change exceeds policy tolerance, return to the requester or approver with a diff rather than silently accepting. Maintain requester, represented unit, approvers, decisions, comments, timestamps, policy, and resulting order. A purchase order number is customer data, not proof that internal approval occurred.
Control credit, payment terms, and invoice exposure
ERP or finance should own approved credit limit, terms, blocks, overdue exposure, and currency. Commerce requests an availability decision using legal customer, bill-to, amount, currency, order risk, and current exposure. Reserve credit during order acceptance with a stable reference; release or convert it as invoices and cancellations occur. Define behavior when ERP is unavailable: fail closed for new exposure, allow a small approved offline threshold, or route to manual review.
Available credit is not simply limit minus posted invoices. Include open orders, unbilled shipments, pending credit reservations, disputed balances under policy, and stale-data margin. Separate authorization to select invoice terms from authority to exceed credit. For card or bank payment, apply the appropriate payment lifecycle instead. Never expose another subsidiary's invoices or credit through a shared parent account unless contractual and authorization rules explicitly permit it.
Integrate B2B order-to-cash with versioned documents and reconciliation
Use canonical business events and map them at boundaries rather than forcing one database schema across CRM, commerce, and ERP. OASIS UBL 2.4 defines standard business documents including Order, Order Response, Despatch Advice, Invoice, Credit Note, and Remittance Advice. Even when JSON APIs are used, those document roles help teams avoid conflating buyer request, seller acceptance, shipment, invoice, and payment.
Give messages document id, version, sender, receiver, correlation, effective time, currency, line identity, and idempotency key. Reconcile accepted order to ERP sales order, fulfillment, invoice, credit memo, and remittance. Exceptions need an owner: rejected master-data mapping, price difference, tax difference, duplicate PO, credit block, partial acceptance, and unit conversion. Publish customer-visible status from authoritative milestones without exposing raw internal codes.
Test tenant, authority, price, and credit boundaries
Build negative authorization tests for a buyer switching companies, inherited role removal, expired delegation, sibling business units, unauthorized ship-to creation, invoice access, approval self-dealing, and stale sessions after offboarding. Verify every API uses represented account and resource scope from trusted server context. Cache keys, exports, search indexes, notifications, and support tooling need the same isolation tests as transactional endpoints; leaks often occur outside the cart.
Create commercial golden orders that combine unit conversion, quantity break, accepted quote, contract expiry, promotion stacking, tax exemption, credit reservation, partial acceptance, and later credit memo. Reconcile the commerce snapshot to ERP documents without requiring today's master data to reproduce yesterday's order. During an ERP outage exercise, prove the exact offline policy and queue recovery. An ambiguous fallback to list price or unrestricted credit can damage a key account faster than a visible temporary hold.
B2B ecommerce architecture takeaways
- Separate legal entity, business unit, site, person, role assignment, and commercial agreement identities.
- Require an explicit represented-account context for every cart, price, approval, and order operation.
- Resolve prices through deterministic precedence and snapshot the accepted commercial evidence.
- Freeze requisitions for approval, then revalidate material facts before seller acceptance.
- Reserve credit against total exposure and define bounded behavior when finance systems are unavailable.
- Reconcile distinct order, response, shipment, invoice, credit, and remittance documents across systems.
B2B ecommerce architecture FAQ
Can the CRM account be the complete B2B commerce model?
Usually not. CRM may own relationships and sales activity, while commerce needs transactional roles, sites, price context, approval, and carts; ERP often owns legal, credit, invoice, and fulfillment facts. Link stable identities and assign field authority instead of copying one record everywhere.
Can one buyer represent multiple companies?
Yes, with separate role assignments and an explicit active context. Never infer the company only from email domain. Show the represented unit prominently and prevent cart, address, price, and order data from crossing contexts.
When should credit be checked?
Preview during cart and requisition, then make an authoritative reservation at order acceptance. Recheck when amount, bill-to, currency, or exposure materially changes. Shipment release may require another control under finance policy.
Conclusion
B2B digital buying succeeds when it faithfully represents who is buying, for which organization, under what agreement, with whose approval and credit. Explicit identities, scoped authorization, reproducible pricing, approval snapshots, and document-level reconciliation let the storefront simplify purchasing without flattening the enterprise controls that make the transaction valid.