The B2B ecommerce best practices that matter most are the ones that make the store behave like your sales team already does: the right buyer sees the right catalog at their contract price, orders go through the approvals their company requires, and stock and order status match what your ERP says. Get those three right and the design, search and speed work on top of them starts to pay off; get them wrong and no redesign will fix the phone calls.
This guide is for distributors, wholesalers and manufacturers who already sell online and keep hitting the same problems with pricing, quotes and back-office sync. It covers what to build, why it breaks, and how to check it, with examples from commerce backends we have built.
Where B2B buying differs from B2C
A consumer checkout assumes one person, buying for themselves, paying now with a card. Almost none of that holds for a trade buyer.
The buyer is usually one of several people at a customer account, and they may not be allowed to spend over a limit without sign-off. The price depends on who is asking, because it comes from a contract, a customer group or a negotiated quote. Payment often happens later, on a purchase order and credit terms. And the order is rarely a one-off, since the same buyer may reorder the same 40 lines every month.
That is why bolting B2B onto a B2C store usually means fighting the platform. Each section below covers one of those differences.
Accounts, roles and approval flows
Model the customer as a company first and a person second. A company account holds the contract, the price list, the credit terms and the shipping addresses. People sit inside it with roles.
Common roles look like this:
- Buyer: can build carts and submit orders, often up to a spending limit.
- Approver: reviews orders above that limit or outside the approved catalog.
- Account admin: adds and removes users, manages addresses and sees all orders.
- Viewer: checks order status and invoices without placing orders.
Approvals need their own order status. An order waiting for sign-off is not placed yet, so it should not reserve stock indefinitely or reach your ERP. Decide up front what happens when an approver rejects an order, edits it, or never responds. A pending order that sits for three weeks while prices change can easily turn into a dispute.
Keep a record of who approved what and when. When a customer's finance team asks why an order went through, you will want the answer in the system, not in someone's inbox.
Customer-specific catalogs and contract pricing
Most B2B pricing problems come from two systems that both think they own the price. The store has a price list, the ERP has a price list, and over time they drift. The buyer sees one number in the portal and a different one on the invoice.
Pick one owner for the price. If your ERP holds contract pricing, the store should ask the ERP (or a synced copy that the ERP updates) and show what it returns, rather than keeping its own rules. If the store owns pricing, the ERP should accept the store's price on the order. Either works; having both does not.
A few practices help:
- Catalog visibility by account. Some customers should not see some products at all, whether that is because of contract, region or regulation. Hide them in search and category pages too, and block direct product URLs.
- Explain the price. Show the buyer's contract price, and if there is a volume break, show the next tier. Buyers trust prices they can check.
- Test pricing against invoices. Pick a sample of accounts and products and compare the portal price with what the ERP would invoice. Run that check after every price-list change as well as at launch.
Product data and spec sheets
Before a trade order is approved, more than one person may check the product. An engineer checks the dimensions, and someone in compliance asks for the safety data sheet. When the product page cannot answer them, the buyer calls your sales team or buys from a seller whose page can.
A product page for B2B buyers usually carries:
- A specification table with units, such as dimensions, weight, materials and ratings.
- Spec sheets, safety data sheets, certificates and installation guides, each with a version or date.
- Pack size, minimum order quantity and lead time, shown next to the price.
- The codes buyers search for, such as your SKU, the manufacturer part number and cross-references to equivalent parts.
Specifications work best as structured attributes, with one field per spec. A size field can drive filters, comparison views and site search, while the same size typed into a description can only be read. Shopify, for example, stores custom product data in metafields. Its own examples include product dimensions, hazards and a size chart. If you run a PIM, it should own these fields, as the record-ownership table further down shows.
Product codes need one clear model, because buyers search with codes from different sources. A GTIN (Global Trade Item Number) is issued through GS1 and stays the same whichever company sells the product. A SKU is the code your business creates for its own stock, so two sellers can list the same GTIN under different SKUs. Manufacturer part numbers and a customer's own part numbers sit alongside both. When all of them map to one product record, a search on any of them finds the same item.
GS1 US sets two rules that shape a B2B catalog. The first is that each variation of a product, such as a new size or a new pack, needs its own GTIN. The second identifies a case apart from the single unit inside it, so selling by the each and by the case takes a separate code and price for each unit of measure. GS1 uses the GTIN-14 for trade item groupings such as a case, and that code is not meant for point-of-sale scanning. With one code per unit of measure, the cart, the invoice and the warehouse count the same thing. A GTIN can be as short as 8 digits or as long as 14, and storing it as text keeps any leading zeros.
Documents need the same care as prices. An outdated spec sheet can lead a buyer to approve the wrong part, so every product change should include a check of the files attached to the page.
Quote-to-order and purchase orders
Many B2B sales still start with a request for quote, not a cart. Large orders, custom configurations and new accounts often need a person to set the price. Treat that as its own workflow rather than a contact form.
A workable quote-to-order flow has a few clear steps:
- The buyer builds a cart and requests a quote instead of checking out.
- A sales rep, or a pricing rule, sets prices, discounts and any minimum order quantities.
- Internal approval releases the quote if it falls outside normal margins.
- The buyer receives the quote with an expiry date and accepts it in the portal.
- The accepted quote becomes the order, carrying the agreed prices and terms through unchanged.
Step 5 is where most homegrown quote tools fail. If the accepted quote is retyped into a new order, or the order recalculates prices from the current price list, the buyer gets a different total from the one they agreed to. The order should reference the quote and keep its prices.
Purchase orders need similar care. Let the buyer enter their PO number at checkout and carry it to the invoice, because their accounts-payable team will match on it. If you offer credit terms, check the account's available credit before you accept the order, and decide what happens when an order would push the account over its limit: block it, send it for approval, or accept it and flag it to your credit team.
Payment terms and methods: net 30/60, ACH and wire
Trade buyers often pay on account, after delivery, instead of paying by card at checkout. Net 30 and net 60 give the buyer 30 or 60 days to pay, and the detail to settle first is the day that count begins. Shopify B2B, for example, offers six fixed net terms of 7, 15, 30, 45, 60 or 90 days. Due on fulfillment is also an option, as is a fixed date on draft orders. Shopify starts every net term on the day the order is placed. If your ERP counts from the invoice date instead, the portal and the invoice will show different due dates. Both systems should follow one rule.
Terms sit with the credit limit, because both are credit decisions. In Adobe Commerce B2B, the merchant sets each company's credit limit, and the company buys against it through payment on account when that is enabled. On Shopify, a deposit taken at checkout as part payment is a Shopify Plus feature. Whatever the platform, terms and limits should not be a store setting that anyone with admin access can change.
The invoice also carries the terms, the due date and the remittance details. Payment then arrives outside the store, often after the goods have shipped, and usually by one of two routes:
- ACH. Nacha says the ACH Network reaches every US bank and credit union account. The network settles payments four times a day on business days, while the Federal Reserve settlement service is open. Same Day ACH has a separate limit of $1 million per payment, rising to $10 million on September 17, 2027. That limit is worth checking against your largest invoices before you tell buyers a payment will clear the same day.
- Wire. The Fedwire Funds Service is a wire transfer service run by the Federal Reserve Banks. It is a real-time gross settlement system, and a transfer is immediate, final and irrevocable once it is processed. The service is generally used for large-value, time-critical payments.
Each payment should be recorded against the invoices it settles. That matching usually happens in the ERP or the accounting system, and the account portal then shows the new balance. Card payments from smaller accounts can run alongside terms. The two paths should stay apart in reporting, so an unpaid invoice never appears as money received.
Self-service account portal: invoices, order status and registration
Many of the calls a trade customer makes to sales or support are lookups. They want to know where an order is, whether an invoice was paid or when a backordered line will ship. A self-service account portal gives them those answers from the same data your team would look up in the ERP.
The main B2B platforms ship part of this. Shopify B2B customer accounts show order history and company location details. Buyers can pay with saved payment methods, reorder by copying a past order and track return requests. The app listing for BigCommerce B2B Edition describes an invoice portal. Customers filter invoices by status and date, and they can pay several at once, in full or in part. The listing names card, ACH and purchase order among the accepted ways to pay. Adobe Commerce groups the buyers from one company under a company account, where the company admin sets up divisions and roles. On Shopify, the B2B features you get depend on your plan.
A portal that cuts those calls covers four areas:
- Order status by line, including partial shipments and tracking numbers.
- Invoices and credit notes, with the open balance and due dates, downloadable as PDF.
- Quotes, with their status and expiry date.
- Account details, such as users and roles, shipping addresses, saved payment methods and the account's payment terms.
Buyers should see their terms and permissions but not be able to change them. Shopify B2B works this way, and it also lets a buyer pay an order placed on terms before the invoice is due.
A platform portal shows what the platform stores. When invoices, credit notes and backorder dates live in your ERP, most of the work is the integration that brings them into the portal. Each figure should come from the system that owns it, as set out in the ownership table in the ERP section. When a figure arrives through a sync, the portal should show when it was last updated. A buyer who paid an invoice this morning and still sees it as open will call, and the timestamp tells them why.
New accounts need their own registration process. A new trade customer may have to pass a credit check or show that they are a business before they see contract prices. The applicant submits company details online, the application goes to the person who approves it, and the applicant can see where it stands. An application that sits unanswered for days can send the buyer to another supplier. Once approved, the account should open with the right price list, roles and credit terms already in place.
Order stages and replaceable rules
As soon as you add approvals, quotes, partial shipments and credit checks, an order can be in many more states than "paid" and "shipped". The practice that keeps this manageable is to define those states explicitly and to put the checks on the transitions between them.
In one commerce backend we built, the order was controlled by an order state machine. The rules for payment eligibility, basket merging and stock allocation sat behind it as replaceable strategies, so the client could swap one out without rewriting the rest. Transition guards checked the order against its customer and contents, and confirmed that shipping and stock were in place, before it could move on. When a transition was refused for an expected reason, the API returned a named result that the storefront could explain to the shopper, instead of a generic error.
Two details from that project apply to most B2B stores:
- Put the checks at the transition. If validation lives in the storefront, a second storefront, a sales-rep tool or an integration can push the order forward without doing the work. Checks on the transition apply to every caller.
- Plan for the awkward case. A payment provider call cannot sit inside a database transaction, so a charge can succeed while the save that records it fails. That project kept the two steps apart and left a clear mismatch for staff to reconcile. It also handled a stock shortfall on an order that was already paid by emitting an event that staff had to act on.
You can read the configurable commerce, payments and inventory workflows case study for the full picture.
Partial fulfilment matters just as much in B2B, where one order often ships in several pieces. In a separate ecommerce checkout, inventory and fulfilment build, each order line tracked how much was ordered, invoiced, shipped, and refunded or cancelled. That let staff settle part of an order without closing the whole purchase, which is exactly what a buyer with a backordered line needs.
Multichannel: pricing and warehouse allocation per channel
Many B2B sellers run more than one channel: a trade portal, a consumer store, marketplaces, and a sales-rep app. Each one tends to need its own prices, currency and fulfilment rules.
In the multichannel commerce and order management backend we built, each channel set its own prices and currency, its own warehouse preferences and its own order rules, while all storefronts shared one API. Inventory kept three separate records: warehouse stock, short-lived reservations taken during checkout, and allocations to orders. An allocation promised the units; only a fulfilment reduced the physical count.
That three-way split is worth copying. If your system cannot tell "on the shelf" from "promised to an order" from "held in someone's cart for ten minutes", it will either oversell or show stock as unavailable when it is not.
The same project separated asking a payment provider to capture money from learning that the provider had captured it. For B2B sellers who authorise a card and capture on shipment, that distinction stops your system reporting money it has not received. The same split matters if you later move order handling into a dedicated multichannel order management system.
ERP, WMS and inventory sync
Your store, ERP, warehouse management system (WMS) and any marketplaces each hold a view of orders and stock. Integration work is mostly about deciding which view wins and what happens when a sync fails.
Start with a record-ownership table before anyone writes code:
| Record | Usual owner | What the store does |
|---|---|---|
| Contract and list prices | ERP | Reads and displays; does not edit |
| Customer account, credit limit | ERP or CRM | Reads; may create new accounts for approval |
| Product content | PIM or the store | Reads from PIM if you have one |
| Available stock | WMS or ERP | Reads, then rechecks at checkout |
| Order (once placed) | ERP | Creates it, then reads status back |
| Shipment and tracking | WMS or carrier | Reads and shows to the buyer |
Your answers may differ. What matters is that each row has one owner and everyone agrees.
Then plan for failure. Every integration call will fail sometimes, so decide what retries, what waits in a queue, and what alerts a person. Make order creation safe to repeat, so a retry does not create a duplicate order in the ERP. Monitor the sync itself; a failed job that nobody notices is how a store ends up selling stock the warehouse does not have.
Stock shown on a product page is usually a cached or indexed figure, and that is fine for browsing. In the checkout, inventory and fulfilment build mentioned above, the storefront showed an indexed availability figure, then re-read the authoritative stock rows under a database lock at checkout. That is a good default: fast pages, accurate orders.
If you also sell in physical locations, the same ownership questions apply to the till. Our guide on how to integrate a POS with your online store covers that case.
Reorder, search and bulk ordering
Trade buyers often know exactly what they want. The fastest store for them is the one that gets out of the way.
- Reorder from history. Let buyers open a past order and add all or some lines to the cart, at today's contract price.
- Saved lists. Many accounts reorder the same set of products. Let them save and share lists within their company.
- Quick order by SKU. A form where buyers type or paste SKUs and quantities saves them clicking through categories. CSV upload helps for large orders.
- Search that knows part numbers. Index your SKUs, manufacturer part numbers and the customer's own part numbers if you store them. Exact matches should come first.
- Unit and pack sizes. Make it obvious whether the price is per each, per box or per case, and enforce minimums and multiples in the cart instead of at invoicing.
These features also matter for B2B ecommerce website design: a dense, scannable order form often serves a trade buyer better than large product imagery.
B2B site search for part numbers and specifications
Buyers type part numbers the way they appear on their own paperwork, so the same code arrives with and without dashes or spaces, and sometimes without its leading zeros. The index and the query should strip those characters in the same way, which lets both forms match. If your warehouse scans barcodes, indexing the GTIN as well lets a buyer search the number printed on the box.
Trade buyers also search by attribute and by the terms their own industry uses, and B2B site search has to cover those as well:
- Filters run on the structured spec fields from the product data, such as size, material or rating.
- Synonyms cover the names buyers use, including older product names and the competitor part numbers you have cross-referenced.
- The account's catalog rules apply to results, autocomplete and filter counts, so a restricted product does not show up in any of them.
- Results show pack sizes and order rules. Shopify B2B, for example, can require orders in lots of 10 and set a minimum and a maximum per product or variant. A buyer who sees the rule in the results does not hit it as an error in the cart.
Search and quick order should share one index. Adobe Commerce B2B Quick Order lets a logged-in buyer who knows the product name or SKU order it in a few clicks. Whatever the platform, a code that works in the search box should also work in the quick order form. Both should return the same contract price.
Searches that return no results are worth a regular review. They point to products you do not stock, codes you have not indexed and words you have not mapped yet.
Performance and accessibility (WCAG 2.2 AA)
Speed matters on large catalogs and on long order forms. Google's Core Web Vitals give you measurable targets: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, each measured at the 75th percentile of page loads. Test the pages your buyers use most, such as category pages with many filters, the quick-order form and the cart with 100 lines, not just the home page.
For accessibility, WCAG 2.2 became a W3C Recommendation in October 2023, and Level AA is a common testing baseline. A few of its newer success criteria line up closely with B2B ordering:
- 3.3.7 Redundant Entry (Level A): information a user already entered in a process should be auto-filled or available to select. Think repeated shipping addresses and PO details.
- 2.5.8 Target Size (Minimum) (Level AA): pointer targets should be at least 24 by 24 CSS pixels, or have enough spacing. Small quantity steppers in long tables often fail this.
- 3.3.8 Accessible Authentication (Minimum) (Level AA): login should not depend on a cognitive test unless there is an alternative or assistance.
- 2.4.11 Focus Not Obscured (Minimum) (Level AA): a focused element should not be fully hidden by things like sticky cart bars.
Automated scanners catch some of these, but not all. Pair them with manual keyboard and screen-reader checks on the order flow. Testing against a standard is not the same as claiming conformance, so keep those two statements separate in your documentation.
Platform, headless or custom: when each fits
Most B2B practices above can be delivered on a standard platform, a headless setup, or custom code. The choice depends on how far your pricing, account and fulfilment rules sit from what the platform does out of the box.
In short: a standard platform fits one team running one store with fairly ordinary rules. Headless fits when the same catalog feeds several channels, brands or regions. Custom work fits when your pricing, accounts or fulfilment logic fight the platform at every upgrade, and even then it usually means building the parts that carry those rules, not the whole store. Our comparison of standard, headless and custom ecommerce platforms explains each option in more detail.
B2B ecommerce best practices checklist
Use this to review your current store or to brief a vendor.
| Practice | What to build | How to check it |
|---|---|---|
| Company accounts and roles | Accounts with buyer, approver, admin and viewer roles | Log in as each role and try an action it should not allow |
| Approval flows | A pending-approval order status with spend limits | Submit an over-limit order; confirm it does not reach the ERP until approved |
| Contract pricing | One price owner; store reads from it | Compare portal prices with ERP invoice prices for sample accounts |
| Catalog visibility | Per-account product rules in listings, search and URLs | Search for a hidden product as a restricted account |
| Product data | Structured spec fields, versioned spec sheets, a GTIN for each variant and unit of measure, part-number cross-references | Open a product as a buyer, find its current spec sheet, and search for it by GTIN, SKU and manufacturer part number |
| Quote-to-order | Quote workflow with expiry; accepted quote becomes the order | Accept a quote after a price-list change; the order keeps quoted prices |
| POs and credit terms | PO field carried to invoice; credit check before acceptance | Place an order that exceeds available credit |
| Payment terms | Net terms held with the credit limit; one rule for when terms start; ACH and wire payments matched to invoices | Place an order on net 30 and compare the due date in the portal, on the invoice and in the ERP |
| Self-service portal | Order status by line, invoices with online payment, quotes, account users, sync timestamps | Pay part of an invoice and compare the portal balance with the ERP |
| Registration | Online application routed to an approver | Submit a test application and confirm the approved account opens with the right price list |
| Order states | Explicit states with checks on each transition | Try to move an order forward from a second client, such as an API call |
| Partial fulfilment | Per-line ordered, invoiced, shipped, refunded quantities | Ship part of an order and refund one line |
| Inventory | Separate on-hand, reserved and allocated stock; recheck at checkout | Two buyers order the last unit at once |
| Integration failure | Record ownership table, safe retries, alerts | Take the ERP offline in staging and place orders |
| Reorder and bulk ordering | Order history reorder, saved lists, quick order by SKU, CSV upload | Time a 50-line reorder |
| Site search | Part-number variants, spec filters, synonyms, catalog rules, one index shared with quick order | Search a part number with and without dashes while logged in as a restricted account |
| Performance | Core Web Vitals budgets on key page types | Measure LCP, INP and CLS on category, quick order and large cart |
| Accessibility | WCAG 2.2 AA as a testing baseline | Automated scan plus manual keyboard and screen-reader pass |
FAQ
What are the most important B2B ecommerce best practices?
Customer-specific pricing that matches the invoice, approval flows that fit the buyer's company, and reliable sync with your ERP and warehouse. Most other improvements depend on those working.
How is B2B ecommerce website design different from B2C?
B2B buyers often know what they want and order in volume, so quick-order forms, saved lists, reorder from history and part-number search usually matter more than lifestyle imagery.
Should the ERP or the store own pricing?
Whichever one your finance team trusts for invoicing. Usually that is the ERP. The important part is that only one system owns it.
Do I need a custom platform for B2B ecommerce?
Not usually. Many stores can extend a standard platform. Custom work makes sense when pricing, account or fulfilment rules keep breaking at upgrades.
How do I handle quotes in a B2B store?
Build quote-to-order as its own workflow: request, pricing, internal approval, buyer acceptance, and conversion to an order that keeps the quoted prices.
If your store is struggling with pricing, quotes or ERP sync, our B2B ecommerce development services page covers what we build, and our work for software for retail and commerce teams shows the wider context. When you want a number, you can get a range for your B2B store.
