B2B ecommerce requirements must preserve company context from login to fulfilment
A useful B2B ecommerce requirements checklist defines the company, location, contact and role behind a purchase; which catalog, price, unit, availability and terms apply; who may request or approve an order; how checkout, purchase orders, payment, fulfilment and returns behave; which system owns each record; and which tests prove the whole transaction works.
Start with one real buying journey, not a platform feature spreadsheet. For example: a branch buyer reorders six products under a negotiated catalog, exceeds an approval limit, supplies a purchase-order number, receives two shipments, and disputes one line. If the requirements cannot explain that journey and its failure paths, they are not ready for vendor comparison or development estimation.
This guide focuses on the operating contract. Use the existing Shopify versus custom ecommerce guide to compare platform ownership, and the PIM requirements checklist when product information itself is the main constraint.
Define an eight-part account-to-order contract
Write the first requirement as a compact contract: the company context, commercial offer, buying authority, accepted transaction, fulfilment promise, known exceptions, accountable owners, and acceptance evidence. This keeps a technically valid storefront from producing an operationally invalid order.
Platform documentation shows why the company context matters. Shopify's official B2B object model distinguishes companies, company locations and contacts, and connects locations to catalogs, tax exemptions and payment terms. Adobe Commerce likewise documents company-specific shared catalogs and pricing. These are examples of product behavior, not universal requirements: your contract must reflect the way your customers actually buy.
Cover nine B2B ecommerce requirement lanes
| Lane | Define | Acceptance evidence |
|---|---|---|
| Account model | Company, locations, contacts, roles, delegation and lifecycle | A user can act only for the permitted company and location |
| Offer | Catalog, price, unit, quantity, availability and effective dates | The same buyer context resolves the same valid offer at cart and order |
| Buying flow | Reorder, quote, cart, approval, PO, budget and amendment rules | Ordinary and approval-required orders complete without an email workaround |
| Checkout | Addresses, delivery, tax, payment terms, credit and validation | Invalid combinations are blocked with an actionable explanation |
| Order lifecycle | Acceptance, allocation, split, backorder, change, cancel and return | Buyer and operator see consistent status and permitted next actions |
| Content and documents | Specifications, certificates, quotes, invoices and shipment records | The right version is visible to the right account at the right stage |
| Systems | ERP, PIM, WMS, CRM, payment, tax, carrier and identity authority | Every object and field has one named owner and recovery path |
| Controls | Permissions, accessibility, audit, privacy, security and fraud handling | Forbidden access and costly actions are tested, logged and reviewable |
| Operations | Administration, migration, monitoring, support, releases and reconciliation | Operators can diagnose and recover a failed transaction without editing data blindly |
Model the company, location and buyer separately
A person may buy for several legal entities or branches. A company may have multiple ship-to locations, billing accounts, catalogs, tax treatments, credit limits and approval policies. Requirements should state how users join a company, switch locations, delegate authority, recover access, and leave. Do not copy consumer-account assumptions into this model.
Define roles through permitted decisions: browse restricted products, see prices, request a quote, create a cart, submit an order, approve above a threshold, view invoices, manage users, or start a return. Test direct URL and API access as well as the visible interface. The OWASP authorization guidance recommends deny-by-default behavior, least privilege and validation on every request; those principles are especially important when one login can reach several business accounts.
Treat catalog and price as dated decisions, not display text
For each company location, define the eligible assortment, sellable unit, pack conversion, minimum or increment, contract price, quantity break, promotion precedence, currency, tax treatment and effective interval. Record what happens when a price changes after a quote, while an item sits in a cart, or before an approval completes.
Shopify's current catalog documentation describes product publications and price lists resolved by buyer context. Whatever platform you choose, acceptance tests should use overlapping catalogs, expired agreements, missing prices, blocked products, mixed units and customer-specific substitutions. A screenshot of the correct price is not proof that the accepted order preserved it.
Specify the order after the buyer clicks submit
Name the moment a request becomes an accepted order. A submitted cart may still require credit review, sales approval, inventory allocation or ERP validation. Give every visible status a business meaning, owner, permitted next action and expected communication. Avoid mapping several operational states to one vague label such as “processing.”
Test partial allocation, backorder, split shipment, changed delivery date, substituted product, rejected credit, duplicate submission, cancelled line, revised purchase order, return and credit. The order management requirements checklist goes deeper into lifecycle control. The commerce brief should still define which of those states buyers can see and which actions they may take.
Keep commerce useful without making it a second ERP
Build an authority matrix by object and field. The commerce platform may own the digital cart and buyer preferences while ERP owns accepted orders, invoices and credit; PIM owns enriched product content; warehouse software owns fulfilment events; and CRM owns sales activity. Your actual boundary may differ, but silent dual ownership is not a design.
For every handoff define identifiers, validation, timing, duplicate handling, acknowledgement, retry, exception queue and reconciliation. The API integration requirements checklist covers that contract in more detail. Also decide what buyers and operators see when ERP or warehouse systems are unavailable; false certainty is worse than a clear temporary state.
Include accessibility in the transaction, not as a final visual audit. Test company switching, catalog navigation, tables, quantity controls, validation messages, approval and checkout with keyboard and assistive technology against the applicable requirements. The current normative reference is WCAG 2.2.
Complete this first-release acceptance worksheet
- 1Buyer situation: company type, location, contact role, device, frequency and reason for buying.
- 2Commercial context: eligible catalog, units, quantities, price source, currency, tax, credit and effective dates.
- 3Happy path: exact steps from access through accepted order and visible confirmation.
- 4Authority: who may prepare, submit, approve, amend, cancel, return and administer.
- 5System boundary: owner for account, product, price, stock, order, invoice, shipment and support state.
- 6Hard cases: choose at least five, including one partial fulfilment and one unavailable dependency.
- 7Evidence: expected records, messages, audit trail, reconciliation totals and named sign-off owner.
- 8Release boundary: explicitly deferred company types, order paths, integrations and administrator tools.
Use the worksheet in a vendor demonstration or discovery session. Ask the team to run the real scenario with your roles, sample records and exceptions. Mark each requirement as standard, configurable, extension, custom, manual or unknown, and attach evidence. That creates a more honest estimate than a yes/no feature grid.
B2B ecommerce platform requirements FAQ
What should B2B ecommerce platform requirements include?
Include company accounts, locations and contacts; buyer and approver roles; account-specific catalogs and prices; products, units and availability; quotes, carts, purchase orders and approvals; payment terms, tax and delivery; order changes, fulfilment, returns and documents; ERP, PIM, CRM, warehouse and payment boundaries; security, accessibility, administration, monitoring, migration, support, and test evidence.
How is B2B ecommerce different from a B2C online store?
B2B buying often acts on behalf of a company location rather than only an individual. The visible catalog, price, tax treatment, credit terms, addresses, approval route, order documents, and fulfilment rules can depend on that company context. A retail storefront with login is not enough unless it preserves those rules through every transaction.
Should B2B ecommerce replace the ERP?
Usually not. The ERP commonly remains authoritative for customer, product, inventory, order, invoice, credit, or financial records, while the commerce platform owns the digital buying experience. Define ownership by object and field, then specify how accepted orders, updates, exceptions, and reconciliation move between systems.
Should a company buy, extend, or custom-build B2B commerce?
Buy or configure when a platform expresses the real account, catalog, pricing, approval, order, and integration model without fragile workarounds. Extend when the platform is a sound transaction core but a few differentiating workflows need focused interfaces or orchestration. Consider a custom product only when the workflow is materially distinctive and the business can own the ongoing product, security, integration, and support responsibility.