Per-customer product catalogue visibility in a B2B ordering portal: how NZ distributors control it

Not every customer should see every product. A foodservice account ordering bulk cases of prepared sauces has no business seeing the retail-packaged range. A direct-to-consumer channel should not be able to order products priced for wholesale redistribution. A key account with an exclusive private-label arrangement should see lines that general trade customers cannot.

In a trade rep relationship, this is managed informally — a rep knows which customers order which ranges. In a self-service B2B ordering portal, that informal knowledge has to be encoded into the system. Per-customer product catalogue visibility is the mechanism that does it: each customer logs in and sees only the products their account is entitled to order.

This sounds straightforward. In practice, it is one of the more involved integration design decisions in a wholesale portal build — because the right answer requires the ERP, the integration layer, and the portal to share a consistent model of which customers can see which products, and to keep that model accurate as customers and products change over time.

Why NZ distributors need per-customer catalogue control

The business reasons vary, but the most common for NZ food and wholesale distributors are:

• Channel separation. Foodservice and retail are different channels with different product specifications, pack sizes, and pricing relationships. Products designed for one channel appearing in the other creates pricing disputes, compliance problems, and customer confusion.
• Exclusive or restricted products. Private-label lines, exclusive distributor arrangements, or products restricted to specific customer types (e.g., licensed premises, registered healthcare providers) need controlled access.
• New product gating. A new product line being rolled out to selected accounts before wider distribution — ensuring only the intended customers can order it during the launch window.
• Simplified ordering experience. A customer who only ever orders ambient grocery lines gains nothing from browsing a frozen and chilled catalogue. Restricting the visible range to what is relevant reduces noise and improves the ordering experience.

The data model: what drives visibility

Catalogue visibility is determined by two things working together: the customer record and the product record. Both live in the ERP, and the portal must read both to resolve what each customer sees.

On the customer side, the ERP debtor or customer record carries an account classification — customer type, customer class, channel code, price level group, or an equivalent field depending on the ERP. Accredo uses debtor classes and debtor categories; MYOB Acumatica uses customer classes; SAP and NetSuite have their own hierarchy. Whatever the label, these fields carry the business meaning: this account is a foodservice operator, this account is a retail stockist, this account is a direct-to-consumer channel.

On the product side, the ERP item master carries the corresponding restriction — a channel flag, a range code, a product type, or a customer class whitelist that specifies which account types can access each product. When a product manager sets a new line to "foodservice only" in the ERP item master, that decision should automatically determine which customers see it in the portal.

The integration layer reads both: at session login (or at query time), it resolves the customer's classification against the product restrictions and builds or filters the catalogue accordingly. The portal does not maintain its own separate list of "which products customer X can see." That list is derived from the ERP at runtime.

Whitelist vs exclusion: two approaches to the restriction model

There are two ways to structure catalogue restrictions, and the choice shapes how easy the system is to operate over time.

A whitelist model means a customer can only see products explicitly added to their permitted range. Nothing is visible by default unless it appears on the list. This is the most secure approach for strict channel separation — no product slips through by accident. The cost is operational: every new product must be explicitly added to the appropriate customer types before it becomes visible, which requires a discipline in the product onboarding process that not every business has.

An exclusion model means all products are visible by default, and restrictions are applied to remove specific products or categories from specific customer types. This is easier to operate when most products are available to most accounts and exceptions are infrequent. The risk is that a new restricted product added to the ERP becomes visible everywhere until the restriction flag is set — the default is permissive, not restrictive.

For NZ food distributors with clear channel boundaries, the whitelist approach — or a hybrid where each product range must be explicitly assigned to a channel — is usually the safer design. The additional onboarding discipline it requires is a worthwhile trade-off against the operational and compliance risk of wrong products appearing in the wrong channels.

New product onboarding: the failure nobody plans for

The most common catalogue visibility failure in production wholesale portals is not a configuration mistake on existing products — it is a new product added to the ERP item master that syncs to the portal with the wrong default visibility.

