Wholesale ecommerce platform: the trade rules each one has to handle

When a wholesale ecommerce platform actually replaces email orders

A sales rep is fixing prices in a spreadsheet late at night because the B2C store cannot express case packs and net terms. The buyer sent a PDF order by email hours ago. The rep is cross-referencing it against a price list that lives in the ERP, a discount agreed on a phone call last quarter, and a credit note that finance has not yet applied. This is what a wholesale ecommerce platform is supposed to replace: a system that lets trade buyers place orders themselves under their agreed rules, such as contract pricing, minimum order quantities and payment terms, instead of emailing PDFs and waiting for someone to key them in.

For a wholesale business, the order is rarely the hard part. The hard part is that each order carries rules: wholesale pricing agreed per account, bulk orders in fixed case sizes, and purchase orders paid on account. A B2B ecommerce portal earns its place only when it applies those rules without a sales rep checking every line.

This article compares five platforms, Shopify Plus B2B, BigCommerce B2B Edition, Adobe Commerce B2B, commercetools and Medusa, across the trade rules that matter in wholesale operations: customer-specific pricing, minimum order quantities, quotes, net payment terms, company accounts, quick ordering, ERP integration, and tax and multi-currency support. Catalogue pages look much the same on every platform. The differences sit in how each one handles those rules.

KVY builds B2B ecommerce and the ERP and accounting integration behind it. The aim here is to map trade rules to platform capabilities, with each capability linked to the vendor’s own documentation, so the comparison can be checked rather than taken on trust. That matters when you are trying to replace manual order handling without breaking pricing accuracy, credit control or buyer trust.

What makes a wholesale ecommerce platform different from a retail store?

A normal DTC checkout collects a card payment from one person buying one item at one price. A wholesale order involves case packs, buyer roles, purchase orders and net 30 on account. Those details change how the whole system is built.

Wholesale ecommerce is online ordering between businesses at contracted prices, usually on credit, and often repeated. Retail e commerce sells individual products to consumers at a public price. The difference in buyer and order shape drives every design decision underneath.

Why wholesale buyers need different tools

Wholesale buyers order on behalf of a company. They expect their own pricing, a catalogue that shows only the products in their contract, and payment on account rather than by card at checkout. A wholesale ecommerce platform has to recognise who the buyer works for before it can show a single price, which is why customer data such as company, location and buyer role sits at the centre of the design.

The core trade rules that decide whether a platform can replace email and phone orders are:

• Customer-specific price lists and catalogues
• Minimum order quantities and case packs
• Quotes and RFQ (request for quotation)
• Net payment terms and credit limits
• Company accounts, buyer roles and approvals
• Quick order and reorder tools
• ERP and inventory sync
• Tax and multi-currency

Most e commerce platforms can show products. Fewer can represent these rules without custom development, and the ones that can do it in different places: some in the product, some in marketplace apps, some in code you write and own.

One engineering detail is worth stating early. Mixing B2C promotions and B2B price lists in one pricing engine is where many builds start to creak. A summer sale discount that stacks on a contracted wholesale price quietly eats the margin on that account.

Rule 1: Customer-specific price lists and catalogues

Wholesale distributors and manufacturers rarely have one public price. They run tiers, contracts and sometimes hidden SKUs per account. A buyer who orders large volumes every month sees a different price from one who orders occasionally, and some accounts see products that others do not.

In practice this means tiered pricing by volume, bulk discounts for agreed order sizes, and account specific pricing for contracts. Each wholesale account may also have its own pricing that overrides the standard tiers.

Shared catalogues and custom catalogs

There are two common patterns: shared catalogues with price-list overrides per customer segment, and account-only custom catalogs where whole product ranges are gated. The second pattern is often called customer specific catalogs. Both multiply the data that must stay synchronised with the system that owns prices.

That system is usually the ERP or a pricing engine. The ecommerce platform consumes the data and presents it. Problems start when the portal begins owning prices instead of reading them, because then two systems claim to be the source of truth and neither knows about the other’s changes.

Our B2B ecommerce development work usually starts by finding out where the truth for price actually lives.

