Skip to content
Create account
or
Sign in
The Stripe Docs logo
/
Ask AI
Create account
Sign in
Get started
Payments
Revenue
Platforms and marketplaces
Money management
Developer resources
Overview
Billing
OverviewAbout the Billing APIs
Subscriptions
Invoicing
Usage-based billing
Quotes
Customer management
Billing with other products
Revenue recovery
Automations
Test your integration
Tax
Overview
Use Stripe tax
Manage compliance
Reporting
Overview
Select a report
Configure reports
Reports API
Reports for multiple accounts
Revenue recognition
    Overview
    Get started
    How Revenue Recognition works
    Data freshness
    Pricing
    Multi-currency
    Connect platforms
    Revenue Recognition for Usage-Based Billing
    Revenue contracts
    Reports
    Overrides
    Audit your numbers
    Examples
    Revenue recognition rules
    Revenue Recognition settings
    Map to your chart of accounts
    Performance obligations API
    Import data to Stripe
    Export data from Stripe
    Standalone selling price
Data
Overview
Business and product data use cases
SchemaData freshness
Sigma
Data Pipeline
Import external data
HomeRevenueRevenue recognition

Standalone selling pricesPrivate preview

Learn how to set up standalone selling prices and create bundles in Stripe Revenue Recognition.

The standalone selling price (SSP) feature enables businesses to accurately allocate revenue for bundled products. It allows for customizable bundle allocations based on either absolute values or percentages, and facilitates setting up different revenue schedules for individual bundle components. Additionally, you can audit journal entries at the bundle item level.

Set up standalone selling prices

You can manage standalone selling prices from the Stripe Dashboard. To create a standalone selling price for a bundle, go to the Standalone selling price page and click Add SSP.

An SSP set up consists of the following key components:

  • Product
  • Effective period
  • Allocation method
  • Bundle components

Product

Choose a product that you’re selling as a bundle. The allocation method applies to this product.

Effective period

An effective period specifies the time period that a SSP applies to.

For an invoice line item, if the finalization time for the invoice falls within the specified effective period, the invoice line item fulfills the effective period requirement.

Caution

For an SSP to apply to a transaction, the transaction must fulfill both the effective period and product requirements. When you update the effective period, the SSP retroactively applies to previous accounting periods. If the previous periods are closed, changes are reflected in the first open accounting period. You can avoid corrections by re-opening previous periods.

Allocation method

When a transaction fulfills both the effective period and product requirement, we apply a set of defined standalone selling prices.

The allocation can be either an absolute value (recommended when each product has its own price) or a percentage (recommended when individual prices aren’t available).

Bundle components

You can set up the product and standalone price for each bundle component. You can either calculate the allocation percentage based on the absolute value or specify it directly as a percentage. By default, we amortize the amount over the service period for each individual bundle component, which we determine using the recurring components of a price and its associated billing period.

Examples

Absolute method

For a desktop bundle product, you can set up the bundle as:

ComponentsValue
ProductDesktop bundle
Effective periodStart: All past dates-End: Indefinite
Allocation methodAbsolute

Bundle components:

ProductProduct Billing PeriodStandalone PriceAllocation %
Desktop (one-off)One-off400 USD80%
3-month warrantyRecurring: 3 months100 USD20%

On January 1, at 00:00:00 UTC, an invoice containing the desktop bundle product finalizes and it costs 450 USD. The customer pays 450 USD in Feb.

We recognize the 360 USD for the desktop immediately. We recognize the 90 USD for the one-year warranty through the end of March. If you looked at the summary after March ends, you might see something like:

Product desktop:

AccountJan 2019Feb 2019Mar 2019
Revenue+360.000.000.00
Deferred Revenue0.000.000.00
Accounts Receivable+360.00-360.000.00
Cash0.00+360.000.00

Product 3-month warranty:

AccountJan 2019Feb 2019Mar 2019
Revenue+31.00+28.00+31.00
Deferred Revenue+59.00-28.00-31.00
Accounts Receivable+90.00-90.000.00
Cash0.00+90.000.00

If you audited the invoice, you’d see:

AccountJan 2019Feb 2019Mar 2019
Revenue+391.00+28.00+31.00
Deferred Revenue+59.00-28.00-31.00
Accounts Receivable+450.00-45.000.00
Cash0.00+450.000.00

Percentage

You can also apply the percentage method regardless of the original amounts on the bundle components.

Allocation details:

ProductProduct Billing PeriodAllocation %
Desktop (one-off)One-off80%
3-month warrantyRecurring: 3 months20%

The journal entries remain consistent with the absolute method.

Audit journal entries

The bundle is reported at the bundle component level. When you download reports, we break down journal entries by each bundle component, which provides a detailed view.

Best practices for maintaining your bundles

The following are some best practices to keep your standalone selling prices correct for your Revenue Recognition reports.

Know when to create standalone selling prices

Create standalone selling prices you need to bundle products and need defined standalone prices and revenue schedules for finance teams.

How bundles interact with other configurations

  • Applying a rule to a product precludes it from being set as a bundle.
  • You can’t apply bundles alongside data imports.
  • We recommend setting up a chart of accounts for bundle components for accurate account mapping.

How we treat bundle components

Default treatments for bundle items include amortization for recurring periods over their service period. We recognize one-off products entirely upon invoice finalization.

Check the accounting period when applying new SSPs

If the effective period for a new SSP overlaps with a closed accounting period, it generates corrections if you retroactively apply the SSPs to transactions from past (closed) accounting periods. If you want to avoid this, reopen your books by opening your accounting period prior to adding the SSP.

Was this page helpful?
YesNo
  • Need help? Contact Support.
  • Join our early access programme.
  • Check out our changelog.
  • Questions? Contact Sales.
  • LLM? Read llms.txt.
  • Powered by Markdoc