Four price lists is configuration. Four hundred is operations. Every tutorial on Shopify B2B catalogs walks through the same demo: create a catalog, attach a price list, assign a company, done in ten minutes. The wholesale operators asking about this in community threads are past that stage, and their question is different: the setup made sense at launch, so why does managing it feel like a second job two years later? This is a post about the second job, the part of catalog management that starts after the tutorial ends.
Quick answer: A Shopify B2B catalog is two objects wearing one name: a publication that decides which products an account can see, and a price list that decides what those products cost, both assigned to company locations. At scale, the design rule is to stop building one full catalog per account and decompose instead: pricing-only catalogs for each pricing truth, publication-only catalogs for each assortment, stacked on the same location. Shopify's own documentation runs the math at fifty pricing tiers and ten assortments: sixty catalogs instead of five hundred. The rest is discipline, a naming convention, an owner, a provisioning runbook, and a drift audit, because at four hundred price lists nobody notices the broken one until an account does. For which pricing model belongs inside each list, tiered, volume, or fixed, the Shopify B2B pricing guide owns that decision; this post is about running the lists once the models are chosen.
What a Catalog Is Actually Made Of
The anatomy matters because each part fails differently. Shopify's B2B catalog documentation describes the merchant-facing object: products plus prices, assigned to companies. Underneath, the platform stores a publication, a price list, and the assignment connecting them to company locations, and the developer documentation is blunt about what happens when the parts separate.
A catalog with no publication shows a logged-in buyer an empty store, no products at all for that location. A catalog with no price list quietly serves initial variant prices converted to the market currency, which for a wholesale account means retail numbers with no warning. And a price list moved to a new catalog leaves its old catalog behind as a publishing-only shell serving default prices, which is documented behavior in Shopify's catalog management guide, not a bug. Debugging a scaled catalog program means knowing which of the three parts is missing, because the storefront symptom, wrong prices or missing products, never says which one it was.
The Segmentation Decision Nobody Makes Deliberately
Catalog sprawl is rarely designed. It accretes: launch with three tier catalogs, add a catalog for the first negotiated account, another for the next, a promotional catalog that outlives its promotion, and within two years the count is in the hundreds with nobody able to say which accounts depend on which. The fix is a decision most programs never make explicitly: how many pricing truths does this business actually have, and how many assortment truths, counted separately.
Counted separately, because the naive architecture multiplies them. One full catalog per account means every catalog carries its own product publication and its own price list, even though most accounts share an assortment and many share pricing. Shopify's two-catalog pattern splits the objects instead: pricing-only catalogs, one per distinct pricing truth, and publication-only catalogs, one per assortment, with each company location assigned one of each. The documented example is a merchant with fifty pricing tiers and ten product assortments: sixty catalogs under the split pattern against five hundred as full catalogs, an order of magnitude less surface to maintain.
The pricing truths then sort into shared and negotiated. Tier pricing, the distributor rate, the dealer rate, the strategic rate, lives on shared lists that hundreds of accounts point at, so one update reaches everyone on the tier. Per-account lists are reserved for genuinely negotiated pricing, where a specific customer's contract sets specific numbers per SKU. The discipline is refusing per-account lists to accounts whose pricing is really just a tier with a name on it, because every unnecessary list is permanent audit surface.
What Breaks at 400 Price Lists
The admin stops being the tool first. Editing prices by hand or uploading the occasional CSV works at boutique scale; at hundreds of lists, price maintenance is an API workload with documented physics. The fixed-price mutation accepts 250 prices per request and behaves as add-and-replace, so refreshing one 12,000-SKU account list is 48 sequential requests that must all succeed, and a contract-wide update across dozens of such lists is a batch job with retry logic, not a task. Programs that reach this scale without automation are running that batch job as a human, which is where the backlog and the errors both come from.
Orphan drift breaks next, and silently. Reassign a price list, and the abandoned catalog serves default prices to whatever accounts still point at it. Replace a catalog's publication, and the old publication persists in the system unless explicitly deleted, both failure modes documented with warnings in Shopify's own guide. At four catalogs, someone notices the same week. At four hundred, the orphan serves wrong prices until a buyer mentions it, and the mention goes to a rep, and the rep assumes it is a one-off.
Overlap is the third break, and it is a design consequence of the split pattern itself: a location holding multiple pricing catalogs receives the lowest applicable price per product. That rule is what makes stacked catalogs predictable, and it is also how a leftover promotional list undercuts a base tier without any error appearing anywhere. The pricing guide linked above treats the margin-leak mechanics in full; at scale the operational point is that assignment changes need review precisely because the system will always resolve overlaps without complaint.
And underneath all three sits the mundane one: at four hundred lists, a catalog named "Copy of Wholesale 2024 FINAL" is a small liability with compound interest. Names that encode tier, region, and source, an owner who approves assignments, and a provisioning runbook for new accounts, which tier list, which publication, which ERP record backs it, are what make the difference between an inventory and an archeology site.
The Roster Lives in the ERP
For operations with negotiated pricing, the customer-to-price relationship already exists somewhere authoritative: the ERP's price books and contract records. The scaled catalog program treats Shopify's lists as mirrors of those records, per account, refreshed on contract changes, with the ERP as the roster deciding which account belongs on which list. That keeps the four-hundred-list estate auditable against a single source instead of being its own truth, and it is the sync work Uncap Connect runs in both directions, price books to lists, at exactly the request-batching scale the admin was never built for.
The Content Layer Catches Up Last
Publications decide which products each segment can see. They do nothing about whether the product records deserve to be seen, and segmentation has a way of exposing that: the moment different buyer groups get different assortments, the gaps in attributes, spec fields, and per-segment merchandising stop hiding inside one big catalog. Programs that reach publication-level segmentation at real SKU counts usually hit the product content question next, which is where the PIM platforms guide picks up: one enriched record per product, feeding every publication from the same source.
A Cadence That Keeps It Honest
The programs that stay clean at scale run a small recurring routine rather than heroic cleanups. A quarterly assignment audit answers one question per account: does what this location points at match what the ERP says it should get? An orphan sweep looks for publishing-only catalogs and unattached publications, the documented leftovers of reassignment. A sampled price reconciliation pulls a handful of SKUs per tier and checks storefront price against the ERP record. None of it is glamorous, and all of it is cheaper than the margin reconciliation that happens when it is skipped for six quarters.
For the wholesale operations Uncap builds, the catalog architecture conversation happens before the account import, because the segmentation decision is nearly free on day one and expensive to retrofit at four hundred lists. Uncap has been a Shopify Platinum Partner since 2013, with more than 380 B2B commerce projects delivered for manufacturers, distributors, and wholesalers. Talk to Our Experts if your catalog count has outgrown the way it is managed, the pricing-truths-versus-assortments count is a one-session exercise.
Frequently asked questions
Do you need one catalog per customer on Shopify B2B?
No, and at scale you should not. Shared catalogs carry tier pricing for the many accounts that price identically, and per-account price lists are reserved for genuinely negotiated contracts. Shopify's two-catalog pattern goes further, splitting pricing-only and publication-only catalogs so fifty pricing tiers and ten assortments need sixty catalogs rather than five hundred.
What happens if a B2B catalog has no publication or no price list?
Missing publication: the logged-in buyer sees no products at all for that location. Missing price list: buyers receive initial variant prices converted to the market currency, meaning retail-level numbers with no warning. Both are documented behavior, and both are the first things to check when an account reports an empty or mispriced store.
How do you update thousands of B2B prices on Shopify?
Through the Admin API rather than the admin screen: the fixed-price mutation takes up to 250 prices per request and replaces existing entries, so large lists update as sequenced batches with retry handling. Operations whose pricing lives in an ERP typically automate this as a sync, mirroring price books to lists whenever contract records change.
Who should own catalog and price list management?
One named owner, with the ERP as the roster. Assignments change only through that owner, new accounts are provisioned from a runbook that names the tier list and publication, and a quarterly audit reconciles what each location points at against what the ERP says it should get. Catalog estates decay by unowned edits, not by big mistakes.