Customer-Specific Catalogs in B2B Shops 2026

Global B2B e-commerce will reach USD 36 trillion in 2026 at an annual growth rate of 14.5% (International Trade Administration). In German wholesale, just over a quarter of total revenue came from e-commerce in 2024: 25.52 percent among enterprises with 10 or more employees (Eurostat). Expectations are shifting as well: 64 percent of business buyers at manager level and above are Millennials or Gen Zers and bring their B2C expectations into B2B purchasing (Forrester). Anyone still serving an identical standard assortment to every customer in a B2B shop in 2026 loses margin, repeat-purchase rate, and trust at the same time. This guide shows how Customer Catalogs map roles, contract prices, and whitelists cleanly, which use cases matter most in medical technology, machinery, and office/MRO, and how the technical implementation on Shopware CE looks in practice.

Why Standard Catalogs Fail in B2B

Sales via websites, apps and marketplaces brought German wholesalers 10.88 percent of their total revenue in 2024, and 80.78 percent of that web sales revenue came from businesses and public bodies (Eurostat) – the online channel in wholesale is primarily a B2B channel. Meanwhile, online sales to consumers are growing: German B2C trade in goods reached EUR 83.1 billion after EUR 80.6 billion the year before, a growth of 3.2 percent (bevh). Yet many B2B shops still run a single catalog that shows every customer the same products, prices, and pack sizes. This matches neither the reality of B2B purchasing nor buyer expectations.

The reason lies in how buying groups are composed: 64 percent of business buyers at manager level and above are Millennials or Gen Zers (Forrester). According to Forrester they do far more self-guided research and have less patience for generic outreach. Personalized buying experiences answer exactly that, because every customer only sees what they can actually order at agreed terms.

The flip side of a missing concept: Switch-prone B2B buyers regularly cite a poor digital customer experience as a reason to go elsewhere, and a lack of cross-channel tracking as an impediment to doing business. Pricing pressure is equally high: buyers expect clear, detailed pricing upfront in the buying process instead of waiting for a sales callback. Data-driven dynamic pricing additionally improves margins for B2B distributors and manufacturers. A standard catalog cannot meet those expectations – Customer Catalogs with per-customer pricing can.

Customer Catalogs: Definition and Levels

Customer Catalogs are not a simple category filter but a multi-layered concept. We recommend four levels – each independently configurable, and in combination forming the full access logic. Every level may influence visibility, price, and terms.

Practically, the B2B shop must evaluate these four dimensions before rendering a product list, a category, or a cart. Sequence matters: first check whether the account has access to the product at all, then whether the role allows it, then whether the location is permitted, and finally whether an active project restricts or extends the assignment. Only after this access check does the pricing logic with contract prices, tiers, and promotional discounts apply – detailed further in our article on B2B pricing strategies 2026.

Implementing Role-Based Visibility Technically

The technical foundation for Customer Catalogs on Shopware CE combines customer groups, user roles, rule builder, and individual service decorators. Out of the box, Shopware CE already provides customer groups with their own prices, product visibility via rules, and account hierarchies with sub-accounts. For advanced B2B scenarios, we extend these building blocks through custom development – especially for role-location-project combinations that cannot be modeled declaratively.

A typical implementation pattern: a catalog_assignment table stores an authorization record per account, role, location, and product. A CatalogVisibilityService decorates the product loader, filters listings and search, and applies price-related rules on the product detail page. Crucially, this logic must also apply to PunchOut responses and API calls – otherwise gaps emerge. Example of a service configuration and the corresponding permission check:

services:
  App\Catalog\Service\CatalogVisibilityService:
    arguments:
      - '@Doctrine\DBAL\Connection'
      - '@Shopware\Core\System\SalesChannel\SalesChannelContextService'

  App\Catalog\Subscriber\ProductListingSubscriber:
    arguments:
      - '@App\Catalog\Service\CatalogVisibilityService'
    tags:
      - { name: kernel.event_subscriber }

  App\Catalog\Decorator\SalesChannelProductLoaderDecorator:
    decorates: 'Shopware\Core\Content\Product\SalesChannel\SalesChannelProductLoader'
    arguments:
      - '@.inner'
      - '@App\Catalog\Service\CatalogVisibilityService'

