In B2B trade, not every customer sees the same shop. A specialist dealer is shown different items than an industrial customer, a contract partner sees special positions from their framework agreement, and phase-out or spare-part items stay hidden from entire customer groups. This assortment and visibility logic does not originate in the shop but in the ERP: customer master data, customer groups, releases and conditions decide who may buy what. B2B internet trade by wholesale and manufacturers reached around 509 billion euro in 2024 and grew by 7 percent (ECC Cologne); 76 percent of that revenue runs through proprietary online shops (ECC Cologne) -- exactly where customer-specific catalogs take effect. Unlike customer-specific prices or the credit limit, this is not about the amount but about pure visibility: which item appears in the catalog for which customer at all. This article shows how to transfer releases, customer groups, blocked products, login requirements and quick order by ERP item number from the inventory system into the shop -- in real time or via a cache.
Key takeaways
- In B2B, the ERP decides on visibility: customer group, release list, blocking flag and login requirement control which items a customer sees in the shop at all.
- Assortment logic is independent of price: it is about whether an item appears in the catalog, not what it costs.
- Customer groups bundle similar customers; customer-specific catalogs and framework-agreement items go further, down to the individual debtor.
- Quick order by ERP item number requires a clean resolution of customer number, item number and release.
- Timeliness is an architecture decision: a real-time query on every request or a regularly updated cache with defined invalidation.
Why Not Every B2B Customer Sees the Same Assortment
B2B purchasing is shifting to digital. Of the roughly 650 billion euro in total e-commerce in Germany, about 530 billion euro were generated in B2B business in 2024 (bevh). At the same time, only 13.3 percent of companies in Germany sold online to other companies or public bodies in 2023 (Statista) -- so the market is large but far from exhausted. Buyer expectations are clear: by the rule of thirds, a third of B2B customers each want in-person advice, remote contact or digital self-service (McKinsey). Those who order digitally expect exactly their assortment -- released items, their contract positions and no products irrelevant to them.
Unlike consumer retail, where everyone sees the same catalog, the B2B assortment is customer-dependent. The reasons are varied: commercial items that may only be sold to vetted businesses, spare parts for specific machine generations, brands with selective distribution, regional delivery restrictions or phase-out stock that only existing customers may still order. These rules live in the ERP because that is where the customer relationship is maintained -- not in the shop, which is only meant to reflect them.
Customer groups
Specialist, industrial and end customers see different catalogs because their conditions and permissions are stored differently in the ERP.
Framework agreements
Contract customers gain access to special items and quantities that no one outside the contract can order.
Selective distribution
Some brands or hazardous goods may only be delivered to authorized or certified businesses.
Spare-part logic
Spare and wear parts often belong only to the assortment of specific customers with the matching machine base.
Phase-out items
Products at the end of their lifecycle stay hidden from new customers and remain open only to existing customers for reordering.
Release requirement
New business customers are only unlocked after review; until then they see a restricted or blocked catalog.
What Steers Visibility: Releases, Blocks, Customer Groups
Visibility in the B2B shop is not a single switch but the interplay of several layers from the ERP. The overview below shows which values determine the catalog view, where they come from and how they act in the shop.
| Visibility layer | Source in the ERP | Effect in the shop |
|---|---|---|
| Customer group | Debtor master | Determines the base catalog |
| Release list (allow list) | Assortment or condition list | Only these items are visible |
| Block list (deny list) | Item or customer block | Hides individual items |
| Framework-agreement items | Contract or special list | Unlocks special positions |
| Login requirement | Customer-group rule | Catalog visible only after sign-in |
| Release status | Debtor flag | Steers blocked, under review or active |
Two basic principles meet here. An allow list (whitelist) releases exactly the items a customer may see -- everything else stays hidden. A deny list (blacklist) shows the full catalog and only hides individual blocked positions. Allow lists are more restrictive and suit heavily regulated assortments; deny lists are easier to maintain for large, mostly open catalogs. Which model fits depends on the share of blocked items. The distinction matters: this logic decides pure visibility, not price. Customer-specific prices run through their own mechanism, which we describe in the article on price synchronization in the B2B shop, and purchasing ability is checked by the credit-limit check in the checkout -- both only apply after the item is visible at all.
Visibility, price and credit are three separate layers
The Data Flow from ERP Customer Master to Shop Catalog
The core of the solution is a traceable data flow between the ERP customer master and the shop catalog. It begins with the customer signing in and ends with a catalog view that shows exactly their assortment. In between lie a few clearly delimited steps.
- Customer identification: After login, the shop user is uniquely mapped to a debtor in the ERP via the customer number.
- Load visibility set: The middleware determines the debtor's customer group, release list, block list and framework-agreement items.
- Filter catalog: The shop catalog is reduced to the permitted items; blocked positions disappear from lists, search and direct access.
- Add special items: Contract and special positions are additionally shown, provided the customer may order them.
- Cache the state: The personalized assortment is held for the session and invalidated when the ERP changes.
A frequently underestimated point is direct access: a blocked item must not only disappear from category lists and search but must also be protected when its product URL is called directly -- otherwise a customer bypasses assortment control with a bookmark. The check therefore belongs in a central middleware and a clean API integration that verifies the signed-in customer's release on every item access. The basis is a consistent customer master; how to synchronize customer and item master data without duplicates is shown in the article on master data synchronization with MDM.
Customer Groups and Catalog Scope from the ERP
Where the visibility data lives depends on the leading system. In the major ERP and inventory systems, customer groups, assortment lists and blocks are stored in different places of the master data model but can be queried via standardized interfaces.
SAP
Customer groups, assortment lists and blocking flags live in the debtor and material master and can be queried via the standardized interfaces of the SAP integration.
Microsoft Dynamics 365
Price groups, trade agreements and item blocks in the debtor master steer which positions a customer sees; the Dynamics integration reads them via the Business Central or Finance interfaces.
JTL ERP and others
Customer categories and item visibilities from the inventory system can be mapped to shop customer groups via the JTL integration.
The central configuration step is the mapping between ERP customer groups and the shop's customer groups. An ERP group such as Specialist Trade North is assigned to a shop customer group that carries the matching catalog section. How deep assortments run is shown by the structure of the market: construction materials and sanitary supplies alone account for around 18 percent of B2B revenue (bevh) -- industries with huge, heavily segmented catalogs in which a customer may often order only a fraction of all items. For connecting the leading inventory system and importing these categories into the shop, our article on the JTL ERP shop integration is worth a look.
Quick Order by ERP Item Number
Business customers know their items. Instead of clicking through categories, they type the ERP or manufacturer item number directly into a quick-order field or upload an order list as a file. This quick order is a central efficiency feature in B2B -- but it only works if assortment control cooperates: the entered number must resolve to an item that is released for exactly this customer.
Resolution takes several number ranges into account: the internal ERP item number, the manufacturer or EAN number, and a possible customer-specific order number that some buyers keep in their own system. If the system finds the number, it checks the release for the signed-in customer before the position moves into the cart. A blocked or unreleased item is rejected with a clear message instead of silently landing in the cart.
def resolve_quick_order(customer, code, erp):
# code: ERP no., EAN or customer-specific order number
item = erp.lookup_item(code)
if item is None:
return Result("not_found", code=code)
if not erp.is_released(customer.debtor_id, item.id):
return Result("blocked", item=item.id)
return Result("ok", item=item.id, qty_min=item.min_qty)Quick order without an assortment check is a risk
Real-Time or Cache: Timeliness of Releases
How current visibility must be is an architecture decision. It balances the timeliness of releases against response time and ERP load. Four approaches are available and can be combined depending on the data type.
| Approach | Advantage | Limitation |
|---|---|---|
| Real-time query | Continuously current releases, no delay | Higher latency and ERP load per page view |
| Preloaded cache | Fast catalog view, low ERP load | Changes only take effect after invalidation |
| Event-based invalidation | Cache stays fast and current | Requires events or webhooks from the ERP |
| Hybrid per data type | Stable groups cached, critical blocks live | Somewhat higher configuration effort |
In practice, a hybrid approach proves effective: stable assignments such as customer group and base assortment are preloaded and updated regularly, while security-critical blocks -- for example a freshly set item blocking flag -- take effect immediately via events. Because B2B internet trade continues to grow in 2025, with an expected increase of 6.3 percent for the year (ECC Cologne), the number of connected catalogs and customers rises steadily; an architecture that balances timeliness and performance pays off as volume grows. How to couple shop and ERP technically in real time is explored in the article on SAP-Shopware real-time synchronization.
Stale visibility is more expensive than a stale price
Implementing Login Requirements and Blocked Products Correctly
Login requirements and blocks only work if they are enforced on the server side. A catalog that merely hides sensitive items in the frontend can be bypassed. The following points make assortment control robust.
- Login gate before the catalog: If the catalog is only visible after sign-in, the shop must consistently route unauthenticated access to the login -- including search and deep links.
- Hide blocked items server-side: Visibility must be enforced on the server, not just hidden in the frontend, so it cannot be bypassed via the product URL.
- Model new-customer release: As long as a business customer is under review, they see a reduced catalog or prices on request until the ERP unlocks them.
- Secure identity handover: The mapping between shop login and ERP debtor must be tamper-proof so no one can view other customers' assortments.
- Traceability: Releases and blocks should be logged with timestamp and trigger to answer customer inquiries and audits.
The connection between shop and ERP transports who may see which catalog -- a sensitive path that belongs technically secured. How to harden access to ERP interfaces with token procedures is described in the article on OAuth 2.0 and token security for ERP interfaces. When orders do not come through the shop but through a customer's procurement portal, the same releases apply; connecting such portals is shown in the article on the OCI punchout integration.
Project Flow of an Assortment Control
More than half of B2B buyers expect a seamless omnichannel experience and switch suppliers when there is friction (McKinsey) -- a consistent, correct assortment across all channels is therefore not a comfort but a retention factor. Total B2B e-commerce including EDI passed the mark of 1.5 trillion euro in 2024 and grew by 5.5 percent (ECC Cologne). Introducing ERP-driven assortment control typically follows five phases.
Five phases to productive assortment control
- 1
Assessment
Capture the leading ERP, existing customer groups, allow and deny lists, and special cases such as login requirements and new-customer release.
- 2
Define the rule set
Decide which visibility is steered via groups, which via allow and deny lists and which via framework agreements.
- 3
Mapping and interface
Map ERP customer groups to shop customer groups and build the connector and filter logic in the middleware.
- 4
Test with real data
Check catalog views per customer group against the ERP releases and test direct access and quick order.
- 5
Go-live and maintenance
Production operation with monitoring of catalog errors, block hits and response times, followed by ongoing fine-tuning.
Common Pitfalls and How to Avoid Them
Recurring mistakes crystallize from integration projects. Planning for them from the start avoids wrong catalog views and expensive rework in production.
- Frontend-only hiding: If a blocked item is only hidden via CSS or in the template, it remains reachable via search, feed or product URL.
- Mixing visibility with price: Combining release and price in one rule creates hard-to-maintain special cases and contradictory views.
- Stale cache on blocks: Without defined invalidation, the shop keeps showing long-blocked items.
- Missing new-customer logic: If the under-review state is not modeled, fresh customers see either everything or nothing.
- Quick order without a release check: Directly entering the item number bypasses assortment control if the release is not verified.
- Inconsistent customer master: Duplicates or wrong assignments cause a customer to see the wrong assortment.
The most important question in the B2B shop is not what the item costs, but whether this customer may see it at all -- and the answer lives in the ERP.
Sources and Studies