Company accounts, buyer roles and approvals: why one customer record per person is the wrong shape for B2B

A consumer platform assumes a customer is a person with an email address, a password, an address and a card. Everything downstream is built on that: the price they see, the addresses they can ship to, the orders they can look at, the emails they receive.

In B2B, the customer is an organisation. Northern Supply Ltd has a head office in one city and three branches in others. Four people can place orders. Two of them can only order up to a threshold. The controller can see every order and place none. Pricing is negotiated at the parent, but the Calgary branch has its own ship-to address, its own tax treatment and its own purchase order numbering. When the buyer at the Calgary branch leaves, their successor needs the same order history, because they are going to reorder from it.

Model that as one customer record per person and four specific things break, in this order. Pricing has to be attached to each person separately, so a new hire sees list price. Order history is fragmented, so nobody can reorder what a colleague bought. Ship-to addresses are duplicated per person and drift apart. And when someone leaves, their history leaves with them, or worse, their login is shared around the office because nobody wants to lose it.

This is why a company accountA company account is a customer record that holds several people, each with their own login and their own permissions. One buyer might place orders, another might only approve them, a third might only look up past invoices. is the structural feature to check first, before pricing, before catalogues. Almost everything else in B2B hangs off the answer to "what is the customer".

Six layers show up in nearly every mid-market distributor, and the number of them a platform models natively is a good proxy for how much integration work is ahead of you. Take this list to a demo and ask the vendor to show you each one in the admin.

Two of these are worth arguing about before you shortlist anything. Budgets and thresholds, because they are the ones customers ask for most and the ones platforms model least. And the approver, because a person who approves but does not buy is a role most consumer-derived platforms have no place to put.

All four were checked against vendor documentation on 20 August 2026. The counts and role names below are quoted from those sources rather than from vendor marketing.

Shopify B2B has a genuine two-level structure. A company is "the parent organization for one or more company locations", a company location is "the business that you’re selling to in a B2B transaction", and Shopify documents ceilings of 10,000 locations and 10,000 customers per company, with a maximum of 25 catalogues and 50 customers per location. Where Shopify stops is roles. There are exactly two permission levels for a location contact: ordering only, where "The customer can make purchases for the company location and review the list of orders that they have placed", and location admin, where they can also "review the list of orders that all customers have placed for that location". There is no spending limit, no view-only role, and no approver.

BigCommerce B2B Edition is built around company accounts with configurable user roles, described in BigCommerce’s own overview as tailoring "access control for Company buyers and backend staff", and it also models your side of the relationship by assigning sales agents as Super Admins and Sales Staff. That second half matters more than it sounds: it is what lets a rep act for a customer, which most platforms treat as an afterthought.

Shopware B2B Components goes furthest on structure. Employee management lets a business customer create employees who are "associated with a company customer and will act on behalf of that company", with roles that "define their permissions and settings", and permissions that "restrict or allow employees to perform certain actions, like ordering without approval or managing roles and employees". Shopware also ships an organization unit component for "more differentiated and specific access rights", and states that permissions "can be extended via app or via plugin".

Drupal Commerce has no company account model in core. As with quoting, that is the trade: you model the hierarchy you actually have, including the layers no product ships, and you pay for a development team to do it.

Separate two things that get called the same name, because the confusion costs projects real money.

Merchant-side review is you checking an order before you accept it. Shopify does this: a company location can be set so that, in Shopify’s words, "all orders for the company location are submitted as drafts". Every order from that location lands in your admin for someone on your team to look at.

Buyer-side approval is your customer’s own organisation approving a purchase before it reaches you. A junior buyer builds a cart, their manager approves it, and only then does it become an order. Shopify has no native mechanism for this. The clearest public statement of the confusion is a Shopify community thread from April 2026 asking for exactly this flow on the Grow plan. One reply asserted that native purchase order approval is "Plus-only via the B2B Companies feature"; a later reply in July 2026 corrected part of that, pointing out that the submit-orders-as-drafts option "is part of Shopify B2B company locations and isn’t limited to Plus". Both replies are talking about merchant-side review. Neither describes a manager inside the customer’s business approving their own colleague’s cart, because that does not exist on Shopify.

Shopware is the one platform of the four with a documented module for the buyer-side case. Its order approval component lets merchants "define rules that determine which orders require approval and which employees can approve them", and its employee permissions explicitly include "ordering without approval" as a permission you grant or withhold. Shopware’s documentation does not describe multi-level chains, so if you need two sequential approvers, treat that as unverified until you have seen it in a sandbox.

The practical read for most mid-market sellers: if a customer asks for internal approvals, ask whether they already have a procurement system. Large organisations with real approval chains usually run one, and the right answer is punchout into their controls rather than rebuilding their controls inside your storefront.

Your ERP already has an opinion about this, and the mapping is where the integration work concentrates. Acumatica has customers, customer locations and contacts. Shopify has companies, company locations and company contacts. They look like the same three levels and they do not behave identically, particularly around which level holds the tax status, which holds the payment terms, and which one an order is actually billed to.

The failure we see most often is not a missing feature, it is a person appearing twice. Bi-directional customer sync between an ERP and a storefront can create a buyer as both a contact under a company and a standalone customer record. The list then contains the same human in two shapes, which quietly breaks account-based pricing for whichever shape is wrong and makes any report on a company account unreliable. Ask your integrator directly which system creates a person, which system creates a company, and what the matching key is. If the answer is "email address", ask what happens when a buyer changes their email.

Decide these five mappings before implementation rather than during it: which ERP record is the company, which is the location, where the price class attaches, where credit and payment terms attach, and whether a person can belong to more than one location. Shopify handles that last case by prompting a buyer with access to several locations to choose which one they are purchasing for, and every price, term and address on the session follows that choice.

Write the answers down and put them in the request for proposal. A vendor who can answer all six in a demo is showing you the product; a vendor who answers them with "that can be configured" is showing you a services estimate they have not written yet.