Pricing Methods

A line’s price is never a single number you set — it’s built, step by step, by the pricing waterfall. Each step starts from the running per-unit price and adjusts it; the methods you configured in Catalog & Pricing Setup are the steps. This section explains what each method does and the order it runs in.

The waterfall order

Pinion’s packaged order — the same sequence the configurator’s “Why this price?” trace replays:

  1. List price — seed the unit price from the pricebook.
  2. Block price — if the product is on Block pricing, replace the seed with the quantity-band tier.
  3. Contracted price — if a negotiated per-Account/Product rate applies, it replaces the unit price.
  4. Volume discount — apply the quantity-based discount schedule.
  5. Term discount — apply the duration-based schedule.
  6. Manual discount — apply the rep’s per-line Additional Discount (% then amount).
  7. Markup — mark the price up by a percent or amount (when configured).
  8. Promo code — apply the deal’s promo-code discount.
  9. Floor / Ceiling — clamp the running price so it never falls below a floor or rises above a ceiling.

Two more methods compose into this rather than sitting as a single step: config-attribute pricing builds the unit price from the rep’s attribute choices, and MDQ runs the waterfall per segment with per-year uplift. Percent-of-Total is a method of its own — a line priced as a share of the other lines.

From unit price to line total

The waterfall produces a per-unit price. The line total is then:

unit price × effective quantity

— where effective quantity is the billable quantity the line saves as its Quantity, not the raw number the rep typed. On a subscription line it already includes the term: the raw quantity × the term, counted in the product’s subscription term unit (10 seats over 3 years on a product whose term unit is Year is 30), then × any bundle multiplier. An MDQ segment carries its own prorated quantity instead of the term. The term is counted once, inside the quantity, never multiplied in again. Every surface that shows a price must reconcile to this, to the cent.

For a bundle, the per-unit price is not the parent product’s own list price. It is derived from the options on the bundle:

bundle per-unit = Σ (each option’s contribution) ÷ the bundle line’s effective quantity

An option that scales with the bundle (a Component) contributes its quantity times the bundle’s; a static one (an Accessory) contributes its own quantity only. On a subscription bundle the bundle line’s quantity and every non-discount option’s quantity also carry the term, once, so the per-unit price is per bundle unit per billing period. On Roll-Up and Itemized bundles, that derived per-unit is what gets stored on the line and what every surface displays, so the parent’s own catalogue price never appears as the bundle’s price. A Standard bundle is the exception: it is sold at the parent’s own price, and its options carry no dollars (see Bundle pricing models). Under Itemized pricing the parent line carries $0 and the child lines carry the money, which is why the parent’s unit price is never the thing to read.

”Why this price?”

Because the price is a sequence, Pinion can show its work: the Price Waterfall (the ⓘ next to a line total) traces every step — list → adjustments → unit price → quantity & term → line total — so the number is never a black box. See Configurator → Rule Transparency.

Computed twice, on purpose

Pricing runs in two parity-locked engines: a client engine computes live as the rep configures (so the deal reacts in real time), and an authoritative server engine recomputes on save — the persisted price is always the server’s, which protects against tampering. The two are kept in lockstep; a divergence is a bug, not a choice.