Arrears Overview

This article describes the relationship between aggregation and arrears charges

So far out examples have discussed billing in-advance, though the concepts apply to advance and arrears billing there are a couple of provisos to watch out for. The following section discusses how to deal with arrears and usage billing with regards to aggregation.

Usage

The cancellation and failure behavior for aggregated subscriptions is the same as if they were non-aggregated subscriptions. That is their service end is dictate by their failed payment behavior and how they were cancelled. The same notifications are sent as in the non-aggregated case.

Arrears

The aggregating subscriptions life-cycle is related to that of it’s children subscriptions. The aggregating subscription will continue to exist until all the aggregated subscriptions have come to an end. Thus once the service end date of aggregated subscriptions has passed the aggregating subscription will end.

This means that over the life-time of a subscription there may be multiple aggregating subscriptions. This allows for re-alignment of the common billing date.

Scenario 1: Cancellation

Timeline chart

Time: P0

1. One subscription is started at the start of January let’s call it:
   1. Sub A
   2. This subscription costs $10/month, an invoice is raised for $10.00.

Time: P1

1. After one month Sub A recurs.
   1. Another invoice is raised for $10.00

Time P1.5

1. After half a month a new subscription, Sub B, is started.
   1. Sub B cost $20/month
   2. As the next billing date will be the start of March (P2) Sub B is automatically aligned to March.
   3. A invoice is generated for Sub B, this is for the time P1.5 -> P2, half a billing period. As Sub B charges $20/month an invoice for $10 is raised.
      1. monthly cost * pro-ration = invoice cost
      2. $20.00 * 0.5 = $10.00

Time P2

1. At the start of March both Sub A and Sub B generate invoices, for $10 and $20 respectively
2. Both invoices are aggregated together and a final invoice for $30.00 is issued.

Scenario 2: Failed Payment

Timeline

Time: P0

1. One subscription is started at the start of January let’s call it:
   1. Sub A
   2. This subscription costs $10/month, an invoice is raised for $10.00.

Time: P1

1. After one month Sub A recurs.
   1. Another invoice is raised for $10.00

Time P1.5

1. After half a month a new subscription, Sub B, is started.
   1. Sub B cost $20/month
   2. This time the period is created with alignPeriodWithAggregatingSubscription property set to false. This causes the subscription to start with one full billing cycle. API call
   3. An invoice is issued for $20

Time: P2

1. At the start of March only Sub A generates an invoices for $10, this is because Sub B is still not aligned to the common bill date.
   1. Another invoice is raised for $10.00

Time: P2.5

1. As the next billing date will be the start of April (P3) Sub B is automatically aligned to April.
2. A invoice is generated for Sub B, this is for the time 2.5 -> P3, half a billing period. As Sub B charges $20/month an invoice for $10 is raised.
   1. monthly cost * pro-ration = invoice cost
   2. $20.00 * 0.5 = $10.00

Time P3

1. At the start of April both Sub A and Sub B generate invoices, for $10 and $20 respectively
2. Both invoices are aggregated together and a final invoice for $30.00 is issued.