Welcome to Zuora Product Documentation

Explore our rich library of product information

Show Page Sections

Bundles in Product Catalog

Bundles allow you to sell multiple products as a single offer, maintaining visibility into individual components for billing and reporting.

Bundles let you sell multiple products together as a single packaged offer while still keeping visibility into the individual components for billing, usage, and reporting. A bundle behaves like a standard rate plan in Zuora, but groups multiple component products and rate plans into a single sellable entity. Bundles have their own pricing and charges, which may differ from the sum of the component prices, and can include optional component charges based on bundle rules.

Note:

This feature is in the Early Availability phase. If you want to have access to the feature, submit a request at Zuora Global Support.

Bundles help you:

  • Simplify purchasing with one SKU

  • Enforce what must be sold together

  • Support accurate billing and invoicing

  • Attribute revenue back to underlying components

Note:

Bundles define what is sold together. Dynamic pricing determines how much it costs based on context and attributes.

Bundle types

Zuora offers conceptual bundle types, including Hard Bundles and upcoming Dynamic Bundles.

Zuora’s overall bundling model includes the following conceptual bundle types:

  • Hard Bundles - A fixed set of products or services sold together under a bundle SKU. Components must be purchased together, cannot be unbundled, and appear as itemized line items on invoices. Component-level usage can still be tracked. The bundle has preset pricing and revenue attribution back to its components.

  • Dynamic bundles – coming soon – Bundles assembled at runtime based on rules such as eligibility, compatibility, and context. Dynamic bundles (also referred to as configurable bundles) are powered by Zuora’s rules engine and context attributes. Dynamic bundles are not part of the current EA scope.

Note:

Only Hard Bundles are supported in the current release.

When should I use Hard Bundles?

This section explains when Hard Bundles are the appropriate choice, helping you determine whether your products, billing requirements, and revenue attribution needs alignment with the Hard Bundle model.

Use bundles when:

  • You want to sell multiple products as one offering

  • Components must be purchased together

  • You need consistent billing and invoicing

  • Revenue must be attributed to underlying components

Do not use bundles if customers must freely add or remove components post-purchase. Consider soft or configurable bundles when available.

How Hard Bundles work

Hard bundles in Zuora are constructed from existing products and rate plans, ensuring consistent pricing, billing, and revenue handling through specific behaviors at the product, plan, and charge levels.

Hard bundles are built on top of existing products and rate plans. When you create a hard bundle, Zuora applies specific behaviors at the product, plan, and charge levels to ensure consistent pricing, billing, and revenue handling.

Product-Level Behavior

At the product level, a hard bundle:

  • Represents a new bundle product that references multiple existing standalone products.

  • Inherits features and entitlements from all included component products, when these capabilities are enabled.

  • Uses effective dates derived from its component products. By default, the bundle cannot be effective beyond the earliest end date of its component products.

  • Cannot include other bundles as components.

    • Nested bundles are not supported.

    • All component products must be standalone products.

Plan-Level Behavior

At the plan level, a hard bundle:

  • Is composed of rate plans that belong to the products included in the bundle.

  • Can only reference plans from products selected at the bundle product level.

  • Automatically inherits all charges from the selected component plans as the starting configuration for the bundle plan.

  • Uses effective dates based on the overlap of the component plans’ effective periods.

  • Effective date handling

    • Zuora calculates a proposed effective date for the bundle plan based on the earliest expiring component plan.

    • You may override the proposed effective date to an earlier date (for example, for backdating), as long as the component plan constraints allow it.

    • The bundle plan cannot extend beyond the earliest expiring component plan.

Charge-Level Behavior

When configuring charges for a bundle plan, Zuora starts by inheriting all active charges from the selected component plans. For each inherited charge, you can choose one of the following options:

  • Keep a 1:1 inherited charge

  • Exclude a charge - You can remove inherited charges that are not relevant to the bundle (for example, redundant installation or setup fees).

  • Create a new bundle-specific charge

    • You can add charges that exist only at the bundle level.

    • In the current release, combining charges with different accounting attributes is restricted due to revenue management requirements.

    • If a new charge represents multiple underlying components and is not attributed back, revenue may be treated as belonging to the bundle rather than the individual components in early phases.

  • Discounts follow specific rules in bundles:

    • Discount charges are not inherited from component plans.

    • To apply a discount to a bundle, you must create the discount directly on the bundle rate plan.

    • Bundle-level discounts apply only to the bundle charges and do not automatically cascade from component products or plans. This ensures that discounting is controlled at the bundle level and avoids unintended pricing or revenue attribution behavior.

Use Case: Create a Hard Bundle in Zuora Billing

A SaaS company offers multiple standalone products, such as Core Platform, Advanced Analytics, and Premium Support. Customers frequently purchase these together as a single solution.

Using Zuora Bundles, the company creates a Hard Bundle that packages these products into one sellable offering.

Sales selects a single bundle SKU during quoting. When the order is placed, Zuora automatically expands the bundle into its component plans and charges. The customer receives one invoice, while usage tracking and billing remain intact at the component level.

Result: Sales sells one SKU, customers receive one invoice, and Finance retains component-level visibility.

Limitations and known behaviors

This section lists the limitations and known behaviors of Hard Bundles in Zuora Billing.

The initial Hard Bundles release has these important limitations and constraints:

  • Component products and plans cannot themselves be bundles. A bundle can only reference standalone products and plans.

  • V1 does not support post-sale “unbundling” flows where parts of a bundle are automatically split into standalone subscriptions. To unbundle, you must cancel the original subscription and create new subscriptions for the desired standalone components, or use soft-bundle constructs when available.

  • Once an optional charge has been:

    • Subscribed, and then

    • Explicitly removed from a subscription bundle it cannot be added back to the same subscription rate plan in V1 (for both amendments and renewals).

  • For inherited charges, only price and default quantity are editable at the bundle level. Other properties (for example, accounting codes, tax codes) must be changed on the component charge and do not automatically cascade to the bundle’s catalog entries in V1.

  • Merging multiple component charges into a single bundle charge typically requires compatible accounting and tax metadata (for example, same accounting codes). Cross-category merging is limited by Revenue Management in early versions.

  • If a component plan’s price changes later, the system can notify you that bundles reference that plan, but bundle prices are not automatically updated. Product teams must manually adjust bundle pricing to reflect new economics.

  • Dynamic Pricing rate cards defined on component charges are not inherited by bundle charges. You must create a new rate card on the bundle rate plan if dynamic pricing is required. However, in future releases, bundles are expected to support dynamic pricing inheritance.

  • Multi-Entity (ME) is not supported for bundles in the current release.

  • Editing an existing bundle does not allow adding additional products. To change bundle composition, you must create a new bundle.

  • Clone functionality is not supported for bundles in V1.

  • Pricing waterfall is not supported when using bundles.