Skip to main content
Menu
Product
Solutions
Integrations
Resources
Guide — catalog rules

How to create Catalog Rules for reseller pricing and product access

Different resellers need different terms — and maintaining a hand-edited price file per partner is how mistakes ship. Catalog Rules solve this at the catalog level: each shared catalog carries its own product filters, exclusions, and pricing calculations, and every reseller assigned that catalog receives the same rule-applied result. This guide walks through building a catalog's rules end to end — including the MAP review step that keeps your calculated prices honest — using a fictional manufacturer and reseller so every number is safe to read.

By Ryan Balchand, Founder, InventaCloud · Published 2026-07-20 · Updated 2026-07-21

1. Introduction

Throughout this guide we'll follow a fictional example: manufacturer Northstar Home Products configuring its Lighting — Dealer catalog for reseller Metro Design Supply — with a markup rule, a restricted category excluded, and a MAP review before sharing. All companies, SKUs, and prices shown are fictional demo data.

2. What a Catalog Rule controls

Rules belong to a catalog, and they shape what that catalog delivers, along two dimensions:

Product access
Which products the catalog includes at all — include filters matched on your data's fields, plus explicit exclusions.
Pricing
Which numbers the catalog carries — percentage or amount adjustments computed over the price role you choose.

The scope to hold onto: a rule applies to its catalog, and every reseller assigned that catalog receives the same rule-applied result — the portal view, their downloads and feeds, and the prices their purchase orders are built at all inherit it. Who receives which result is decided by which catalog you assign them.

3. Before creating a rule

Three prerequisites make rule-building quick: the catalog is imported and clean (see mapping your CSV columns), your price roles are populated as separate fields (cost, price, MSRP, MAP where you use it — see Product Data Management), and the reseller exists — invited directly or approved from the marketplace.

4. Choose the catalog and reseller tier

Because rules are catalog-level, a pricing tier in practice is a configured catalog. Partners on the same terms share a catalog; partners on different terms get different catalogs:

Northstar's tiers as catalogs (configured by Northstar — not auto-generated)
Fictional example
Lighting — DealerStandard dealer terms · Metro Design Supply and other dealers assigned
Lighting — Design TradeTrade terms · its own rules and its own assignments

Metro Design Supply sits on standard dealer terms, so Northstar assigns it the Lighting — Dealer catalog. A partner with genuinely unique terms gets its own configured catalog — deliberate overhead that keeps exceptions visible instead of buried.

5. Select the applicable catalog

Rules are edited on the catalog itself, so selecting the catalog is selecting who's affected: everything you configure here reaches exactly the resellers assigned to it, and nothing else. Northstar's other catalogs simply don't exist from Metro's perspective — assignment is what creates visibility, and one reseller can hold different catalogs with different rules where the relationship calls for it.

6. Define product filters

Include rules decide what's IN. Each rule matches a field from your imported data — a category column, a brand, any mapped field — with an operator (exact, contains, starts with, ends with) and a match value. Anything no include rule matches never enters this catalog.

Rule scope — Lighting – Dealer catalog
Fictional example
Include: category contains Pendants Include: category contains Sconces Include: category contains Table Lamps

7. Configure pricing adjustments

A price-adjustment rule computes the catalog's delivered numbers from a price role you choose: pick the target price field, an adjustment mode (percentage or amount), a direction (increase or decrease), and the value.

Pricing — Lighting – Dealer catalog
Fictional example
Target price roleCost
AdjustmentPercentage · Increase · 18
Example: NHP-2210 cost $100.00Catalog delivers $118.00

The platform applies exactly the arithmetic you configure, on every row, every rebuild. Confirm the base role before the percentage — +18% over cost and +18% over MSRP are very different offers.

8. Review calculated prices against MAP

MAP is a price role you supply — the advertising floor delivered with the catalog data so partners always have the current value beside their price. One thing to be clear-eyed about: the rules engine does not compare its calculated prices with MAP, and it does not adjust a result that lands below the floor. That comparison is your review step, and it belongs in every rule change:

MAP review in action
Fictional example
NHP-3305 · calculated price$84.00
NHP-3305 · MAP data value$89.00
Review resultBelow MAP
Required actionAdjust the pricing rule or source data before sharing

When a calculated value lands below MAP, fix it at the source — raise the adjustment, correct the cost or MAP data, or reconsider which catalog the product belongs in — then rebuild and re-check. And keep the boundary honest: MAP delivery governs the data your partners receive; how a reseller prices on their own storefront remains their responsibility under your agreement. The full MAP workflow has its own guide: setting up and reviewing MAP pricing.

9. Add product or category exclusions

