***

title: Product Catalog & Pricing Reference
subtitle: Complete configuration of Prolifi's product catalog -- from defining products and plans through to pricing models, entitlement structure, plan variants, grandfathering, and acquisition strategy.
slug: billing-pricing/product-catalog-pricing
---------------------

For clean Markdown of any page, append .md to the page URL. For a complete documentation index, see https://docs.prolifi.io/billing-pricing/llms.txt. For full documentation content, see https://docs.prolifi.io/billing-pricing/llms-full.txt.

## What this covers

This reference document covers the complete configuration of Prolifi's product catalog — from defining products and plans through to pricing models, entitlement structure, plan variants, grandfathering, and acquisition strategy. This document is the single reference for understanding how everything you sell is structured in Prolifi.

***

## Prerequisites

<Note>
  Before configuring the product catalog:

  * Account setup is complete
  * Operating entities are configured (required for multi-currency pricing) — [See: Getting Started: Finance, Section 1](/getting-started/finance)
  * Tax settings are configured per entity (required for correct invoice tax calculation) — [See: Tax Management Reference](/global-operations/tax-management)
</Note>

***

## 1. Product Catalog Structure

Prolifi's product catalog is organised in a four-level hierarchy:

```mermaid
graph TD
    A["Product Group — optional organisational layer"] --> B["Product"]
    B --> C["Plan — priced, entitled version of the product"]
    C --> D["Pricing Plan — the pricing model and amount"]
    C --> E["Entitlement Definitions — what the customer gets"]
    C --> F["Billing Model — how and when the customer is charged"]
```

### 1.1 Product groups

Product groups are an optional organisational layer for catalogues with many products. They allow you to group related products together for display, reporting, and navigation purposes. A product group has no direct billing function — it is purely organisational.

Example product groups:

* "Platform" (containing all SaaS platform products)
* "Professional Services" (containing service-based products)
* "Add-ons" (containing all standalone add-on products)

### 1.2 Products

A **Product** ([Glossary: Product](/glossary/platform-concepts)) is the root entity in the catalog. Every plan, entitlement, and subscription references a product.

**Product attributes:**

| Attribute     | Description                                                                             | Required                     |
| ------------- | --------------------------------------------------------------------------------------- | ---------------------------- |
| Name          | The commercial name displayed to customers                                              | Yes                          |
| Description   | Marketing description of the product                                                    | Recommended                  |
| Category      | Product type classification (Digital Service, Physical Product, etc.)                   | Yes                          |
| Status        | Draft / Active / Archived                                                               | Yes                          |
| Product group | The group this product belongs to (if using groups)                                     | Optional                     |
| External ID   | Your system's identifier for this product                                               | Recommended                  |
| Tax code      | The tax classification for this product ([Glossary: Tax Code](/glossary/billing-terms)) | Required for tax calculation |
| Metadata      | Custom key-value pairs for internal use                                                 | Optional                     |

**Product status lifecycle:**

* **Draft:** Product is being configured; not visible for subscription creation
* **Active:** Product is live; subscriptions can be created
* **Archived:** Product is no longer sold; existing subscriptions continue but no new ones can be created

### 1.3 Features

Features are the specific capabilities or access rights associated with a product. Define features at the product level before configuring plans, because plans reference features when configuring entitlements.

Features can be:

* **Binary:** Feature is either included (on) or not (off) for a given plan
* **Quantified:** Feature is included at a defined quantity (e.g., "up to 10 users", "100 GB storage")

Feature examples:

* "API Access" (binary)
* "Advanced Reporting" (binary)
* "User Seats" (quantified)
* "Storage (GB)" (quantified)
* "API Calls per Month" (quantified, usage-tracked)

***

## 2. Plans

A **Plan** ([Glossary: Plan](/glossary/platform-concepts)) is the commercially packaged, priced version of a product. A product typically has multiple plans representing different tiers or configurations.

