Distributors live or die by how cleanly the customer hierarchy maps to how their accounts actually buy. Adobe Commerce B2B gives you the right primitives (companies, divisions, roles, customer groups, shared catalogs), but the design choices made in the first month of an implementation will determine whether the system flexes with the business for the next five years or has to be reworked the moment a major account changes how it does procurement.
The patterns are not obvious from the documentation. Bemeir’s Adobe Commerce team has implemented B2B for distributors in industrial parts, beverage, foodservice, building products, and medical supply, and the design decisions repeat. This is the framework we use when sitting down with a distributor to architect the customer hierarchy before a single line of code is written.
The four primitives Adobe Commerce B2B gives you
The B2B layer in Adobe Commerce introduces four concepts on top of standard customer accounts. Each one is a tool for modeling a real-world distributor relationship.
Company. The legal entity that buys from the distributor. A company has a credit limit, a default shipping address, a default payment method, and a company admin. It is the unit at which contracts, pricing, and credit are managed.
Company user. A person who buys on behalf of the company. A company can have many users. Each user has a role within the company.
Company role. The set of permissions a user has within their company. Default roles in Adobe Commerce are Default User (place orders) and Company Administrator (manage users, addresses, view orders), but custom roles can be created with granular permissions (e.g., a role that can create orders but not submit them).
Customer group. The pricing and catalog bucket the company sits in. Customer groups drive shared catalog assignment, tax class, customer-specific pricing, and tier pricing eligibility. A company belongs to exactly one customer group at a time.
These four primitives are powerful and underused. Most implementations only configure two roles and one customer group per major account tier. The implementations that scale use the full system.
The hierarchy patterns that actually fit distributors
Distributors fall into four common hierarchy patterns. Pick wrong and the system fights the business for years. Pick right and customer-onboarding becomes a 20-minute admin task.
Pattern 1: Single buyer per company. Small accounts where one purchasing manager is the only buyer. Company has one Company Admin user. Shipping address is fixed. Pricing is by customer group. This is the simplest pattern and fits maybe 60% of accounts by count for most distributors, even when those accounts only represent 15-20% of revenue.
Pattern 2: Multiple buyers, no approval flow. Mid-tier accounts where two to ten people buy independently. Company has one Company Admin and several Default Users. Shipping addresses can vary per order. Pricing remains by customer group. This is the pattern for most mid-sized restaurants, contractors, and small medical practices.
Pattern 3: Multi-buyer with approval flow. Larger accounts where junior buyers request orders and a procurement manager approves before submission. This uses Adobe Commerce B2B’s approval rules, with custom roles like “Buyer Requester” (can create but not submit orders) and “Buyer Approver” (can approve and submit). The approval thresholds (by dollar amount, by shipping address, by SKU category) get configured per company. This pattern handles roughly 80% of large enterprise accounts.
Pattern 4: Multi-location company with division-level autonomy. The most complex. Companies with multiple physical locations (chain restaurants, multi-site contractors, hospital systems) where each location has its own buyers, its own approval flow, its own shipping address, and sometimes its own pricing. Adobe Commerce B2B supports this through the company structure with sub-companies, and it is where most distributor implementations get the design wrong.
For Pattern 4, the design question that matters most is: are the divisions treated as separate companies under a parent company, or as departments within a single company? The answer drives whether each division can have its own credit limit, its own approval flow, its own customer group, and its own pricing tier. Most distributors want this level of autonomy at the division level for their largest chain accounts.
Customer groups: how distributors should structure them
A common mistake is creating one customer group per major account. This does not scale: 4,000 accounts means 4,000 customer groups, and the admin overhead becomes unmanageable.
The pattern that works for most distributors is tiered customer groups by pricing band, with overrides at the company level for genuinely customized pricing.
| Customer group | Use case | Typical % of accounts |
|---|---|---|
| Standard B2B | Net-30, list pricing | 60% |
| Volume Tier 1 | 5-10% discount, monthly invoicing | 20% |
| Volume Tier 2 | 10-15% discount, monthly invoicing | 12% |
| Strategic Account | Custom catalog, custom pricing, dedicated rep | 7% |
| Internal/Employee | Cost-plus pricing for staff | 1% |
The 7% of accounts in the Strategic tier are where company-level pricing overrides apply: customer-specific catalogs, customer-specific shared catalog, and per-SKU price overrides through the Adobe Commerce shared catalog system. Everything below the strategic tier runs on customer-group pricing, which is dramatically easier to maintain.
Role design: the permissions matrix that matters
Adobe Commerce’s default roles work for simple cases. For most distributor implementations we recommend three to five custom roles. Here is the framework:
Company Administrator. Manage users, manage addresses, view all orders for the company, approve orders if approval is configured. One per company minimum.
Procurement Manager. All Company Admin permissions, plus the authority to approve high-value orders, add new addresses, and modify the approval workflow. Used in the largest accounts where the procurement function is separate from general account admin.
Buyer Approver. Approve orders submitted by Buyer Requesters within configured thresholds. Cannot manage users or addresses. This is the role assigned to department heads who approve their team’s orders.
Buyer Requester. Create orders, save quotes, build requisition lists, but cannot submit orders above a dollar threshold without approval. This is the role assigned to most line-level buyers in larger accounts.
Read-Only Viewer. View company orders and reports but cannot purchase. Useful for accounts payable, controllers, and external auditors who need visibility but should not be able to place orders.
The permissions in Adobe Commerce B2B’s role system are granular enough to define each of these without code. The exception is when the distributor wants role-based catalog visibility (some roles see some SKUs, others see different SKUs), which requires either separate customer groups per role or a custom permission layer. Most distributors should resist the urge to do this; complexity here grows faster than the business benefit.
Approval rules that scale
Adobe Commerce B2B approval rules can be configured at the company level by dollar threshold, by shipping address, by SKU, by SKU category, and by payment method. The two patterns that work for distributors are simple and predictable.
Dollar-threshold approval. Orders above $X require approval. The threshold is configured per company based on the buyer’s authority and the customer’s purchasing controls. Typical thresholds: $500 for small accounts, $5,000-$10,000 for mid-market, $25,000-$50,000 for enterprise.
Category-based approval. Orders that include SKUs from specific categories require approval regardless of dollar amount. Common use: controlled substances in medical distribution, hazardous materials in industrial, or anything subject to regulatory tracking.
The two anti-patterns we have seen distributors try and then walk back: complex multi-stage approval (level 1 approves, then level 2 approves, then submitted) and per-SKU approval at large scale. Both create approval queues that slow orders down to the point where buyers find workarounds.
How this connects to the ERP
The customer hierarchy in Adobe Commerce B2B is only as useful as its sync with the ERP. The distributor’s ERP (SAP, NetSuite, Microsoft Dynamics, Oracle, Sage Intacct) is the source of truth for customer account data, credit limits, pricing, and order history. Adobe Commerce mirrors the relevant subset.
The sync architecture choices that matter most:
Customer master direction. Almost always ERP-to-Adobe Commerce. New customer accounts are created in the ERP and synced to Adobe Commerce, where they become Company records. The Adobe Commerce admin can create users and assign roles, but the core company data flows from the ERP.
Pricing direction. Almost always ERP-to-Adobe Commerce, with customer-group pricing and customer-specific pricing both syncing from the ERP’s price book. Real-time pricing during browsing requires careful integration design; the Bemeir B2B team has shipped this with batch sync, cache-warm sync, and on-demand sync depending on catalog volatility.
Credit limit and credit hold. Synced from the ERP in near real time. If the ERP puts a company on credit hold, the Adobe Commerce checkout should block order submission. This integration point is where some implementations cut corners and cause expensive AR problems later.
Order direction. Always Adobe Commerce to ERP on order placement. The ERP becomes the system of record for fulfillment, inventory allocation, and invoicing.
The implementation order that works
For a distributor implementing Adobe Commerce B2B, the sequence that consistently delivers is: confirm the four-pattern model and pick the right pattern for each account tier, design the customer group structure with no more than seven groups, design the role permissions matrix with three to five custom roles, scope the approval rules with simple thresholds, build the ERP sync architecture before building the storefront, and only then start the UI implementation.
The mistake we have inherited from prior agencies most often is the reverse order: build the storefront, configure default roles, then discover at month four that the business actually needs the four-pattern model and the integration architecture cannot support it without significant rework.
Bemeir’s Magento team runs Adobe Commerce B2B discovery as a standalone engagement when the merchant wants the customer hierarchy and integration design locked in before implementation. The deliverable is a 25-30 page architecture document covering all of the above, with the customer hierarchy mapped to the merchant’s actual top 50 accounts as worked examples.
The discovery investment is small relative to the cost of getting the customer hierarchy wrong. Distributors who get this right have a B2B storefront that the sales team uses to onboard new accounts in minutes. Distributors who get it wrong have a system that the sales team works around. The four primitives Adobe Commerce gives you are enough to support either outcome; the design choices in week one determine which one happens.