How the five platforms handle customer-specific pricing

• Shopify Plus B2B sets custom prices through catalogs assigned to company locations. More complex pricing logic, such as cost-plus formulas or contract escalators, is outside what that page describes, so it ends up in apps or custom code.
• BigCommerce B2B Edition includes price lists as part of the B2B Edition, and BigCommerce price lists apply per customer group and channel.
• Adobe Commerce B2B uses custom shared catalogs with custom pricing assigned to company accounts. The depth is significant, and so is the configuration surface.
• commercetools handles this in its API through Standalone Prices and price selection by customer group and channel. The implementation team still has to design how accounts map to groups.
• Medusa provides price lists per customer group in its Pricing Module, and its B2B recipe uses one customer group per company.

A common failure mode: someone adds a discount field in the portal for one client, and over time it becomes a second, unsynchronised price list that nobody audits.

Rule 2: MOQ and case packs

A minimum order quantity (MOQ) is the smallest number of units a buyer can order for a given SKU. A case pack is the increment: glass bottles that must ship by the carton, for example. These rules may vary by product, by customer or by channel, and they should be enforced in the cart, not explained in a footnote.

For a deeper breakdown of how to model these rules, see the dedicated article on minimum order quantities.

The data usually comes from the ERP item master or trade terms tables. Duplicating MOQ data in the ecommerce database is risky because it creates a second place to update when carton sizes change, and someone always forgets. Volume price tiers also need to line up with MOQ and case-pack constraints, or buyers see a price break they are not allowed to order. Bulk purchasing rules belong next to the stock and inventory management data that the ERP already holds.

One pattern that causes trouble is free-text order notes used to carry carton rules. If the rule is in a text field, the system cannot check it or report on it.

MOQ and case pack support by platform

• Shopify Plus B2B supports quantity rules with a minimum, maximum and increment per variant, which covers products boxed in fixed multiples.
• BigCommerce B2B Edition has bulk price tiers in its price lists, but that is pricing rather than an order minimum. We could not find an official BigCommerce page documenting minimum or maximum purchase quantities, so this article does not classify that capability.
• Adobe Commerce B2B offers per-product “Minimum Qty Allowed in Shopping Cart” and “Qty Increments” settings.
• commercetools has no official page we could find that documents MOQ or increment enforcement, so it is listed as not documented.
• Medusa uses min_quantity in its price rules to select a price tier, which is not the same as blocking a cart below a minimum. Cart-level MOQ and case-pack enforcement is custom code.

Rule 3: Quotes and RFQ

An RFQ is a request for quotation: the buyer drafts a basket, requests a quote, someone reviews it internally, a quote is sent, and if accepted it converts to an order. The lifecycle matters because it sits between browsing and buying, and handling it badly usually pushes buyers back to email even when the rest of the portal works. For a deeper breakdown, see the article on quote-to-order flows.

Sectors differ. Commodity buyers expect instant, auto-priced quotes. Project-based orders need the sales team involved. The quote stage is often where custom pricing and payment terms are first negotiated, so it touches rules 1 and 4 as well.

One engineering detail: storing quotes and orders in separate tables without a stable link makes reporting on conversion almost impossible later. If you cannot trace a quote to the order it became, your sales cycle data is incomplete.

How platforms implement quotes and RFQ

• Shopify Plus B2B builds B2B orders as draft orders with company pricing and terms, which is a merchant-led flow. We found no official page for a buyer-initiated RFQ, so a buyer self-serve quote request is not documented.
• BigCommerce B2B Edition includes Sales Staff Quoting, and its B2B Edition settings control Request for Quote for guests, individuals and company users.
• Adobe Commerce B2B supports quote negotiation initiated by a company buyer or a sales rep.
• commercetools exposes a negotiation flow through its Quote Requests API and the related Staged Quotes and Quotes resources. The workflow UI is the implementer’s responsibility.
• Medusa documents quotes as something you build: its quote management guide notes the default application has only standard cart and order features. A quote flow also ships in the official B2B starter, as code you own.

Rule 4: Net payment terms and credit limits