### 2.1 Plan attributes

| Attribute          | Description                                                                                        |
| ------------------ | -------------------------------------------------------------------------------------------------- |
| Name               | The commercial plan name (e.g., "Professional", "Enterprise")                                      |
| Description        | Plan description shown to customers                                                                |
| Status             | Draft / Active / Archived / Grandfathered                                                          |
| Billing model      | The billing model for this plan — [See: Billing Models Reference](/billing-pricing/billing-models) |
| Pricing plan       | The pricing model and amount                                                                       |
| Billing frequency  | Monthly, annual, quarterly, custom                                                                 |
| Trial period       | Number of days before first charge                                                                 |
| Entitlements       | The features and quantities included in this plan                                                  |
| Upgrade paths      | Which plans this plan can be upgraded to                                                           |
| Downgrade paths    | Which plans this plan can be downgraded to                                                         |
| Minimum commitment | Minimum period before cancellation without penalty                                                 |
| Auto-renewal       | Whether the plan auto-renews at commitment end                                                     |

### 2.2 Plan variants and alternate pricing

A single plan can have multiple pricing variants, each representing a different pricing option for the same plan configuration. Common use cases:

* **Currency variants:** The same plan priced in GBP, USD, EUR separately
* **Billing frequency variants:** Monthly pricing vs. annual pricing at a discount
* **Customer segment variants:** Standard pricing vs. partner pricing vs. enterprise pricing

Plan variants share the same entitlements and billing model but have different pricing configurations.

### 2.3 Add-ons

**Add-ons** ([Glossary: Add-on](/glossary/platform-concepts)) are separate products that are sold alongside a base subscription. They extend the base subscription's capabilities without requiring a plan upgrade.

Add-on configuration:

* Add-ons are products in their own right — they have their own product record, pricing plan, and optionally their own entitlements
* Add-ons are linked to base subscription plans to define which add-ons are available with which base plans
* Add-ons can be priced independently of the base subscription (their own billing cycle and model)
* Add-on invoices can be included in the base subscription invoice (consolidated billing) or issued separately

***

## 3. Pricing Models

Prolifi supports eight pricing model types. The pricing model determines how the billable amount for each charge period is calculated.

### 3.1 Fixed Pricing

([Glossary: Fixed Pricing](/glossary/pricing-subscription-terms))

**How it works:** A fixed amount, charged every billing period regardless of usage.

**Configuration:**

* Amount: The fixed charge per billing period (e.g., £500/month)
* Currency: The billing currency

**Example:** Enterprise SaaS plan at £1,200/month. Every month, the invoice is for exactly £1,200.

***

### 3.2 Per-Unit Pricing

([Glossary: Per-Unit Pricing](/glossary/pricing-subscription-terms))

**How it works:** A price per unit multiplied by the quantity of units. The total charge scales linearly with quantity.

**Configuration:**

* Unit price: The charge per single unit (e.g., £50 per seat)
* Value metric: The unit being priced (e.g., "user seats")
* Quantity: Fixed quantity on the subscription, or variable (set by the customer or updated by usage events)

**Example:** SaaS platform at £50 per seat. A customer with 8 seats pays £400/month.

***

### 3.3 Volume Pricing

([Glossary: Volume Pricing](/glossary/pricing-subscription-terms))

**How it works:** The total quantity determines which rate band applies, and that rate is applied to the entire quantity.

**Configuration:**

* Price bands: Define quantity thresholds and the rate per unit for each band
* Bands are evaluated by looking at the total quantity and finding which band it falls in

**Example:**

| Quantity band | Rate per unit |
| ------------- | ------------- |
| 1–100         | £1.00/unit    |
| 101–500       | £0.80/unit    |
| 501+          | £0.60/unit    |

Customer uses 200 units → falls in 101–500 band → pays 200 x £0.80 = £160.
Customer uses 600 units → falls in 501+ band → pays 600 x £0.60 = £360.

