Products & pricing

The catalogue and pricing engine that everything else in CPQ draws on. Products are defined once; prices are calculated through a transparent, ordered waterfall.

Core objects

Products — the catalogue master, classified as SIMPLE, BUNDLE, KIT, OPTION, SERVICE, SUBSCRIPTION or DIGITAL. Each product supports:
- Categories and product families for organisation.
- Attributes (including picklist/multiselect values) and per-product values.
- Features and options (both directly on a product and nested under features).
- Bundles and kit contents — a bundle tree of child products sold as a set.
- Relationships and compatibility rules between products.
- Versions (with a current version) and media (images, video, documents, 3D models).
Bill of materials (BOM) — attribute and item definitions/mappings that describe assembled or manufactured products, usable down to quote lines.
Price books & entries — currency-specific price lists; cloneable, with CSV import/export of entries. An entry carries a list price, an optional cost price and an optional floor price — the intended minimum selling price, used to clamp calculated prices (it must be non-negative and no higher than the entry’s list price).
Rate cards and price conditions — advanced, condition-based pricing inputs used within the waterfall.
Discount schedules & tiers — volume/term discount bands.
Promotional campaigns & promotional products — time-boxed promotions with a calendar, activation/deactivation and campaign analytics.
Pricing rules — a saved condition paired with a calculation formula, applied by the price waterfall. See Pricing rules below.
Guided selling processes — scripted question-and-answer flows that lead a seller to the right product. See Guided selling below.
Discount approval matrix — thresholds that decide when a discount forces an approval (see Quotes & approvals).

The pricing waterfall

Pricing is computed as an ordered sequence of adjustments, each recorded as a step so the final price is fully explainable. Steps include:

Base price and price-condition adjustments
Rate card pricing
Discount schedule / volume discount
Term discount (based on commitment months)
Discount matrix and discount approval
Campaign and promotional override
Pricing rule adjustments
Contract price and manual adjustments
Tax and surcharge, ending at the final price

Pricing guard rails

These rules apply when CPQ calculates a price for a product — the pricing endpoint, and the auto-pricing that runs when a product is added to a quote. The standalone waterfall tool described above is an analysis view: it clamps a negative result to zero (shown as a Price Floor step) but does not apply the price-book floor price, and if a configured tax provider is unavailable it falls back to the tax rate supplied with the request — it does not consult the tax tables maintained under Tax Management, and applies no tax if the request carried no rate.

Calculated prices are clamped to the price-book floor price. However the discounts stack — price conditions, rate card, volume, term, promotion, negotiated — the calculated net price is never allowed to fall below the floor price on the product’s price-book entry. A price-increase condition can still take the price above list.
A calculated net price is never negative. Fixed-amount discounts that stack up to more than the list price are clamped to zero rather than producing a negative calculated price.
Pricing lookups fail closed. If a price-book, discount-schedule, promotion, contracted-price, tax-rate or exchange-rate lookup fails, the calculation raises an error rather than returning a silently wrong price — it will not fall back to “no discount” or a 1:1 exchange rate. Configuration that is genuinely absent (no discount schedule, no live campaign, no sales agreement, no rate on file for a tax code) still simply means “no discount” or “no tax”; only error paths fail closed. The external tax provider noted above is the one deliberate exception — it falls back rather than erroring. In the same spirit, a price condition scoped to particular customer tiers or regions applies only when the customer’s tier/region is known and matches — an unknown tier or region never qualifies.

Prices that reach a quote line without going through the engine are stored as entered. A price a user types or edits directly on a line is not re-clamped against the floor or against zero, and if auto-pricing fails while a product is being added, CPQ logs the failure and keeps the price the caller supplied rather than rejecting the line. Use the discount approval matrix — not the floor price — to control what may leave the building.

Pricing rules

A pricing rule is a saved condition paired with a calculation formula. Rules are maintained under Pricing → Pricing Rules; each carries a name, a short code, a type, an evaluation scope and an evaluation order — lower numbers run first. The first hundred active rules, in evaluation order, take part in a calculation.

The form offers five type labels, saved as three stored types. Discount, Surcharge and Override are all stored as Adjustment and behave identically — the formula alone decides the new price, so the label records your intent and nothing more. Validation is stored as Validation; Informational is stored as Calculation, so leave informational rules without a formula — a stored Calculation rule with a formula will change the price. The list and its type filter work in the stored types, and reopening a rule stored as Adjustment or Calculation leaves the Rule Type field blank — a Validation rule reopens correctly. Saving again keeps the stored type either way.

Validation is the only type that never touches the price: a Validation rule that matches produces no visible output — no message, no warning, no waterfall step. Every other rule runs its formula. Use the discount approval matrix, not a validation rule, to stop a price leaving the building.

Every rule also carries an evaluation scope — Line Item, Quote or Cart. It is recorded on the rule but does not change how the rule is evaluated: every active rule is evaluated against the line being priced.

Conditions

Conditions are assembled in the visual builder and nest into AND/OR groups. Build them on the fields a price calculation actually supplies: customer type, customer tier, customer region, quantity and unit price. Subtotal is supplied as well, but it carries the running unit price rather than price × quantity, and current discount is always zero — neither is much use in a condition.

The builder also offers order total, product category, product type and margin %. A price calculation never supplies these, and a condition on a field with no value cannot match, so a rule that tests one of them will never fire.

Formulas

An Adjustment rule carries a formula that returns the new price. Formulas are expressions rather than code. They may reference price, quantity, discount, subtotal, margin, cost and order_total, use the usual arithmetic operators and ^, and call min, max, round, floor, ceil, abs, pow and sqrt.