Net terms mean the buyer has an agreed period to pay after invoicing; net 30 means 30 days. Credit limits cap how much an account can owe at any time. A buyer close to their limit should not be able to place a large order without someone reviewing the exposure.

There are three checkpoints: at order creation (is credit available?), at release or fulfilment (has the credit position changed?), and at periodic account review when terms change. Purchase orders are common in wholesale, and they are the usual way buyers draw on credit terms. For the full credit-modelling detail, see the article on net payment terms.

The truth about exposure should live in the ERP or credit system. The ecommerce platform must read from it, not maintain a parallel ledger. If two systems each think they know the credit position, neither does.

Checking credit only at one late point is a common gap. By the time it fails, the buyer has already been promised delivery, and holding the order back damages trust.

Net terms and credit handling by platform

Card payments are the easy part, and payment processing for cards works in much the same way on every platform. The platforms vary much more on flexible payment terms and credit on account, which is how most trade customers actually pay. Credit lines and flexible payment options also have to agree with what finance holds in the ERP.

• Shopify Plus B2B supports payment terms of net 7, 15, 30, 45, 60 or 90, due on fulfilment, a fixed date, and deposits. We found no official Shopify page for credit limits, so credit-limit enforcement is not documented here.
• BigCommerce B2B Edition documents company payment terms in net days and company credit settings, and its buyer functions cover available credit, limited purchases and credit hold.
• Adobe Commerce B2B offers Payment on Account up to a company credit limit, enabled among the basic B2B features.
• commercetools has no official page we could find for payment terms or credit limits, so this cell is not documented.
• Medusa has employee spending limits in the official B2B starter, but we found no Medusa documentation for net terms or credit limits, so this cell is not documented.

Rule 5: Company accounts, buyer roles and approvals

A realistic corporate account might include a procurement manager who sets up the account, store managers at several locations who place orders, and a finance approver who signs off anything above a threshold. They need shared access under one company, not one shared email login. In practice, that usually means a wholesale account managed across users, not a single buyer record.

Common capabilities are parent company accounts, child locations, and corporate accounts that reflect the real buying hierarchy with role-based permissions, spending limits and approval workflows. Shared purchase history and the ability for staff to act as a buyer to troubleshoot still matter. These rules intersect with quotes, net terms and catalogue visibility, so they have to be designed together.

It is simpler to configure one approval rule in one place than to retrofit exceptions in three different services later. Every exception added to an approval chain is a future support ticket. Approval processes are easiest to support when the business can explain them in one sentence per role.

Account hierarchies and approval workflows by platform

• Shopify Plus B2B models companies with locations and “Ordering only” or “Location admin” permissions. Merchant-side review is possible with the “Submit all orders as drafts for review” setting; buyer-side approval workflows are not documented.
• BigCommerce B2B Edition provides company accounts with hierarchy and buyer roles, including custom roles. Its API documentation mentions shopping-list approval, but a purchase approval workflow is not documented.
• Adobe Commerce B2B supports company roles and permissions and purchase order approval rules by value or role.
• commercetools models hierarchies through Business Units and Associates, with Associate Roles and permissions and Approval Rules and Approval Flows in the API.
• Medusa treats this as code: the B2B recipe builds a custom company module, and the official B2B starter adds company management and company and merchant approvals. We cover how that fits together in Medusa’s B2B module.

Rule 6: Quick order and reorder

Trade buyers often know SKUs by heart. They want speed, not browsing. The portal should reduce clicks for common tasks: repeat purchases, bulk orders and restocking standard lines.

Common patterns are quick order by SKU, CSV upload, reorder from purchase history, saved lists and multi-location carts. Buyers who place the same order every week get the most out of these. When buyers log in, they should see their last orders and saved lists first, which gives them a self service experience for routine restocking.

The back-office effect is real: fewer manual re-keys from emailed spreadsheets, cleaner order lines and less time the sales team spends on data entry. But CSV upload is only useful when errors are surfaced line by line and can be fixed, not just “file rejected, please try again”.

Buyer productivity features across platforms