***

### 3.4 Tiered Pricing

([Glossary: Tiered Pricing](/glossary/pricing-subscription-terms))

**How it works:** Each portion of usage is priced at the rate for the tier it falls within. Units in tier 1 are priced at tier 1's rate; units in tier 2 are priced at tier 2's rate.

**Configuration:**

* Tiers: Define quantity thresholds and the rate per unit within each tier
* All units within a tier are charged at that tier's rate

**Example:**

| Tier   | Units   | Rate per unit |
| ------ | ------- | ------------- |
| Tier 1 | 1–100   | £1.00/unit    |
| Tier 2 | 101–500 | £0.80/unit    |
| Tier 3 | 501+    | £0.60/unit    |

Customer uses 600 units:

* Tier 1: 100 x £1.00 = £100
* Tier 2: 400 x £0.80 = £320
* Tier 3: 100 x £0.60 = £60
* **Total: £480**

***

### 3.5 Stair-Step Pricing

([Glossary: Stair-Step Pricing](/glossary/pricing-subscription-terms))

**How it works:** The total quantity determines a pricing band, and the customer pays the flat price for that band — regardless of how many units they actually use within the band.

**Configuration:**

* Steps: Define quantity thresholds and a flat price for each step

**Example:**

| Step   | Quantity range | Flat price |
| ------ | -------------- | ---------- |
| Step 1 | 1–100          | £100/month |
| Step 2 | 101–500        | £300/month |
| Step 3 | 501–2,000      | £600/month |

Customer uses 101 units → in Step 2 → pays £300 (not £100 + marginal rate on 1 unit).
Customer uses 499 units → still in Step 2 → pays £300.

<Note>
  Stair-step pricing creates a strong incentive for customers to manage usage just below a threshold, and a strong upsell signal when they approach the top of a step.
</Note>

***

### 3.6 Dynamic Pricing

([Glossary: Dynamic Pricing](/glossary/pricing-subscription-terms))

**How it works:** The price per unit or total charge is determined by a rules engine that evaluates conditions at billing time rather than a static configuration.

**Configuration:**

* Rules: Define conditions and the pricing outcome when each condition is met
* Conditions may include: time of day, day of week, customer segment, geography, external variable inputs

**Use cases:** Time-of-use pricing for utilities (peak/off-peak rates), demand-based pricing for cloud resources, segment-specific pricing applied at billing time rather than plan level.

***

### 3.7 Usage-Based Pricing

([Glossary: Usage-Based Pricing](/glossary/pricing-subscription-terms))

**How it works:** The charge is calculated from metered usage events. Events are aggregated over the billing period and the aggregated total is applied to a pricing calculation (per-unit, tiered, volume, etc.).

**Configuration:**

* Usage metric: The metric to aggregate (references a configured usage metric definition)
* Aggregation method: Sum, count, max, last value, or percentile
* Pricing applied to aggregated total: Per-unit, tiered, volume, or stair-step

**Example:** AI API service charges £0.002 per token. A customer uses 2,500,000 tokens in a month. Invoice amount: 2,500,000 x £0.002 = £5,000.

***

### 3.8 Hybrid Pricing

([Glossary: Hybrid Pricing](/glossary/pricing-subscription-terms))

**How it works:** Multiple pricing components are combined in a single plan. Most commonly a fixed base amount plus a variable usage component.

**Configuration:**

* Component 1 (fixed): A fixed amount charged every period
* Component 2 (variable): A usage-based or per-unit amount charged based on consumption
* Included units: Whether some usage is included in the fixed component before variable billing begins

**Example:** £500/month base fee + £0.01 per API call above 50,000. A customer making 80,000 calls pays: £500 + (30,000 x £0.01) = £500 + £300 = £800.

***

## 4. Entitlement Management

Entitlements define what a customer can access or consume under a plan. Each plan has a set of entitlement definitions that are provisioned automatically when a subscription to that plan is created.

