How do you choose a wholesale ecommerce platform that handles price lists, credit limits and the ERP?

Sources checked on 13 November 2026.

This guide is for the person at a wholesaler or distributor who is choosing an online sales platform for business customers, or assessing whether the current store is still enough. It describes the features to check, the split of roles between the platform and the ERP, and questions for the vendor.

The short version: a B2C store with a login added will not handle prices negotiated with each customer, purchases by several employees of one company or orders on trade credit. Look for a platform that has these elements out of the box or lets you build them without working around its core.

In wholesale the customer is a company, not an individual. This leads to differences the platform has to handle:

• Prices: negotiated with a customer or customer group, and they may also depend on quantity.
• Buyers: several employees of one company with different permissions and limits.
• Payment: an order on invoice with payment terms and a credit limit.
• Orders: repeat, multi-line, placed by SKU.
• Integrations: the ERP on the wholesaler's side and sometimes a procurement system on the customer's side.

Each of these points changes the platform's data model: a customer stops being one account with one price. That is why a platform comparison should start with how it models a company, its employees and its trading terms.

A company account groups several buyers from one company. According to the Adobe Commerce B2B overview, the company administrator builds its structure (divisions, subdivisions, users) and assigns roles that control ordering, quoting and access to credit information.

In the same module, when Purchase Orders are activated, every company order is created as a Purchase Order (PO) and, depending on the employee's role and the order, can be subject to approval rules.

Medusa's core has no company account module. The Medusa B2B recipe describes customer groups, a B2B sales channel and price lists, recommends a custom module with data models such as Company and Employee for companies whose employees have different privileges, and points to a ready-to-use B2B starter.

Wholesale prices have several layers. The platform should allow each of them without manual calculation in a spreadsheet:

Tiered prices are built in on some platforms. The Medusa documentation on price tiers and rules describes the min_quantity and max_quantity fields: a price applies when the quantity of a variant in the cart falls within the range, for example $10 by default, $8 from 10 units and $6 from 20 units.

Before choosing a platform, decide where prices originate. If customer price lists are maintained in the ERP, the platform should import and update them, not keep a second, manually corrected copy.

If a buyer knows the product codes and regularly orders the same items, browsing a catalogue as in a B2C store slows their work down.

An example of a standard feature: quick order in Adobe Commerce lets the customer add products by SKU or name, paste many SKUs at once or upload a file with a product list using a downloaded template.

On top of that come purchase lists (in Adobe Commerce: requisition lists) and reordering a previous order. In a platform demo, ask to see a 50-line order placed from a file and count the clicks it takes.

A wholesale customer pays on invoice with payment terms, and the wholesaler monitors a credit limit. Adobe Commerce's B2B module has the Pay on Account method, a purchase on the company's credit line, with a limit set by the merchant.

A limit in the store alone is not enough if receivables and paid invoices live in the ERP. The platform has to know the customer's current balance and reserve the limit at order time, before the ERP posts the invoice.

We describe the limit reservation architecture, ERP integration and buyer messages in our guide to trade credit in B2B ecommerce.

If the ERP keeps customer records, price lists, stock levels, receivables and invoices, the ecommerce platform becomes a sales channel that has to read this data and send orders back. Before choosing, decide for each type of data which system owns it:

On that basis, ask the platform vendor about a ready connector for your ERP, about queuing orders when the ERP is unavailable, and about who maintains the integration after go-live.

If a customer buys through its own procurement system, the wholesaler may be asked for an integration instead of an ordinary store login.

The cXML standard describes documents exchanged between procurement applications, ecommerce hubs and suppliers: company details, catalogues, PunchOut, purchase orders and their changes, confirmations, ship notices and invoices. In it, PunchOut belongs to application integration, the connection between the customer's procurement system and the supplier's store.

If several key customers require PunchOut, put it in the requirements from the start. Adding this integration later may require changes in how the cart and orders are handled.

Platforms with a ready B2B module give a faster start if your processes fit their model. Extensible platforms such as Medusa need some features built, but let you model unusual rules. Whatever you choose, ask the vendor these questions:

Record the answers in one table for all compared platforms. A missing answer to the ERP question or to the cost of building a feature is information worth including in the decision.

1. Company model: how does the platform represent a company, its branches, employees and roles?
2. Prices: where do customer price lists originate and how do they reach the platform?
3. Credit: how does the platform check and reserve the credit limit at order time?
4. ERP: is there a connector for our ERP and what happens when the ERP does not respond?
5. Extension: which of our requirements must be built, and who maintains that code through platform upgrades?