Wholesale pricing: price lists, minimums and payment terms

Wholesale breaks retail software in a specific way. Retail has one price per thing. Wholesale has a price per thing per buyer, a floor on how few of that thing a buyer may order and a buyer who does not pay at the till. Most tools solve one of those three and leave you doing the other two in a spreadsheet you email out quarterly.

The idea: a tag is a price list

There is no separate "price list" object to create and then assign to customers. A price list is a customer tag you have declared eligible for wholesale pricing.

The wholesale settings hold a list of columns, each a tag name plus a default. Tag a customer cafe, and the moment cafe is one of those columns, that customer prices against it. Untag them and they price at retail. Nothing to keep in sync, because the membership list and the price list are the same list.

The consequence, and the part merchants find confusing: you move a buyer between price lists by changing their tags. Tags are the assignment. Matching is case-insensitive, so a ladder authored against Cafe still applies to a customer tagged cafe.

What a column charges

Each column has a default: a percentage off your retail price. It applies to every product in the wholesale catalog with nothing more specific attached.

More specific means a ladder, set per product per tag: quantity breaks, each with a minimum quantity and either a percentage off or a flat price. Buy twelve, pay this. Buy forty-eight, pay less.

Pricing one line: the buyer gets the best rung their quantity qualifies for, and where none applies, the column's default percentage off retail does.

Two behaviours that catch people out:

A flat-price rung ignores the product's own price entirely. On a product with a size range that means every size costs the same, because the rung returns its value outright rather than discounting a base. Sometimes exactly what you want, sometimes a nasty surprise, so the price list view flags it where it occurs.

A buyer carrying two eligible tags gets the cheaper of the two. Tags are a floor, not a stack: two discounts never add together.

The price list you read as a merchant always matches what checkout charges, so the sheet cannot drift from the till. It prices at a quantity of one deliberately, so a row backed by a ladder starting at twelve shows the column default and reports separately where the ladder starts.

Margin mode prices from cost

A column's default can instead be a target margin against each product's own cost. That sets a fixed price per product, capped so a wholesale buyer never pays more than a retail walk-in.

The trade-off: a margin column only covers products it has actually baked a price for. A product added later, or one with no recorded cost, falls through to the column's default. Either way your costs stay yours.

Minimums, and where they actually live

A minimum order quantity is a property of the product, not of the price list: one minimum applies to every list at once. The per-list quantity is the ladder break, answering a different question. The break says "this gets cheaper from here", the minimum says "you cannot order fewer than this".

A per-variant override is the only way to vary a minimum, and it can only create or change one, never remove it. Where a product is sold by weight the minimum falls back to the product's own smallest sellable quantity, so a legitimate half-kilogram (about one pound) order is not blocked by a phantom minimum of one whole unit.

At checkout the gate groups cart lines by product and variant, and each variant meets its own minimum standing alone. Six of one size plus six of another does not add up to twelve. The same grouping picks the ladder rung, so the quantity that earns a discount and the quantity that clears the minimum are always the same number.

For one minimum everywhere there is a bulk stamp. It clears per-variant overrides as it goes and tells you how many before it writes, because leaving them behind means the screen and the till disagreeing.

One column per type, or one per account

Because a column is only a tag, nothing stops you having as many as you can keep straight. The two ends of that choice pull against each other, and it is worth deciding deliberately rather than discovering which one you have.

A column per account type is the readable version. cafe, restaurant, reseller: three or four columns, a default on each, ladders only where a flat percentage will not do. Pricing a new stockist is typing one tag. The cost is that every account of a type gets the same deal, so the buyer who negotiated something different has nowhere to live except an exception you will forget.

A column per account holds every negotiation exactly as agreed, and it does not scale. A ladder is per product per tag, so twenty accounts with real ladders is twenty ladders to author for each product, and twenty to re-read every time your ingredient costs move. That is the version that quietly stops being maintained, which is the same failure as the quarterly spreadsheet you left behind.

The model lets you have both, and the reason is the stacking rule above: a buyer holding two eligible tags is priced on both and charged the lower of the two. So put everybody on a type column, then give the few accounts with their own terms a personal tag as well. The type column is the floor and the personal column only ever improves on it. The consequence to plan around is that this works in one direction only: a personal column cannot charge an account more than its type column, so a premium tier has to be built as a lower type default that the personal column does not beat, never as a surcharge.

Minimums do not follow the same shape, and that is the trap. A minimum belongs to the product, so there is exactly one of it no matter how many columns you run, and a per-variant override is the only way to vary it. Where your account types genuinely need different floors, express that as a ladder that makes the small order unattractive rather than as a minimum that blocks it.

Pay on invoice

A trade buyer who has to enter a card at checkout is a trade buyer who will ask you to email an invoice instead.

Net terms are a property of a payment method. Create one, enable terms on it, set how many days after the order the money is due and optionally restrict it to particular tags so only trade customers see it. Any method with terms enabled is wholesale-only regardless of tags, because a tag alone is not proof of trade: a retail customer can carry the same one.

Placing an order on terms mints a real order with no charge. The whole total becomes a single scheduled payment due the configured number of days after the order date, anchored on your business's calendar day. It behaves like every other payment plan, so it appears in the dashboard, the overdue reporting and the portal like any other.

The payment record is created as pending verification, always. Net terms means the money has not arrived, whatever else the method is configured to do. If the method auto-confirms, that advances the order into production and reserves stock. It says nothing about the money, and the payment sits waiting for you to confirm it landed. Nothing here marks an invoice paid without you.

Getting a buyer in

Trade buyers do not use your public storefront and have no password. They enter their email on the wholesale sign-in, get a six-digit code and are in. Eligibility is decided by whether the customer record for that address carries one of your configured tags.

Wholesale is a Business-plan feature. If a plan lapses it reads as off everywhere at once, with the stored configuration kept intact.

Setting it up

Turn on wholesale, add a column per price list with its default, tag the customers in each, set minimums, add a terms payment method if your buyers pay on invoice and add ladders where a flat percentage is not good enough.

Do the ladders last and slowly. Everything else is configuration you do once. A ladder is a commercial decision per product per account type, and the price list view exists so you can read back what you committed to before a buyer does.