Revenue Recognition settings examples

Amortization granularity

This example uses the following assumptions:

• On June 15th, 2024 at 12:00:00 PM UTC, a customer starts a 4-month subscription that costs 120 USD.
• The subscription generates an invoice.
• The invoice finalizes and the customer pays 120 USD.

In this example, the invoice and revenue periods are from June 15, 2024 12:00:00 PM UTC to October 13, 2024 12:00:00 PM UTC. The 120 USD is recognized across 15.5 days in June, 31 days in July, 31 days in August, 30 days in September and 12.5 days in October. We can use this example to demonstrate the differences between our supported amortization methods.

If you looked at the summary after October ends, amortization by millisecond applied, you might see something like:

If you looked at the summary after October ends, amortization by day applied, you might see something like:

If you looked at the summary after October ends, amortization by month evenly applied, you might see something like:

If you looked at the summary after October ends, amortization by month evenly, first and last month prorated applied, you might see something like:

Record recovered revenue as gains

By default, Revenue Recognition recognizes recovered revenue as gains. Revenue recovered from events such as uncollectible invoices paid, disputes won, or refunds failed is booked to the Recoverables account (Gains). This example uses the following assumptions:

• On January 1, 2024 at 00:00:00 PM UTC, a customer starts a 4-month subscription that costs 120 USD.
• The subscription generates an invoice.
• The invoice is marked as uncollectible on February 1.
• On March 1, the invoice is paid and a recovery occurs.

When you disable this setting, revenue recognition resumes from the original revenue recognition schedule. This applies to two scenarios: when recovery occurs before the service period ends, or when recovery occurs after the service period ends.

If you receive cash before the service period ends, then the original revenue recognition schedule resumes. Using the example above, cash is received in March, which is before the service period ends. Rather than booking a gain in March, Revenue Recognition reverses the bad debt, recognizes revenue immediately for February and March, and adds the remaining deferred revenue back for the remainder of the subscription life. Revenue continues to be recognized until the end of the original service period. The summary might look like this:

If you receive cash after the original service period ends, revenue is recognized in the period cash is received. Using the previous example, if you don’t receive cash until May, Revenue Recognition reverses the bad debt and recognizes revenue immediately in May. The summary might look like this:

Stripe handles refunds failed and disputes won in a similar manner, but the recovered revenue goes to different accounts. For refunds failed, the recovered revenue goes to the Refunds account. For disputes won, the recovered revenue goes to the Disputes account.

Catch-up revenue

This example uses the following assumptions:

• On November 1st, 2024, at 00:00:00 UTC, a customer is billed for an invoice that costs 92 USD.
• The invoice has service periods from Oct 1, 2024 to Jan 1, 2025 for all of its line items.
• The invoice finalizes and the customer pays 92 USD.

In this example, the service period for the transaction begins prior to the invoice finalization, triggering the catch-up revenue effect. We can use this example to demonstrate the differences between enabling and disabling catch-up revenue.

After December ends, with catch-up revenue enabled, the summary might look like:

After December ends, with catch-up revenue disabled, the summary might look like: