Revenue Recognition settings examples

Amortisation granularity

This example uses the following assumptions:

• On 15 June 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 finalises and the customer pays 120 USD.

In this example, the invoice and revenue periods are from 15 June 2024 12:00:00 PM UTC to 13 October 2024 12:00:00 PM UTC. The 120 USD is recognised 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 amortisation methods.

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

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

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

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

Record recovered revenue as gains

By default, Revenue Recognition recognises 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 1 January 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 1 February.
• On 1 March, 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, recognises revenue immediately for February and March, and adds the remaining deferred revenue back for the remainder of the subscription life. Revenue continues to be recognised 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 recognised 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 recognises 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 1 November 2024, at 00:00:00 UTC, a customer is billed for an invoice that costs 92 USD.
• The invoice has service periods from 1 Oct 2024 to 1 Jan 2025 for all of its line items.
• The invoice finalises and the customer pays 92 USD.

In this example, the service period for the transaction begins prior to the invoice finalisation, 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: