BEAM

Seedlight BEAM: our framework for launching, automating and growing eCommerce platforms →

← B2B ecommerce: moving wholesale sales online

Chapter 3 of 6

Pricing and trading terms: the decisions before the build

The scope of your first release needs commercial substance before anyone starts building. Who sees a price and when, whether stock levels are public, how trade credit and order blocking work, what your minimums and units are, which currencies you sell in, and when a quote has to replace a list price. Every decision comes with a consequence for your sales rep and for the system.

8 min read

Key points

  • Every commercial decision has two consequences: it changes what your sales rep does daily, and it determines what has to be configured in the system. Skip the decision and the default setting of your chosen tool makes it for you.
  • Price and stock visibility is really a decision about how much work stays with your sales reps. Price on request across the whole catalog hands them back exactly the orders the platform was meant to take away.
  • Trade credit without an agreed blocking variant, a named person who can lift the block, and a response time will stop a regular customer at the worst possible moment.
  • Not every price fits a price list. Decide explicitly which situations follow the quoting path, so the platform never pretends to know a price it does not know.

The scope of your first release is settled: you know which processes go into the platform and which stay outside it for now. That scope now needs commercial substance, and it needs it before anyone starts building. This chapter is not about price list mechanics. Rule layers, the order in which they resolve, and versioning we covered separately in the piece on B2B contract pricing. What matters here are the decisions an owner has to make earlier, because each one has two consequences: it changes the daily work of a sales rep, and it sets what has to be configured in the system.

Who sees a price, and at what point

The first decision is about visibility, and it has three variants, all of them common in wholesale. A public price list shows the same figures to every visitor and effectively rules out differentiated terms. Prices after login open the catalog to everyone but reveal figures only to verified trade customers, and in wholesale that is the default. Price on request shows no figure to anyone until a sales rep gets in touch. You can mix these: part of the assortment with public prices, the rest behind login.

The consequences run both ways. Prices after login mean somebody has to verify and approve new accounts, and that task usually lands with a sales rep, along with the question of how fast it has to be done. On the system side you need registration with approval, a link between the account and the customer record, and a catalog that works properly without prices, because that is how a prospect sees it before logging in and how search engines see it too. Price on request applied to the entire assortment hands back to your sales team exactly the work the platform was supposed to remove: processing small, repetitive orders. Keep it where it is genuinely needed instead of making it the default.

Does everyone see availability

Stock visibility is a separate decision from price, so decide it separately. You can show an exact unit count, a general status ("in stock", "low stock", "made to order"), availability only after login, or nothing at all. An exact count shortens the conversation about whether goods are there, but it also reveals the size of your warehouse to anyone who will use that in a negotiation, competitors and dealers included. A general status is commercially safer, yet on larger orders it still ends in a phone call. The system consequence matters more than it looks: the more precise the number you display, the more often you have to refresh it and the more an error costs. The decision you make here comes back to you as an invoice in the next chapter.

Payment terms and credit limits

In wholesale, payment is rarely up front, so the platform has to handle deferred terms. Three things need settling. Who gets deferred payment: every verified trade customer, only those with purchase history, or case by case. Where the platform reads the limit and the balance from: it has to be the same ledger your finance team uses, not a separate table inside the store, because two independent versions of a balance will diverge within the first month. And what happens once the limit is exceeded, which is the decision most often left unspoken until the day it blocks a regular customer.

There are several blocking variants and they differ in commercial impact. A hard block prevents the order from being placed. A warning informs but lets the customer continue. Accept-and-hold records the order and stops it before goods are released. Restricting payment methods lets ordering continue, but on prepayment only. That last variant is usually the most sensible starting point, because it does not stop the sale, it changes its terms. Whichever you pick, you need an answer to who can lift the block and how quickly, otherwise the procedure collapses into a phone call to the owner.

Blocking on an exceeded credit limit is a finance decision with an immediate sales effect. Before you switch it on, settle three things: what exactly is blocked (placing the order, releasing the goods, or only the deferred payment option), who can lift it and within what time, and what the customer sees. A message saying "this order cannot be placed" with no reason and no named contact guarantees a call to the sales rep and a bad day on both sides.

Order minimums, units and case packs

A minimum order value or quantity is a logistics tool in B2B, not a marketing one: the point is that picking and shipping make cost sense. The decision is whether the minimum is one figure for everyone or varies by customer group and channel. For a sales rep it means the end of manually merging micro-orders, but also conversations with customers who fall short of the threshold. For the system it means the minimum has to be a parameter of the customer terms rather than a constant in the configuration, because the first contract with an exception to the rule will appear within a month.

Free shipping thresholds travel from retail to wholesale worse than expected. A single value rarely works, because transport cost depends on weight, dimensions, pallet count and region, and two orders of the same value can be a parcel and a half pallet. A sensible first release keeps one value threshold for typical orders plus individual freight pricing for the unusual ones, flagged clearly in the cart. The third decision in this group is the selling unit: if the product ships in cases of twelve, you have to settle whether a customer can buy seven. Answering "no" is easier in the warehouse, but it requires a unit conversion in the system, rounding up to a full case, and a message explaining why seven became twelve. The unit shown on the platform must be the unit that appears on the invoice, or your first complaint will be about exactly that.

Currencies and selling abroad