• Shopify Plus B2B lists “Easy reorders” through customer accounts among its B2B features, and quick order lists are available in Trade and free themes from version 11.0, or through theme code.
• BigCommerce B2B Edition includes a Quick Order Pad (by SKU, CSV or previous orders), shared shopping lists and Buy Again.
• Adobe Commerce B2B supports Quick Order by SKU or CSV and requisition lists for frequently ordered products.
• commercetools provides a Shopping Lists API for repeat lists. A quick-order interface is not described there, so the front end is yours to build.
• Medusa has bulk add-to-cart in the official B2B starter only, which makes it starter code you own rather than a core feature.

Rule 7: ERP and inventory sync

A wholesale ecommerce platform is rarely the system of record for stock, prices or invoices. Treating the commerce platform as the source of truth when the ERP already holds that data is an architectural mistake that shows up later as reconciliation work.

Key integrations include the ERP (orders, inventory, pricing), accounting (invoices, payments), a warehouse or 3PL (fulfilment events), and sometimes PIM or CRM systems. Wholesale ordering depends on ERP integration, even when it is built in a later phase.

Order management and inventory management

Order management covers what happens after the buyer submits: credit checks, allocation, fulfilment and invoicing. Inventory management covers what stock is available to promise. In most wholesale operations both live in the ERP or warehouse system, and the ecommerce platform reads from them rather than keeping its own copy.

Architectural patterns range from direct point-to-point integration (simplest to start, hardest to maintain), to middleware or iPaaS (adds a coordination layer), to event-driven services (most flexible, highest engineering cost). The right pattern depends on order volume, the number of systems and the team that will run it.

Syncing stock on a timed job is acceptable for low-volume retail. In high-frequency wholesale ordering it causes overselling, because several large orders can land between two sync runs against the same stale stock figure.

Integration approaches by platform

Each platform has a preferred integration style, and it should match the systems already in place.

• Shopify Plus B2B says you can integrate your ERP or other systems using B2B APIs, or use third-party B2B apps. Either way the sync logic is something you build or buy.
• BigCommerce B2B Edition has an ERP category on its official app marketplace and B2B REST and GraphQL APIs for custom work.
• Adobe Commerce B2B publishes guidance on SAP ERP integration that uses middleware for catalogue, inventory, pricing and order sync, which is integration code rather than a built-in connector.
• commercetools lets you build and deploy integrations with Connect, alongside its Inventory API.
• Medusa has an ERP recipe describing how to build the integration, and a native Inventory Module for stock inside the platform.

Rule 8: Tax and multi-currency

Cross-border wholesale adds VAT and GST rules, multiple currencies, tax exemptions, and pricing and settlement in more than one currency. These are not display features. They affect invoices, margins and compliance.

Common requirements are tax-exempt trade customers, registration numbers on the account, invoices with the correct tax breakdown, pricing in the buyer’s currency with settlement in the base currency, and reverse charge VAT where it applies. Currency handling needs consistent rounding rules between systems.

This ties back to the ERP: tax codes and exchange rates must match between systems. A tax plugin on its own is rarely enough when the business spans several jurisdictions.

Rounding differences between ERP and ecommerce price calculations cause reconciliation disputes at invoice time. A small difference per line multiplied across a long order is exactly the kind of discrepancy finance will query.

Tax and currency capabilities by platform

• Shopify Plus B2B stores tax IDs and exemptions per company location, and Shopify Markets handle currency and taxes by market.
• BigCommerce B2B Edition supports multiple transactional currencies, and its price lists can be set per currency and used with tax-exempt customer groups.
• Adobe Commerce B2B provides tax configuration, including a customer tax class per shared catalogue, and multiple currencies.
• commercetools offers Tax Categories with country and state rates, and carts carry a currency.
• Medusa has a Tax Module with per-region rates, rules and tax providers and multi-currency prices in core.

Wholesale ecommerce platform comparison: how each handles the rules

The sections above cover each rule in detail. The table summarises it so it can be skimmed in a meeting or attached to a decision document. Each cell links to the official page that backs it.