In an exclusion-model portal, a new product defaults to visible for all customers. If the product team adds a new foodservice-only line to the ERP but has not yet set the channel restriction flags, it will appear in the retail portal until someone notices and corrects it. In a high-SKU environment where dozens of new products are added monthly, this happens regularly.

The design decision that prevents this is simple: new products should default to hidden in the portal until the appropriate visibility configuration is set in the ERP item master. A product that no one can order yet does no harm. A restricted product visible to the wrong customers creates orders that cannot be fulfilled, pricing disputes, and channel relationship damage.

This default-hidden approach requires the product team to complete visibility configuration as part of the new product setup process — not an afterthought. Building this into the ERP item master workflow, with a checklist or approval step before a product becomes portal-visible, is the operational change that makes the technical model work in practice.

Search, browse, and direct URL access

Visibility enforcement applies across every way a customer might encounter a product in the portal. In search results, restricted products do not appear for customers without access. In category browsing, restricted categories are either not shown or shown as empty. In product recommendations or related-item suggestions, restricted lines are filtered from the output.

Direct URL access requires particular attention. If a customer obtains a URL for a restricted product — from a colleague, a shared link, or a prior session — the portal must return an appropriate response, not the product page. The correct response is a 404 or a neutral "product not found" message that neither exposes the product nor confirms it exists for that customer's channel. Enforcement must happen at the session or server layer, not just in the front-end UI — client-side filtering can be bypassed by anyone who inspects the page source or the API responses.

Four failure modes to design out

In production wholesale portals, catalogue visibility problems follow predictable patterns:

• No visibility enforcement built. The portal shows all products to all logged-in customers. This is the most common outcome when the integration is scoped as "product sync" without explicitly addressing visibility rules. It works until the first wrong order from the wrong channel.
• Restrictions maintained in the portal, not the ERP. A product team manually configures catalogue access in a portal admin interface separate from the ERP. When customer types change in the ERP or new products are added, the portal configuration does not update automatically. Drift accumulates until it becomes a significant operational problem.
• New products default to visible for all. As described above — the most common source of unintended product exposure in production systems.
• Rep ordering bypasses customer restrictions. When a rep orders on behalf of a customer through the portal, the portal may use the rep's permissions rather than the customer's. A rep who has full catalogue access can inadvertently order restricted products for a customer whose account is not entitled to them. The portal must apply the customer's visibility profile during any rep-assisted session, not the rep's.

What to define before build starts

Before writing any integration code, the following questions need answers from the business:

• Which ERP field on the customer record carries channel or type classification? Is it consistently populated across all accounts?
• Which ERP field on the product record carries channel restrictions or range assignments? Is it populated for existing products, or does it need to be backfilled?
• Whitelist or exclusion model — which matches how the business actually operates its product range decisions?
• What is the default visibility for a product with no restriction data configured? (Hidden until configured is the recommended answer.)
• How does a customer get the wrong catalogue today, and what is the expected response from the portal?

These questions are not technical — they are operational decisions that the business needs to make before the integration design can be finalised. Leaving them unresolved until mid-build is one of the most reliable ways to extend a portal project by four to six weeks.

Per-customer catalogue visibility sits alongside customer-specific pricing, credit limit management, and order minimums as one of the four areas where a purpose-built wholesale portal differs most from a generic e-commerce store. Each requires the portal to reflect the reality of how the business manages its accounts — sourced from the ERP, not re-entered and maintained in a second system.

If you are evaluating a B2B ordering platform for your distribution business, or working through how catalogue restrictions should connect to your Accredo, MYOB, or other ERP, talk to the Zeabyte team. We build wholesale ordering platforms with deep ERP integrations for NZ distributors, and catalogue visibility design is one of the first questions we work through in every platform engagement.

For a broader look at what separates a purpose-built wholesale portal from a generic e-commerce approach, the B2B trade portal vs e-commerce guide covers the full picture.