Multi-currency starts with a binary decision: does the first release handle export sales, or do they stay in email and quotes for now. If they are in, you are adding a separate currency price list or a conversion rule, and with it the immediate question of which rate, from which day, applies to an order. Then come the consequences that are easy to forget at the planning stage: EU VAT number validation and different tax rates, documents and the language of support, delivery terms, and the cost of taking goods back from another country. For a sales rep it means a second price grid to watch. For the system it means the currency is an attribute of the customer agreement and of the document, not a switch in the footer. If exports are a few percent of turnover today, an honest "not in the first release" is defensible, but it has to be a decision rather than an oversight.

The table below collects the decisions from this chapter. Read it row by row: if a column is blank for you, the decision has not been made yet, only postponed.

DecisionWhat it means for the sales repWhat it means for the system
Prices visible only after loginVerifies and approves new accounts within an agreed response timeRegistration with approval, account linked to the customer record, catalog that works without prices
Exact stock levels for logged-in customersFewer "is it in stock" questions, more complaints when the number driftsMore frequent stock refresh and a choice between physical stock and available to sell
Deferred payment with a credit limitNeeds to know who lifts a block and how quicklyAccess to balances and overdue invoices, not just the limit amount
Logistics minimum per orderFewer micro-orders to merge by hand, more conversations about the thresholdMinimum as a customer terms parameter plus a clear message in the cart
Selling in case packs onlyStops correcting quantities after the customerUnit conversion, rounding up, consistency with the unit on the invoice
Selling in a second currencyA second price grid to maintain and different delivery termsCurrency as a customer and document attribute, a rate rule, EU VAT handling

The pattern across the whole table: a commercial decision always has a counterpart in human work and in system configuration.

When you need a quote instead of a list price

Not every transaction fits a price list, and the platform should not pretend otherwise. The typical cases that need quoting are configurable or non-standard products, volumes beyond your agreed thresholds, non-standard freight, a project or tender with a deadline, and a new customer with no agreed terms yet. The decision is which of these follow the quoting path and which can be handled by a rule in the price list. For the customer it means sending an enquiry instead of filling a cart. For the sales rep it means a task with a response deadline instead of another email in the inbox. For the system it means a quote status and an expiry date, so nobody orders at a price agreed six months ago.

The second, less obvious decision is what happens after acceptance. An accepted quote can apply once, to that order only, or it can create a time-limited customer term that also applies to subsequent purchases. The first variant is simpler; the second reflects how wholesale actually works and is the one that removes the repetitive re-keying of the same arrangements from your sales team. How we set this process up in practice is described under B2B pricing and quotes.

Write the decisions down before you pick a tool

None of the decisions in this chapter belongs to IT or to your platform vendor. Collect them in one document and record the reasoning next to each, because a year from now nobody will reconstruct it from memory. Some of them will trigger an internal conflict: finance will want prepayment and hard blocks, sales will want flexibility and exceptions, logistics will want high minimums. That conflict is better resolved on paper than in a system configuration a week before launch. Nearly every one of these decisions also assumes the platform knows the current customer price, the stock level and the outstanding balance, and it holds none of that data itself. Where it gets that data, how often, and what happens when the source goes quiet is the subject of the next chapter.

Questions

Will hiding prices behind a login hurt your store visibility in search?

Category and product pages can still be indexed when figures are shown only to logged-in trade customers, provided the catalog works without prices and is not entirely locked behind a login. The real cost is different: a prospect cannot compare your offer before registering, and some enquiries land with a sales rep instead of in a cart. A middle path is a public list price or a price range on part of the assortment, with individual terms available after login. Neither variant guarantees rankings or traffic.

Does a B2B platform have to support trade credit from day one?

It does not. A first release can run on prepayment and proforma invoices for new customers and offer deferred terms only to those who already have an approved limit in your finance system. There is one condition: the platform must know the current balance and any overdue invoices. Without that, the block is calculated late, which is worse than no block at all because it creates the illusion of control.

What if some customers buy single units and others only full case packs?

Treat the selling unit as part of the customer trading terms rather than a global catalog setting. Set a default variant (usually the case pack) and name the groups allowed to order single units. The critical part is that the unit shown in the cart is the unit that reaches the sales document, together with its conversion factor. A mismatch between them ends in credit notes and disputes on delivery.

All chapters in this guide

B2B ecommerce: moving wholesale sales online

  1. 01When wholesale outgrows emailThe signals that selling through reps, inboxes and spreadsheets has stopped scaling, what a B2B platform actually changes and what it will never change. The B2B versus B2C differences that decide feasibility, plus an honest caveat: software will not tidy your price lists or your data for you.
  2. 02What to build first: scope of your first releaseSix things a first B2B store release has to have, and four areas worth deliberately postponing. The scoping rule: your first release handles the most common order from your best customer end to end, not every possible case. Plus how to pick the first group of customers to go live with.
  3. 03 · You are herePricing and trading terms: the decisions before the build
  4. 04ERP integration: what to connect in the first releaseThe commercial decisions are written down, but the platform knows neither the customer price, nor the stock level, nor the outstanding balance. What has to be synchronised from day one and what can wait, who owns each type of data, how often to sync and what that costs, what to do when your ERP has no API, and how to plan for the day the integration breaks.
  5. 05Onboarding customers and sales repsThe most common reason a B2B rollout fails is not technical: the platform works correctly and nobody uses it. How to bring customers onto the platform (who goes first, what has to be ready in their account, what a first login looks like) and how to set the rules for your sales team so the platform becomes their tool rather than a threat.
  6. 06Launch and growthA B2B platform rollout does not end on launch day. How to start with a pilot on a narrow group and widen from there, what to measure in the first weeks, how to read low adoption (usually friction rather than reluctance), what to build second, and how to maintain the platform so it does not feel a year old after twelve months.