Each cell is “Native”, “App/extension” or “Custom code”. “Native” does not mean no effort; it means the feature exists in the product or its B2B edition. “Custom code” is not automatically bad; it means you own the implementation, which brings control and maintenance responsibility. “App/extension” usually means another vendor to manage, with its own support terms and update cycle. “Not documented” means we found no official page that backs a classification, which is not the same as saying the feature is missing.

Rule-by-platform capability table

Rule	Shopify Plus B2B	BigCommerce B2B Edition	Adobe Commerce B2B	commercetools	Medusa
Customer-specific price lists	Native	Native	Native	Native	Native
MOQ and case packs	Native	Not documented	Native	Not documented	Custom code
Quotes and RFQ	Native (merchant-led draft orders; buyer RFQ not documented)	Native	Native	Native	Custom code
Net payment terms and credit limits	Native (terms; credit limits not documented)	Native	Native	Not documented	Not documented
Company accounts, buyer roles and approvals	Native (buyer-side approvals not documented)	Native (purchase approvals not documented)	Native	Native	Custom code
Quick order and reorder	Native	Native	Native	Native (API; front end is custom)	Custom code
ERP and inventory sync	Custom code (B2B APIs or third-party apps)	App/extension	Custom code	Custom code	Custom code
Tax and multi-currency	Native	Native	Native	Native	Native

The cells describe capability, not cost. Integration work, app subscriptions and hosting all sit on top of the licence, whichever label a cell carries.

Licence, hosting and pricing

• Shopify Plus B2B is proprietary SaaS hosted by Shopify, with Shopify Plus starting at $2,300 USD/month, on a one-year or three-year term.
• BigCommerce B2B Edition is proprietary SaaS hosted by BigCommerce and is its Enterprise B2B offering, priced on request according to the BigCommerce pricing page.
• Adobe Commerce B2B is a proprietary extension enabled in Adobe Commerce. It can run on-premises or on Adobe Commerce as a Cloud Service on Adobe-managed SaaS infrastructure, and it is priced on request.
• commercetools is proprietary, API-first SaaS hosted by commercetools, with integrations hosted through Connect, and its pricing page lists it as priced on request.
• Medusa is open source under the MIT License, except Enterprise Edition materials. It can be self-hosted or run on Medusa Cloud, whose pricing tiers are Develop from $29/mo, Launch from $99/mo, Scale from $299/mo and Enterprise at custom pricing.

Where wholesale ecommerce builds break in production

Most breaks are not about missing features. They come from misaligned truth between the ERP and the commerce platform, or from rules that nobody owns after the people who configured them move on.

Common failure modes

Price list drift against the ERP. Portal prices get updated by one team. ERP prices get updated by finance. There is no reconciliation process, no scheduled comparison job and no alert when the two diverge. Account managers end up explaining invoices instead of selling, and buyers stop trusting the prices they see.

Approval rules nobody owns. Rule trees grow over time. Nobody is sure which still apply, so operations staff bypass the portal and accept emailed PDFs again, which puts the business back on manual order processing across email, spreadsheets and phone calls. Approval rules work best when they are few, written down and owned by a named role.

Credit limits checked too late. The limit is checked only at fulfilment. Orders already promised to buyers have to be held back, which damages trust and slows the sales cycle. A credit check at order submission and again before release catches the problem before the order has been promised.

Quick order tools that do not match how buyers think. Search works by marketing name, but buyers type internal SKUs or their own part codes. If the quick order pad does not accept those, buyers go back to sending spreadsheets for sales reps to retype. Alternative SKU mappings have to be imported, not assumed.

Integrations treated as one-off scripts. Price and stock sync scripts without monitoring fail silently, and the failure is found days later during a manual check. Meanwhile buyers see wrong prices, stock is oversold and the wholesale platform they rely on stops feeling trustworthy. Observability for integrations matters as much as for the storefront.

One pattern causes quiet damage: a nightly price import overwriting negotiated quote prices in the portal. The buyer agreed a price yesterday, the import replaced it overnight, and the order ships at a different margin. Nobody notices until the next margin review.

The trade-offs between wholesale ecommerce software options