<?php

namespace App\Catalog\Service;

use Doctrine\DBAL\Connection;

class CatalogVisibilityService
{
    public function __construct(private Connection $connection) {}

    public function filterVisibleProductIds(
        array $productIds,
        string $accountId,
        string $roleId,
        ?string $locationId = null,
        ?string $projectId = null
    ): array {
        $sql = 'SELECT product_id
                FROM catalog_assignment
                WHERE account_id = :account
                  AND role_id = :role
                  AND (location_id = :location OR location_id IS NULL)
                  AND (project_id = :project OR project_id IS NULL)
                  AND product_id IN (:ids)
                  AND is_active = 1';

        return $this->connection->fetchFirstColumn($sql, [
            'account'  => $accountId,
            'role'     => $roleId,
            'location' => $locationId,
            'project'  => $projectId,
            'ids'      => $productIds,
        ], [
            'ids' => Connection::PARAM_STR_ARRAY,
        ]);
    }
}

Assignments themselves are never maintained manually; they are imported from ERP and PIM systems. In practice it pays off to treat the table as a view on a rule-based engine, not as a static list. Even with an example catalog of 50,000 SKUs and 500 accounts, four- to five-figure assignment volumes per configuration add up quickly. Inline admin editing does not scale here. Our custom-built ingest pipelines sync master-data changes, framework contract updates, and role mappings either nightly or event-driven.

Contract Prices and Tiered Models

Customer Catalogs only unfold their full value in combination with contract prices. Context: the average B2B cart value is typically above B2C levels, while the B2B conversion rate is lower – the individual order weighs more heavily in return. Every pricing decision therefore matters: a small price change moves profit more than revenue – making accurate per-customer pricing logic exceptionally valuable.

In practice, the quote-to-order rate varies widely between average and best-in-class companies – the difference arises exactly where customer-specific catalogs and contract prices are cleanly integrated, not at the sales call, but in self-service. More context in our article on B2B pricing strategies 2026. There is a hard reason to retain existing customers: increasing the customer retention rate by 5 percent increases profits by 25 to 95 percent, according to research by Frederick Reichheld of Bain & Company (Harvard Business Review) – another reason to map pricing for recurring buyers exactly.

Use Case 1: Medical Technology

In medical technology, framework contracts, roles, and certifications are tightly intertwined. Hospitals operate on multi-year contracts with fixed item baskets, volumes, and prices. Inside the hospital, central purchasing, wards, and the OR operate under different approvals: purchasing negotiates, wards order routine items, and the OR procures specialized articles with batch and sterilization constraints. A Customer Catalog must reflect this three-way split cleanly.

• Role-based visibility: Purchasing sees the full assortment including alternatives; wards see approved consumables; the OR sees sterilized items with batch IDs
• Framework contract prices: Items with negotiated fixed prices, tied to annual purchase volumes and automatic replenishment
• MDR-compliant data: UDI labels, batch info, and expiry dates per SKU – visible only to eligible roles
• Approval workflow: Orders above a threshold trigger a second approval by purchasing management
• Location split: Dedicated stock location per hospital site with individual lead time and minimum order quantity

The decisive benefit: the shop becomes an extension of the ERP system. Instead of calling central purchasing, wards order directly through the portal under exactly the negotiated terms and within the approval limits granted. This saves time across the order chain while increasing compliance against the framework contract.

Use Case 2: Machinery Spare Parts

In machinery, Customer Catalogs revolve around Bills of Materials (BOM) and serial numbers. An equipment operator should see their specific machines in the portal along with the assigned spare parts, exploded drawings, maintenance history, and approved alternatives. The scale can be significant: extensive spare-parts catalogs per equipment family and many operator accounts per machinery builder. Without a customer-specific catalog, operators would have to navigate a global list and risk miss-orders.

