Billing Cycles
The billing cycle specification associated with a subscription is retrieved from a predefined billing profile template in the subscription wallet. The template is created as part of pricing configuration and forces all billing cycle pricing associated with the subscription to be applied with the same cycle settings. Each wallet can contain only one billing profile template. Define billing cycles in billing profile templates in My MATRIXX.
Billing Cycle Processing
- n days
- n weeks
- n months
- n years
For example, you can define a quarterly billing cycle by setting the period to 3 months so that once every 3 months (4 times a year), billing occurs. All recurring processing is performed on the defined billing cycle. If a wallet does not have a billing profile template, billing cycle processing is not performed.
The BillingIntervalId in SubMan API query responses identifies the specific billing interval for billing cycle information. The ID increases by one for each later
interval. For example, if the current interval is 1, the NextBillingCycle
BillingIntervalId is 2.
BillingCycle field of type MtxBillingCycleData. MtxBillingCycleData has a BillingCycleAlignment field that
specifies whether the bill cycle boundaries are aligned with the subscription or group time zone or with the system time zone. The possible values for this field are:- 1 — Cycle boundaries are at midnight in the subscription or group time zone.
- 2 — Cycle boundaries are at midnight in the system time zone.
MtxBillingCycleChangeEvent show the configured billing cycle
alignment option:BillingCycleAlignmentBefore(this field is not used to initially set up a bill cycle).BillingCycleAlignmentAfter.
The possible values for these fields are the same as the BillingCycleAlignment field.
For more information about configuring billing cycles and managing billing cycles, see the discussion about billing cycle management in MATRIXX Pricing and Rating. For more information about changing billing cycles using the SubMan APIs, see MATRIXX Subscriber Management API.
Changing Billing Cycles
After a bill cycle is established for a subscription or group, a different billing cycle can be
specified. However, only the offset of the billing cycle can be changed, not the
period length. For example, you can change a subscription's billing cycle from the
first of every month to the fifteenth of every month, but not from monthly to
weekly. A cycle offset change takes effect at the end of the existing cycle unless
the SubMan call specifies that the change occurs immediately
(ImmediateChange is true). Any balances
aligned with the billing cycle are realigned with the active billing days.
Using the SubMan SubscriptionModify and GroupModify APIs you can change a billing cycle and have the change be applied immediately in the current billing cycle. When a billing cycle is changed, an MtxBillingCycleChangeEvent event is generated. If the current cycle is shortened, an MtxPeriodTerminationEvent Event Detail Record (EDR) is generated. The period termination proration policy defined in product offer cycle data is applied to generate refunds and forfeitures for the terminated period. For more information about period termination, see Period Termination. For more information about proration, see Billing Cycle Proration. For more information about changing billing cycles using the SubMan APIs, see MATRIXX Subscriber Management API.
When specifying a billing change to occur immediately, the new offset and the current time determine how the current billing cycle is changed. The following examples describe how the new billing cycle is applied. In each example, the current offset is the 20th day of the month, and the current billing cycle is from March 20 to April 19.
After a billing cycle change, the short period after the current period is applied to the balance rollover. No refund occurs for a cancellation or forfeiture on rollover balances when a period is terminated early.
An MtxBillingCycleChangeEvent EDR is generated to record the requested change of the billing cycle definition. The EDR includes the start date and end date of the next billing cycle.
New Offset is before Old Offset and after Current Day
On April 5, the subscriber requests to change the offset to the 10th. The current billing cycle is terminated on April 9. The next billing cycle starts on April 10 and ends on May 9. An MtxBillingCycleChangeEvent and MtxPeriodTerminationEvent are generated.
New Offset is before Old Offset and before Current Day
On April 15, the subscriber requests to change the offset to the 10th. The current billing cycle does not change. The next billing cycle starts on April 20 and ends on May 9. An MtxBillingCycleChangeEvent EDR is generated.
New Offset is before Old Offset and the Same as Current Day
On April 10, the subscriber requests to change the offset to the 10th. The current billing cycle is terminated on April 10. The next billing cycle starts on April 11 and ends on May 9. An MtxBillingCycleChangeEvent and MtxPeriodTerminationEvent are generated.
New Offset is after Old Offset and before Current Day
On April 5, the subscriber requests to change the offset to the 25th. The current billing cycle does not change. The next billing cycle starts on April 20 and ends on April 24. An MtxBillingCycleChangeEvent EDR is generated.
New Offset is after Old Offset and after Current Day
On March 23, the subscriber requests to change the offset to the 25th. The current billing cycle is terminated on March 24. The next billing cycle starts on March 25 and ends on April 24. An MtxBillingCycleChangeEvent and MtxPeriodTerminationEvent are generated.
Period Termination
Period termination can be delayed by answering the following system configuration question: Global:How long (in minutes) should period termination be delayed? The default value in minutes is 240 (4 hours). The maximum value in minutes is 1320 (22 hours).
- When a billing cycle period ends, usage charges for the preceding period can still be charged to the preceding period. This question determines the period of time during which usage charges for the preceding period can still be charged to the preceding period. This question also determines when the MtxTransferToBilledAREvent EDR is generated after the end of a bill cycle period.
- When the current period is terminated early due to a billing cycle change, the subscription receives a refund of recurring charges prorated to the period termination time. This question determines the number of minutes to wait for late arriving events before terminating a period due to billing cycle change. When the period is terminated early due to a cycle change, an MtxPeriodTerminationEvent EDR is generated at the end of the terminated period. The event includes the amount of the refund cancellation and forfeiture cancellation. For information about proration, see the discussion about billing cycle proration that follows.
- When usage or charges for a period of a periodic meter increment that period after it ends (for meters that are configured to close periods). This question determines the delay during which the period is incremented. When the delay time ends, an MtxMeterPeriodCloseEvent EDR is generated.
For more information about this property and configuring other global system properties, see the discussion about global system configuration in MATRIXX Configuration.
Billing Cycle Proration
When a period termination of a balance cycle or a billing cycle occurs due to a change in a billing cycle definition, a certain length of time is subject to the proration of charges and grants that are applied to handle the change in the billing cycle length. This period is either shorter or longer than the usual period for that cycle. For example, if a monthly billing cycle changes in August from the 1st of the month to the 11th of the month, the period starting on September 1st is 10 days (through September 11th) or 40 days (through October 11th). The period to use is configured as part of configuring the MATRIXX Engine. You configure the period termination proration policy in product offers to define how the refund of recurring charges and forfeiture of recurring grants is calculated.
When the current period is terminated early, the subscription receives a refund for recurring charges and forfeits recurring grants prorated to the period termination time. A refund or forfeiture due to period termination is applied to the balance intervals that are active at the end time of the terminated period. If the amount to be forfeited is more than the available balance amount, the forfeiture amount is reduced to the available balance amount. If a postpaid main balance is used to pay for recurring charges, and period termination is configured to occur after the balance for the terminated period is transferred to accounts receivable, the refund due to period termination is included in the balance for the next billing period.
Disabling of Billing Cycles
When billing cycles are disabled, no recurring processing is performed on any periodic balances having periods that are aligned with billing cycles.
Billing cycles can be disabled only if no postpaid main balances are in the wallet.
When billing cycles are enabled again after being disabled, a billing cycle is started immediately and the current day becomes the first day of the billing cycle. Periodic balances having periods that are aligned with billing cycles are updated to follow the new billing cycle definition. However, no balance refund or forfeiture occurs due to the duration change of the current periods.