Customer-Specific Catalogs in B2B Shops 2026

Global B2B e-commerce will reach USD 36.16 trillion in 2026 at an annual growth rate of 14.5% (ITA/Experro). At the same time, current studies show: 77% of B2B buyers do not buy without personalized content (Numen Technology 2026), and more than half of all B2B mega-purchases above USD 1 million are now handled through digital self-service channels (Forrester B2B Buyer Insights 2026). 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

The German B2B e-commerce market is roughly three to four times larger than the B2C market and reaches an estimated volume of EUR 1.4 trillion (Statista). For comparison: total German online retail recorded EUR 476 billion in 2023, up 11.7% (bevh/Statista). 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 numbers are unambiguous: 66% of B2B buyers expect fully personalized journeys (Salsify 2026), 82% of B2B marketing leaders confirm that buyers now expect tailored experiences (Forrester), and 95% of B2B marketers report measurable improvements from personalization (BigCommerce). On the impact side, McKinsey consistently reports 5-15% revenue lift, 10-30% higher ROI, and up to -50% customer acquisition costs from personalization. Personalized web experiences deliver +19% revenue and +40% average order value according to Convert.com/McKinsey.

The flip side of a missing concept: 90% of B2B buyers switch suppliers after a poor digital experience (Sana/Nishtech), while 87% are willing to pay a premium for an excellent portal. Pricing pressure is equally high: 69% of B2B buyers expect dynamic prices online, 33% are frustrated when only static lists appear, 55% want their personal prices visible directly, and 49% expect individual payment rules (Growmax). A standard catalog cannot meet those expectations — Customer Catalogs can.

Customer Catalogs: Definition and Levels

Customer Catalogs are not a simple category filter but a multi-layered concept. Across our B2B projects, four levels have proven essential — 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. With 50,000 SKUs and 500 accounts, five-figure assignment volumes per configuration are routine (Growmax). 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 sits at USD 500 to 1,000+ (Digital Web Solutions) — compared with USD 60-150 in B2C. The B2B conversion rate is slightly below B2C at 1.8% vs 2.1% (Elogic/Ruler Analytics), but its weight is far greater due to the higher order value. Every pricing decision therefore matters: McKinsey quantifies that a 1% price increase can lift EBIT by 6-14% — making accurate per-customer pricing logic exceptionally valuable.

Industry benchmarks are clear: the average quote-to-order rate runs at 25-35%, while best-in-class companies reach 45-55% (Atwix 2026). 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. Existing customers typically generate 65% of revenue at only 35% share and deliver 31% higher AOV (Smile.io/BusinessDasher) — 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 specialised articles with batch and sterilisation constraints (OroCommerce/Cloudfy). 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 sterilised 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. Typical scale is significant: 50,000 SKUs per equipment family and 500 to several thousand accounts per machinery builder are routine (Growmax). 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. According to SellersCommerce, large office customers typically operate with whitelisted assortments, cost-center budgets, and PunchOut integrations 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.

Millennial buyers accelerate this trend: 68% prefer self-service in B2B (eMarketer 2026). 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. Across our projects, clear roles have proven themselves: 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. The following KPIs have proven meaningful in our projects, paired with benchmarks from current industry studies:

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. Typically, key accounts with framework contracts show disproportionally strong improvements, while walk-in customers remain stable.

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.