Asking for the best wholesale ecommerce platform usually turns into a question of where complexity sits and who maintains it. The trade-offs below describe that, rule by rule, without ranking the platforms.

• Hosted SaaS vs control. Shopify Plus and BigCommerce are vendor-hosted, so there is no infrastructure to run. When rules go beyond what the product documents, such as unusual discount logic or credit checks, the extra logic moves into apps or middleware that sit outside the vendor’s product.
• Native features vs code you own. Native features are maintained by the vendor and usually easier to support, but they bend only as far as their settings allow. Custom code can express every nuance, but the team that writes it also carries its maintenance and its bugs.
• Suite depth vs integration freedom. Adobe Commerce B2B puts many trade rules in one product, with the configuration surface that comes with that. commercetools and Medusa expose building blocks through APIs and modules, which gives freedom in how integrations are shaped and puts more of the design work on the implementation team.
• Licence cost vs engineering cost. A licence front-loads cost. Custom code moves cost into engineering time and maintenance. Neither is lower in the abstract. The total cost depends on how many trade rules need custom work, how many third party apps the build relies on, and how often the rules change.

How these trade-offs show up in real projects

A SaaS B2B module can get buyers onto a portal quickly when the initial trade rules fit its settings. The trade-off appears later, when rules that do not fit start moving into ERP integrations and apps, and the logic ends up spread across several systems.

An API-first stack such as commercetools or Medusa means the team owns every rule and can change it without waiting on a vendor roadmap. The trade-off is more design and build work up front, and a standing need for engineers who understand the code.

A suite such as Adobe Commerce B2B keeps more rules inside one product and reduces the number of separate apps. The trade-off is ongoing work on configuration, extension upgrades and, for self-hosted installs, hosting and performance tuning.

In every case the deciding question is where the trade logic for B2B wholesale ecommerce will live and who will own it, because that decides how the platform for wholesale copes with business growth and a rising order volume.

Frequently asked questions

Which e-commerce platform is best for wholesale?

No single platform is best for every wholesale business. Shopify Plus B2B, BigCommerce B2B Edition, Adobe Commerce B2B, commercetools and Medusa all cover customer-specific price lists, but they differ on MOQ enforcement, quotes, credit limits and approvals, as the table above shows. The better fit is the one whose native features match your trade rules, with the rest built as code you are willing to own.

What software do wholesalers use?

Most wholesalers run an ERP for orders, stock, prices and invoices, with accounting and a warehouse or 3PL system alongside it. An ecommerce platform for wholesale sits in front of those systems so buyers can place orders themselves. Some also use PIM or CRM systems, which the platform has to integrate with.

Are B2B and wholesale the same?

Wholesale is one kind of B2B ecommerce. B2B covers any sale between businesses, including services and one-off projects, while wholesale usually means repeated orders of physical goods at contracted prices, often on credit.

What is a B2B wholesale company?

It is a business that sells goods to other businesses, such as retailers, distributors or manufacturers, rather than to consumers. Its orders typically carry account-specific prices, minimum order quantities, purchase orders and net payment terms.

What is the cheapest wholesale website?

Licence prices differ in structure. Shopify Plus starts at $2,300 USD/month, BigCommerce, Adobe Commerce and commercetools are priced on request, and Medusa is open source under the MIT License with paid Medusa Cloud tiers. The licence is only part of the total cost, because integration work, apps and hosting sit on top of it.

A wholesale platform in daily use

A Malaysian paint manufacturer has run its orders, stock and production on a system KVY built and has operated since January 2025. Customer price groups are resolved per item and per unit of measure, which is the customer price list rule above applied to every order line. Stock reservations are kept as their own records, so the same stock is never promised to two orders. The system syncs to QNE Cloud accounting with Malaysian e-invoice fields, so the ERP and inventory sync rule holds without staff re-keying orders.

If you are weighing this for your own business, start with a plan. In two to three weeks we map how the system would connect to your ERP, warehouse, payments and sales channels, set out the build in phases with the cost to run it over three years, and give a fixed quote for the first phase. You keep the plan whatever you decide.