Subscription examples

Unless stated otherwise, these subscription examples assume that revenue recognition takes place on a per-day basis.

Monthly subscription

This example uses the following assumptions:

• On 15 January, at 00:00:00 UTC, a customer starts a monthly subscription that costs 31 USD.
• The subscription generates an invoice.
• The invoice finalises and the customer pays 31 USD.

In this example, the invoice and revenue periods are from 15 January 2019 to 14 February 2019. The 31 USD is recognised across 17 days in January and 14 days in February. If you looked at the summary after January ends, you might see something like:

This means that recognised revenue increased by 17 USD for the days in January, and deferred revenue increased by 14 USD for revenue you expect to recognise in February.

Annual subscription

This example uses the following assumptions:

• On 1 January, at 00:00:00 UTC, a customer starts an annual subscription that costs 365 USD.
• The subscription generates an invoice.
• The invoice finalizes and the customer pays 365 USD.

In this example, the invoice and revenue periods are from 1 January 2019 to 31 December 2019. The 365 USD is recognised daily throughout the year. If you looked at the summary after March ends, you might see something like:

Monthly metered subscription

There are four types of aggregate_usage, each of which has a different implication on how revenue is recognised.

Sum

This example uses the following assumptions:

• On 15 January, a customer subscribes to a monthly metered subscription at 1 USD per unit, and with aggregate_usage=sum.
• On 25 January, they use 15 units.
• On 4 February, they use another 17 units.
• On 14 February the subscription generates an invoice totalling 32 USD.
• The invoice finalises for 32 USD, but isn’t paid yet.

In this example, the invoice and revenue periods are from 15 January 2019 to 14 February 2019. Although the invoice isn’t generated until 14 February, the 15 USD from 25 January still has to be recognised when the usage was reported. If you looked at the summary after January ends, you might see something like:

If you looked at the summary after February ends and the invoice hasn’t been paid yet, you might see something like:

Max

This example uses the following assumptions:

• On 15 January, a customer subscribes to a monthly metered subscription at 1 USD per unit, and with aggregate_usage=max.
• On 25 January, they use 17 units.
• On 4 February, they use another 15 units.
• On 14 February, the subscription generates an invoice for 17 USD.

In this example, the invoice and revenue periods are from 15 January 2019 to 14 February 2019. If you looked at the summary after January ends, you might see something like:

If you looked at the summary after February ends and the invoice is yet to be paid, you might see something like:

The 15 units recorded on 4 February don’t impact revenue recognition because they’re not the max usage record.

Last during period

This example uses the following assumptions:

• On 15 January, a customer subscribes to a monthly metered subscription at 1 USD per unit, and with aggregate_usage=last_during_period.
• On 25 January, they use 17 units.
• On 27 January, they use 10 units.
• On 4 February, they use another 15 units.
• On 14 February, the subscription generates an invoice for 15 USD.

In this example, the invoice and revenue periods are from 15 January 2019 to 14 February 2019. If you looked at the summary after January ends, you might see something like:

The 17 units recorded on 25 January doesn’t have any impact on revenue recognition because it’s not the last usage record during the period at the end of Jan.

If you looked at the summary after February ends and the invoice hasn’t been paid yet, you might see something like:

The 17 units recorded on 25 January and 10 units recorded on 27 January don’t have any impact on revenue recognition because they aren’t the last usage during the period.

Last ever

This example uses the following assumptions:

• On 15 January, a customer subscribes to a monthly metered subscription at 1 USD per unit, and with aggregate_usage=last_ever.
• On 25 January, they use 17 units.
• On 27 January, they use 10 units.
• On 4 February, they use another 15 units.
• On 8 February, they use another 18 units.
• On 14 February, the subscription generates an invoice for 18 USD.
• On 14 March, the subscription generates another invoice for 18 USD.

In this example, the invoice and revenue periods are from 15 January 2019 to 14 February 2019. If you looked at the summary after January ends, you might see something like:

The 10 units recorded on 25 January doesn’t have any impact on revenue recognition because it’s not the last usage record at the end of Jan.

If you looked at the summary after February ends, you might see something like:

Now in the period of 14 February to 14 March, because there’s no usage record within the period, we recognise 18 USD when the invoice happens. If you looked at the summary after March ends, you might see something like:

Upgrade

This example uses the following assumptions:

• On 1 April, at 00:00 UTC, a customer starts a monthly subscription that costs 90 USD.
• The subscription generates an invoice.
• The invoice finalises on 1 April and the customer pays 90 USD.
• On 21 April at 00:00 UTC, they upgrade to a monthly subscription that costs 120 USD.
  • Two unbilled invoice items are created to represent (1) -30 USD for the unused time of the previous plan and (2) 40 USD for the remaining time of the new plan.
• The next invoice includes the two unbilled invoice items and is finalised on 1 May at 00:00:00 UTC with 3 line items:
  • -30 USD for the unused time of the previous plan with the service period from 21 April at 00:00 UTC to 1 May at 00:00 UTC.
  • 40 USD for the remaining time of the new plan with the service period from 21 April at 00:00 UTC to 1 May at 00:00 UTC.
  • 120 USD for the service in May with the service period from 1 May at 00:00 UTC to 1 June at 00:00 UTC.

If you looked at the summary after May ends, you might see something like:

Downgrade

This example uses the following assumptions:

• On 1 April, at 00:00 UTC, a customer starts a monthly subscription that costs 90 USD.
• The subscription generates an invoice.
• The invoice finalises on 1 April and the customer pays 90 USD.
• On 21 April at 00:00 UTC, they downgrade to a monthly subscription that costs 30 USD.
  • Two unbilled invoice items are created to represent (1) -30 USD for the unused time of the previous plan and (2) 10 USD for the remaining time of the new plan.
• The next invoice includes the two unbilled invoice items and is finalised on 1 May at 00:00:00 UTC with 3 line items:
  • -30 USD for the unused time of the previous plan with the service period from 21 April at 00:00 UTC to 1 May at 00:00 UTC.
  • 10 USD for the remaining time of the new plan with the service period from 21 April at 00:00 UTC to 1 May at 00:00 UTC.
  • 30 USD for the service in May with the service period from 1 May at 00:00 UTC to 1 June at 00:00 UTC.

If you looked at the summary after May ends, you might see something like: