Customer-specific pricing for contractors starts in your ERP

Every general platform caps customer-specific pricing somewhere, and the cap is usually the number of price lists, the unit a price can attach to, or the plan you must be on.

Shopify extended B2B to its Basic, Grow and Advanced plans on April 2, 2026, with "up to 3 active catalogs across all your B2B markets." A catalog is Shopify's price list. Unlimited catalogs, and assigning a catalog directly to a company or a company location, stay on Shopify Plus, which Shopify's help center lists from US$2,500 a month on a one-year term. Even on Plus, "each company location can have a maximum of 25 catalogs assigned to it," and a store can hold 10,000 catalogs in total.

BigCommerce takes the other route. Its price lists need a Performance plan, and BigCommerce says "there is no limit to the number of price lists you can have." But each customer group and storefront pair gets one price list at a time, and B2B Edition companies get their prices through a customer group, not directly. Price changes can take "up to 10 minutes" to reach the storefront.

WooCommerce core has no B2B pricing; it comes from plugins. B2BKing offers per-customer price lists, and for very large lists it recommends an optimized storage mode. In that mode, customer prices no longer show in WooCommerce REST API responses or the product exporter, which is exactly where an ERP sync would look for them.

NetSuite, the ERP, is the most generous on paper: "You can set up to 1,000 price levels," and Oracle advises against creating more than 1,000 pricing groups.

The finding: a yard with more than three negotiated price sheets outgrows Shopify's non-Plus plans, and the platforms without a hard cap move the risk into how the price gets there.

Map each pricing layer your ERP uses to one place in the store, before anyone builds anything. A yard can run several layers at once, and the store has to know which one wins.

NetSuite's documentation is the clearest public example of what those layers look like. A customer record has a default Price Level. Item Pricing on the same record sets a price level for a single item. Pricing groups set a level for a group of items. Oracle's rule: "The price level for a pricing group overrides the customer's price level, but not item pricing." A customer with no price level gets the base price. Expect your ERP to have the same shape under different names.

Contractor accounts add one more wrinkle: the account is a company, but the people ordering are a foreman, a purchasing lead and an owner. The price belongs to the company. Every login under it must see the same number.

In ToolSwift, customers are grouped, and each group decides both which products an account sees and which pricing applies, so contractors and retail customers each get a catalog meant for them. One company account holds several individual logins, each with its own role. The customers page covers groups and credit; the products page covers catalogs and tiers.

The finding: every layer needs a home, and the last row is the one that decides whether your online pricing is limited to what your ERP can express.

Quantity breaks belong on the product page, where the contractor can see that 200 studs cost less each than 20, and you have to decide in writing which rule wins when a break and a contract price both apply.

This is where platforms quietly differ. Shopify allows up to 10 price breaks per product, and once a volume price applies it is fixed: the catalog's overall percentage adjustment no longer applies. On BigCommerce, if a variant has a price record on a price list, product-level bulk pricing does not apply to it in the cart. NetSuite needs Quantity Pricing switched on as a separate feature, with an optional setting for different quantity discounts per price level.

None of those rules is wrong. Each is a precedence decision someone made for you. If your contract says a framer gets level 3 pricing plus the bundle break on full units, and the platform drops one when the other applies, the contractor sees a number your counter would never quote.

A contractor's price has to be the same in the portal, the app, a quote and at the counter. If it changes depending on where he asks, he will call to check every time, and you have paid for a portal nobody trusts.

Quotes break first, because a quote is usually built by a person. At many yards, a contractor sends a materials list, someone inside turns it into SKUs, and that person has to remember the account's price sheet.

On ToolSwift, the Takeoff Agent turns a contractor's voice note, photo, scan, takeoff or file into a draft quote for staff review, matching the items against your catalog with that account's pricing applied. When the quote is approved it converts into an order with the same line items, pricing and customer account, with nothing re-entered. AI quote drafts through the Claude and ChatGPT connector are coming. The contractor's account, pricing and credit are the same whether he buys at the counter, on the app or on the phone with your inside sales rep, and checkout enforces his credit limit automatically.

The counter is where Shopify drops the contractor's price. Shopify's help center says "company-specific prices for B2B markets aren't available for retail purchases," which means a contractor's negotiated prices don't follow him to a Shopify POS sale. I covered the rest of that gap in my Shopify B2B comparison.

Test the pricing with real accounts and real items before a single contractor gets a login.

What goes wrong is almost never the base price. It is the overlap. Shopify shows the lowest price when several catalogs price the same product differently, so an account that sits in two catalogs gets the better of the two whether you meant it or not. Fixed prices in a Shopify catalog override any overall percentage adjustment. BigCommerce drops product bulk pricing for variants with a price record. In NetSuite's Advanced Pricing, customer-specific price rules come first, then customer item pricing, group pricing and the customer's price level, then rules for all customers, then the item's base price. Every platform has an order. You need to know yours and test it.

Here is the test plan I would hand a yard before go-live. Pick six accounts from your ERP that each exercise one rule, log in as each, and compare the screen to what your counter would charge.

Run the price-change test twice: once for an item on a contract and once for an item that is not. DCKAP's best practices say the same in general terms: validate before go-live, retry failed updates with alerts, keep audit logs, and test contract pricing and quantity breaks. The six rows below are that advice made specific to a yard.

You need it online if more than a handful of your contractor accounts buy at a price other than your shelf price. If everyone pays the same price, a group discount is enough, and a per-account setup is overhead.

The yards that need it most are the ones with negotiated sheets for framers and builders, quantity pricing on units of lumber and sheet goods, and contractors who order from a truck before the counter opens. Those contractors will trust the portal only when the number on the screen matches the number on their invoice, every time.

The yards that should wait are the ones whose ERP cannot yet say clearly which price an account gets. Putting an unclear price online makes it unclear in more places.

My decision rule: if your negotiated prices live in your ERP, choose a store that reads them from the ERP and applies them per account and per quantity, and walk away from any setup that asks you to upload a second price list. If your ERP cannot express a rule you sell on, the store has to hold that one rule itself, and only that one.