Native B2B on Shopify Plus is built from a few primitives: companies and their locations, catalogs that decide what each location can buy, price lists that set what it pays, and quantity rules that shape how it orders. Each release fills in more of that model. The question for wholesale merchants is always the same: is the native model now good enough to retire the custom pricing logic we built around its gaps?
what keeps changing in catalogs and price lists?
Shopify extends catalogs and price lists release by release, and the B2B section of the changelog is the place to read the specifics of each one. We don’t restate them here, because they move. The direction has been consistent: more of what wholesale teams configure by hand, or with custom code, can live in Shopify’s own B2B objects and be managed in the admin.
That makes the useful question not “what shipped this time” but “does my pricing now fit the native model”. The rest of this entry is how to answer it.
who it touches
- Wholesale stores that run pricing through a custom app, a script, or customer-tag logic in the theme.
- Stores that keep a separate wholesale storefront or expansion store only because pricing could not be expressed natively.
- ERP-integrated merchants whose price lists are mastered outside Shopify and pushed in on a schedule.
- Sales teams that manage company accounts, payment terms and ordering rules by hand.
should you migrate off custom pricing logic yet?
Migrate if your pricing is a set of lists per customer group, with quantity breaks and simple rules. That maps cleanly onto catalogs and price lists, and moving it out of custom code removes something you maintain.
Wait if your pricing depends on logic the native model does not express: contract prices negotiated per SKU and per period, prices computed from live cost data, rules that combine many customer attributes at once. Forcing that into price lists tends to produce more lists than anyone can audit. Keep the custom layer, or move the computation into a Shopify Function and keep catalogs for assortment.
If your ERP is the source of truth for price, the integration matters more than the feature. Native price lists are only better if the sync that fills them is reliable and observable.
what we’d do
- Write your pricing rules down in plain language. If you cannot, that is the first problem.
- Map each rule to a native object: catalog, price list, quantity rule, volume price, payment terms. Mark the ones that do not map.
- Prototype on a dev store with a realistic copy of companies, locations and price lists, including your biggest account.
- Compare prices line by line between the current system and the native model for a sample of real past orders.
- Migrate in cohorts. Move a group of accounts, watch a full ordering cycle, then move the next.
checklist
- Pricing rules are written out and owned by someone.
- Each rule is mapped to a native B2B object, or marked as custom.
- The ERP price sync is reviewed for reliability and monitoring.
- Prices are compared line by line on past orders.
- There is a cohort migration plan with a rollback.
impact
Worth knowing. Nothing is forced. For simple tiered wholesale, it is a reason to retire custom code. For contract pricing, not yet.