Billing Dates

When subscriptions are added to an aggregation they become aligned to a common bill date. In the following section we discuss how this common bill date is calculated and how this affects billing.

Common Bill Date

A common bill date is needed, such that the aggregated subscriptions generate their cost on the same schedule. Having a common bill date for all the subscriptions provides a number of benefits:

1. Subscriptions create charges for the same billing periods
2. Easier for the customer to understand when they will be billed
3. If charges are produced at the same time it is possible to infer a relationship between their bill dates, and thus to apply volume discounts.

How is this common bill date determined?

The initial bill date is set as the earliest start date of all the aggregated child subscriptions, this date becomes the periodStart of the aggregated and aggregating subscriptions. Subsequent bill dates are calculated based on the billing frequency of the aggregating rate-plan. This is calculated as the periodStart + aggregating rate plan frequency.

For example:
A child subscription is started and invoiced on the 1st of January.

The aggregating rate-plan has a monthly billing frequency. The next invoice will be on the 1st of February

Alignment

As mentioned previously when a child subscription is started an aggregating subscription is automatically created. Let’s work through a number of cases.

Scenario 1: Matching Frequency

Let’s consider when the aggregating and child subscriptions bill at the same frequency, for example monthly.

Month 1

1. Two subscriptions are created in the Provisioned state, let’s call them:
   1. Sub 1
   2. Sub 2
2. Both subscriptions are started:
   1. If you want to start multiple subscriptions concurrently, create them in a Provisioned started and then use the following API call
3. At this point an aggregating subscription is automatically created by BillForward, let’s call this:
   1. Sub A
   2. The ID of Sub A is set on the aggregatingSubscriptionID property of the account.
4. Sub 1 and Sub 2 each produce an invoice, let’s call them:
   1. Inv 1
   2. Inv 2 respectively.
   3. It’s worth noting neither of these invoices are issued to the customer or used to charge the customer.
5. At the same time Sub A generates an invoice, let’s call this:
   1. Inv A
6. Inv A is the aggregation of the Inv 1 and Inv 2, as such all charges which appear on Inv 1 and Inv 2 appear on Inv A
7. Inv A is issued and payment taken.

Scenario 1 example:
An account is setup and the aggregating rate-plan is set.

Two subscriptions for $10.00 are started on the 1st of January.

Two invoices for $10.00 are created, the aggregating subscription then combines these into a new third invoice for $20.00.

>> Fast Forward 1 Month >> 

On the 1st of February each child subscription raises an invoice for $10.00 the aggregating subscription collects these and creates a new invoice for $20.00.