price * 0.9 — take ten per cent off
price - 50 — take a flat 50 off
500 — override the price outright
min(price * 0.9, 950) — ten per cent off, capped at 950

Write formulas against price and quantity. In a real calculation cost, margin and order_total resolve to zero, so a formula like max(price * 0.7, cost * 1.1) — which reads as “discount hard but hold a margin over cost” — quietly collapses to price * 0.7 and protects nothing. The form’s own margin-protection example fails earlier still: it is written as Math.max(...), which the expression engine does not recognise, so the formula will not parse and the rule never fires at all.

A formula that will not parse, that names a variable CPQ does not supply, or that produces anything other than a finite number leaves the price untouched — the rule simply does not fire. A result below zero is clamped to zero.

Try a rule before you switch it on

Every rule form carries a Rule Simulator. Enter a price, quantity, customer type and product category, run the simulation, and CPQ reports whether the conditions matched, whether the rule is active, the resulting price and the percentage change, with an expandable log of the inputs and the formula result.

Treat it as a scratchpad for the arithmetic, not a rehearsal. It runs the same condition evaluator as the server, but not the same inputs: it hands the rule a product category, which a real calculation never supplies, and it offers no customer tier or region, which a real calculation does. A rule on product category will match here and can never fire live; a rule on customer tier looks dead here and works in production. It also runs the formula whatever type the rule is. Check the numbers here, and check the matching against the field list above.

A rule only takes part in a calculation while its Active switch is on, so a rule can be drafted, simulated and left dormant until you want it. The list searches by name, filters by stored type and active state, and opens any rule for viewing, editing or deletion.

Where pricing rules apply

Pricing rules are evaluated by the price waterfall calculation, after promotions and before contract pricing — so they shape the numbers you see on the waterfall screen and in an exported waterfall. They are not part of the auto-pricing that runs when a product is added to a quote; that path is the price-book and discount-schedule engine described under Pricing guard rails above.

Guided selling

Guided selling turns “which of these products does this customer actually need?” into a scripted set of questions. A process is a named, coded wizard, kept under Configuration → Guided Selling and optionally scoped to one product category. You control whether respondents may skip steps, whether they can navigate backwards, and whether a progress bar is shown, and you can set the message and the redirect URL used when the process finishes.

Each process holds an ordered set of steps. A step has a number, a name and code, a title, a description, help text and instructions, and one of five types:

Step type	Purpose
Question	Ask the respondent something
Product selection	Let them pick products
Attribute selection	Let them pick product attributes
Information	Show guidance without collecting an answer
Summary	Review the selections so far

Steps that collect an answer use one of nine input controls — radio buttons, checkboxes, a dropdown, a multi-select, text, number, date, slider or none — and draw their choices from a static list, the product catalogue, a product’s attribute values, or a dynamic source. A step can be marked required, given a default value, laid out as a standard form, grid, list or cards across up to six columns, shown with or without images and prices, and pointed at the step that should follow it. Processes and steps are listed together, so you can expand a process and add, edit or delete its steps in place.

The app is where processes are designed. Submitting a respondent’s answers and getting back the scored product recommendations is done through the guided-selling API.

The product configurator

Products → Configurator is the hands-on view of a configurable product. Pick a product from the searchable list of active products — or open the configurator straight from a product — and CPQ lays out that product’s features, each with its available options and the price adjustment the option carries, shown as a fixed amount or a percentage. Options are presented as dropdowns, radio buttons or checkboxes according to how the option was defined, and the same features can be worked through either as a single form or one step at a time.

The features and options the configurator walks through are defined on the product itself — see Core objects above.

Master data

The shared lookup lists live under Masters, one screen per type:

Currency — the currency codes price books and quotes are denominated in.
Payment terms — the terms a customer record can be put on.
UOM — units of measure.
Shipping methods — the delivery options available to an order.

Each screen lists its entries with search and sorting, and lets an administrator add, edit, deactivate and remove them.

Tax has a dedicated home at Admin → Tax Management, in three parts:

Tax codes — the codes applied to products and lines, fully editable.
Jurisdictions — the places a tax applies. Listed and added here.
Tax rates — the rate for a code in a jurisdiction. Listed and added here.

These tables back CPQ’s built-in tax engine — the tax API and the tax on an invoice. Tax on a quote line is worked out differently, from the rate in the tax code’s own name rather than from these tables: see Tax on quote lines.

A company can point CPQ at an external tax service instead — Avalara or Vertex — which the waterfall then uses to cost tax, including address-based jurisdiction resolution. See Pricing guard rails above for what happens when a configured provider is unreachable.

What you can do

Calculate a waterfall for a product/quantity and get a per-step breakdown, an explain view, and a compare of up to five pricing scenarios.
Calculate a price against a price book, or a discount from a schedule, on demand.
Export a quote line’s waterfall to CSV/JSON for audit.
Import and export price-book entries in bulk (CSV).
Run promotional campaigns automatically or against a promo code, and review campaign analytics.

Admin-configurable

Price books, rate cards, price conditions, discount schedules and tiers, promotional campaigns, pricing rules, guided selling processes and the discount approval matrix are all maintained by administrators. Price books and quotes each carry a currency code; the currency list itself, along with the other lookup lists and the tax tables, lives in Master data.

Connects to

Quotes & approvals — the engine prices quote lines as products are added, and discounts drive approvals.
Subscriptions — recurring products use dedicated subscription pricing models.
CRM — products and pricing back the deals raised in CRM.