Technically the BOM is maintained in the PIM system and linked per serial number to the account. After login, the shop renders a ‘My Equipment’ view with direct access to the relevant spare parts. Maintenance roles see a different catalog than engineering or purchasing – the maintenance technician is offered typical wear parts immediately, while engineering can inspect the full BOM. Purchasing, in turn, can access alternate supplier items with their own prices. This use case is tightly connected to product configurators that cover compatible components, and to self-service portals that structure B2B self-service overall.

The effect: quote-to-order times drop, inside sales is relieved, and the operator receives within minutes what once took days. At the same time, loyalty to the manufacturer grows because the shop reflects exactly the customer's own machines. Switching to another supplier becomes less attractive – a clear competitive advantage beyond price.

Use Case 3: Office Supplies and MRO

In office supplies and MRO (maintenance, repair, operations) a different pattern dominates: many buyers per customer, small carts, tight budget and cost-center controls. In practice, large office customers typically operate with whitelisted assortments, cost-center budgets, and PunchOut integrations (OCI, cXML) into their procurement systems. The role of Customer Catalogs here is to reduce the full assortment to the customer-specific approved subset, serve contract prices, and monitor cost-center budget caps.

Younger buyers accelerate this trend: 64 percent of business buyers at manager level and above are Millennials or Gen Zers (Forrester) and, per Forrester, do far more self-guided research. They expect to find, order, and settle without a sales conversation – which only works if the assortment is pre-filtered. Combined with PunchOut catalogs (OCI, cXML) a seamless process emerges: the buyer starts inside their own SRM system, enters the shop, sees only the approved catalog with negotiated prices, and submits the order back into the procurement system as a requisition.

ERP/PIM Integration as Foundation

No Customer Catalog survives without clean data. Master data, customer-group assignments, and terms are not born in the shop but in the ERP system and the PIM. The shop is a sophisticated consumer of this data – never a primary source. We recommend clear roles: ERP delivers accounts, contract prices, tiers, credit limits, and cost centers; PIM delivers product attributes, variants, media, and BOM data; the shop combines both and translates them into a runtime logic that evaluates visibility and prices in real time.

For many customers we rely on SAP Business One or Microsoft Dynamics as the backbone. Details of those connectors are covered in our articles on ERP integration Shopware/SAP and Middleware for e-commerce integration. For larger projects, Microsoft Dynamics 365 often joins as a second pillar. Core rule: every term change in the ERP must appear in the shop within defined SLAs – via near-real-time events or scheduled syncs depending on the business model.

Performance KPIs for Customer Catalogs

Without metrics, Customer Catalogs quickly become a means in themselves. We recommend the following KPIs, with an industry figure only where a source exists:

Measuring these KPIs in a segmented way – by account type, role, and region – matters. A single global average hides the real effect of Customer Catalogs. The effect is to be expected mainly among key accounts with framework contracts, less among walk-in customers.

Implementation Roadmap in 5 Phases

Introducing customer-specific catalogs is not a plugin switch but a project with IT, sales, and data perspectives. We recommend a phased approach that delivers early outcomes while laying the foundation for longer-term extension:

1. Phase 1 – Data audit: Inventory accounts, roles, framework contracts, and terms in the ERP. Document master-data gaps and close them before building logic
2. Phase 2 – Access model: Define the account-role-location-project matrix. Workshop with sales, IT, and purchasing to reflect the real business model – not wishlists
3. Phase 3 – Technical build: Activate Shopware CE foundations (customer groups, rules, sub-accounts) and extend with custom service decorators for visibility, pricing, and projects
4. Phase 4 – Pilot with key accounts: Migrate 2–3 strategic customers, validate visibility, pricing, and workflows jointly. Build in feedback loops and measure KPIs before and after
5. Phase 5 – Rollout and iteration: Migrate all accounts step by step, expand self-service tools for buyers, add AI-supported catalog and pricing optimization, continuously monitor KPIs

Phases 4 and 5 benefit especially from robust monitoring. Signals that require adjustment include falling quote-to-order rates in specific segments, rising cart abandonments after login, or a strikingly low self-service share. Periodic consistency checks between ERP terms and shop terms – including automated discrepancy reports – regularly pay off in our experience.