B2B commerce is not B2C with a discount attached.

The buyer is not the customer

This single difference explains nearly all the others. In retail, the person browsing, the person paying and the person receiving are usually the same. In business-to-business, they are often three different people inside an organization that is itself the actual customer.

The consequences land immediately. Price depends on the company's contract, not on who is signed in. The right to order depends on a role, and sometimes on a spending limit. Order history has to be visible to colleagues, not only to whoever clicked. And when someone changes employer, all of those rights disappear overnight.

Platforms that take B2B seriously model this explicitly. Shopify's B2B documentation is built around the company object, with its locations, contacts and payment terms. Adobe Commerce offers company accounts, requisition lists, shared catalogues and quote requests. These are not decorative options — they mark where the real complexity sits.

Four objects you cannot work around

When a B2B project goes sideways, it is almost always on one of these four, and almost always because it was treated as a variation on a consumer mechanism.

The last row is the one projects underestimate most. A B2B order is often not a transaction but a request: approved by a manager, attached to a purchase order, invoiced thirty days later. The checkout does not end in a payment. It ends in an approval.

The percentage discount trap

Faced with negotiated prices, the most common workaround is to keep a single public price and apply a percentage per account. It is quick to implement and it works for roughly a year.

Then the exceptions arrive, and they always arrive. One customer has fixed pricing on three SKUs and a percentage on everything else. Another negotiated a rate valid until a specific date. A third gets different pricing by quantity, with a tier that matches no standard pack size. Each exception becomes a rule coded somewhere, and nobody can answer the simple question any more: why is this customer seeing this price?

A B2B price list is not a promotion. It is a contractual commitment, and it has to be explainable line by line.

So the question to settle early is straightforward: is price a commerce concern, or a contract concern owned elsewhere — in the ERP, typically? Both answers are defensible. What is not defensible is letting two systems each hold half of the truth.

What should actually drive the platform decision

The usual criterion is volume: order counts, SKU counts, traffic peaks. For a business-to-business operation that criterion rarely discriminates — volumes are often modest next to retail, with far larger baskets.

The useful criterion is how many distinct contractual rules the platform will have to carry, and how long they live. A handful of questions gets you there.

1. How many genuinely different price lists exist today, and who maintains them?
2. Can a customer see a restricted catalogue, and does that restriction come from the contract or from logistics?
3. Can an order require internal approval on the customer side, and under what rules?
4. Are payment terms and purchase orders requirements, or exceptions?
5. Which system is authoritative for price: the commerce platform or the ERP?

An organization answering "a handful, stable, managed in the ERP" does not need a dedicated B2B platform. An organization answering "several dozen, renegotiated yearly, kept in a spreadsheet" has a pricing governance problem before it has a platform problem — and no commerce project will solve that on its behalf.

That is the least expected conclusion of this kind of work: the hard part is almost never the storefront. It is the accumulation of rules the organization has built up customer by customer, which selling online forces it, for the first time, to write down.