For full entitlement configuration detail, see the [Entitlement Management Reference](/billing-pricing/entitlement-management).

**Summary of entitlement types:**

| Type           | Description                                                |
| -------------- | ---------------------------------------------------------- |
| Variable       | Has a defined quantity; consumption is tracked and counted |
| Binary         | Feature is either accessible (on) or not (off)             |
| Expirable      | Expires after a defined period or on a specific date       |
| Carry-Over     | Unused balance carries forward to the next period          |
| Auto-Extension | Automatically extends when it would otherwise expire       |

***

## 5. Grandfathering

**Grandfathering** ([Glossary: Grandfathering](/glossary/pricing-subscription-terms)) is the practice of protecting existing customers from pricing or packaging changes that apply to new customers.

### 5.1 When to use grandfathering

* You are launching a new pricing model and want existing customers to stay on the old pricing indefinitely
* You are discontinuing a plan but existing customers should remain on it until they choose to change
* You want to reward long-standing customers by maintaining their original pricing

### 5.2 How grandfathering works in Prolifi

When a plan is grandfathered:

1. The plan status is changed from "Active" to "Grandfathered"
2. No new subscriptions can be created on the grandfathered plan
3. Existing subscriptions on the grandfathered plan continue to renew and bill at the grandfathered plan's pricing
4. Customers on grandfathered plans can be migrated to a current plan at any time via a subscription plan change

Grandfathered plans remain visible in the system for operational purposes but are not available in the public plan catalog.

### 5.3 Migrating grandfathered customers

When you are ready to migrate grandfathered customers to a current plan:

* Use Prolifi's bulk subscription update tool to migrate a defined cohort
* Configure whether the migration triggers proration or takes effect at the next billing period
* Consider whether a discount or communication campaign is appropriate to soften the pricing change for affected customers

***

## 6. Offers and Acquisition Strategy

### 6.1 Discounts

Prolifi supports three discount structures:

**One-to-one:** Applied to a specific customer's subscription. Used for individually negotiated commercial terms.

**One-to-many:** A reusable discount code or campaign. Applied to multiple customers via a shared code or automatic application rules.

**Targeted:** Automatically applied to customers meeting defined criteria (segment, geography, plan type, signup date).

**Discount configuration options:**

* Type: Percentage off, fixed amount off, or fixed price override
* Duration: Once, N periods, or lifetime of subscription
* Scope: Specific products, specific plans, or any plan
* Stackability: Whether the discount can combine with other active discounts
* Expiry: An end date after which the discount code is no longer valid

### 6.2 Price ramps

A **Price Ramp** ([Glossary: Price Ramp](/glossary/pricing-subscription-terms)) schedules price changes over time. Configure at the plan level (for all customers on this plan) or at the subscription level (for a specific customer).

**Price ramp configuration:**

* Start price: The initial effective price
* Schedule: The dates (or period offsets) at which the price changes and the target price at each step
* Terminal price: The final price the ramp reaches

<Tip>
  Price ramps are transparent to customers — the full ramp schedule should be communicated at the time of subscription to avoid unexpected price increases.
</Tip>

### 6.3 Free trials and promotional periods

Free trials are configured as a property of a plan:

* Trial length (days)
* Whether a payment method is required at trial start
* Entitlement behaviour during the trial (full access or restricted access)
* What happens at trial end (auto-convert to paid, require customer action)

Promotional periods (e.g., "first 3 months free" on an otherwise paid plan) can be configured as a 100% discount for a defined number of periods.

***

## Cross-references

* [Prolifi Glossary](/glossary/platform-concepts)
* [Billing Models Reference](/billing-pricing/billing-models)
* [Entitlement Management Reference](/billing-pricing/entitlement-management)
* [Multi-Country Setup](/global-operations/multi-country-setup)
* [Tax Management](/global-operations/tax-management)