Exclude rules carve exceptions out of whatever the include filters admitted: a restricted line, individual SKUs, or (as Northstar does) the Contract-Only category. An exclusion wins over an inclusion — a product matched by both stays out of the catalog, with no gap or placeholder where it would have been. Discontinued status travels as product data too, so a rule matching the discontinued flag can keep phased-out items out of the catalog entirely.

10. Review rule order and stacking

A catalog can carry several price rules, and they run in the order you add them — each rule reads the value the previous one produced, and the last write wins. That makes stacking possible (a markup followed by a promotional amount adjustment) and makes order a decision, not an accident. There is no automatic conflict resolution: if two rules touch the same price field, YOU decide which order expresses your intent. Keep the stack short and legible, and when in doubt, preview (next step) rather than reasoning it out in your head.

11. Preview the reseller result

Browse the catalog exactly as its assigned resellers will receive it — products after filters and exclusions, prices after the adjustment stack — and read the MAP column alongside:

SKU (fictional)Your dataCatalog delivers
NHP-2210 · Brass PendantCost $100.00$118.00 · visible
NHP-3305 · Linen Table LampCost $70.00 · MAP $89.00$84.00 · below MAP — fix before sharing
NHP-4120 · Contract SconceCategory: Contract-Only— not included

Fictional example. This is the single most useful habit in rule work — the rule you meant and the rule you built diverge exactly once, in front of a partner, unless the preview catches it privately first.

12. Save and apply the rule

Save, and the rules take effect when the catalog rebuilds: the platform applies per-SKU price overrides first, then the catalog's rules, then publishes the result — so the portal view, downloads, and feeds all carry the same rule-applied output, and purchase orders built from here on are priced at the delivered numbers.

13. Test the reseller view

After saving, spot-check like a reseller would: open the preview again, check a handful of known products — one that should be excluded, one near your MAP value, one plainly marked up — and pull a download to confirm the file matches the view. Two minutes here prevents the awkward partner email later.

14. Update or disable a rule

Rules are living configuration: adjust the markup at renewal time, add exclusions as lines become restricted, or switch a rule's Active toggle off to suspend its effect while keeping it on file. Changes apply when the catalog rebuilds, and resellers see the updated result whenever they next look — each catalog shows its latest update date in their portal, and their next download carries the current delivered data. After any pricing change, repeat the MAP review from section 8: a rule edit that made sense in isolation can push a handful of calculated prices below the floor.

15. Common Catalog Rule mistakes

Markup on the wrong base role

+18% over MSRP is a very different number than +18% over cost. Always confirm the target price role before the percentage.

Skipping the MAP review

The engine won't warn you when a calculated price lands below MAP — checking the output against your MAP values is part of every rule change, not an optional extra.

One catalog doing every tier's job

A catalog delivers one rule-applied result to everyone assigned. When partners need different terms, configure separate catalogs — don't try to make one catalog mean two things.

Skipping the preview

The rule you meant and the rule you built diverge exactly once — in production, in front of a partner. Preview catches it privately.

16. Catalog Rule checklist

  • Tier structure decided — one configured catalog per set of repeating terms
  • The right catalog selected — rules affect exactly its assigned resellers
  • Include filters admit exactly the intended products, brands, or categories
  • Exclusions cover restricted and discontinued items
  • Pricing target role and adjustment value confirmed
  • Rule order reviewed where rules stack — last write wins
  • MAP values populated on the products that need a floor
  • Calculated prices reviewed against MAP — anything below fixed at the source
  • Reseller preview checked — including one excluded and one near-MAP product
  • A downloaded file spot-checked against the preview

Common questions

Can two resellers get different prices for the same products?

Yes — by assigning them different catalogs. Rules belong to a catalog and deliver one result to everyone assigned it, so different terms live on separately configured catalogs: standard dealers on one, trade partners on another, each with its own pricing rules and its own assignments.

What happens to existing purchase orders when I change a rule?

Nothing — submitted orders keep their durable snapshots. New orders are built at the updated rule-applied prices, and resellers see the current result whenever they visit: each catalog shows its latest update date, and their next download carries the current delivered data.

Does the platform stop a calculated price from going below MAP?

No. MAP is delivered as a price role alongside your calculated prices — the rules engine doesn''t compare its results with MAP or adjust them automatically. Reviewing the calculated output against your MAP values before sharing is part of the workflow, and what a reseller charges in their own store is governed by your MAP agreement with them, not by the platform.

Can I schedule a rule to start on a future date?

No — Catalog Rules are not date-scheduled, and there is no effective-date automation: a rule takes effect when you save and the catalog rebuilds. For a planned change, prepare the edit and apply it on the day the change should begin. The Promotions Calendar is a separate feature for sharing time-based promotional information — it does not schedule or change Catalog Rules.

Deliver consistent catalog access and pricing data.

Start a 14-day free trial and configure your first catalog''s rules — onboarding call included.