For native collection methods, the platform handles core parts of the billing lifecycle, from calculating the amount due on a policy, raising the premium, generating collections, and updating the policy balance based on the collection result. If you are using Collection Modules, the lifecycle of your collections is handled by the collection module code that you define. See Root lifecycle events for more information.

In the event of failed collections, the platform will automatically lapse policies (or mark them as "not taken up") according to the lapse rules that you can configure on a product-by-product basis. You can read more about how to configure lapse rules for your product in the general product settings guide.

Collection lifecycle summary

The Root billing lifecycle is summarised below at a high level. These steps are generally completed at a daily interval.

• Raise premiums - The platform determines which policies are due to be billed based on their billing day, and debits the policy ledger with the amount due. Root supports monthly billing (policyholder can choose on which day of the month to be billed), yearly billing (policyholder can choose the day of the month and the month of the year to be billed) and once-off billing (policyholder can choose which date to be billed).
• Create payments - The platform will create collections to be actioned. The type of collection created for any given policy will depend on the outstanding balance, the policy's collection history and the collection method linked to the policy. Examples of different types of collections include:
  • Recurring collections - A policy's monthly or yearly premium that has most recently been raised.
  • Arrears collections - Outstanding payments that were missed prior to the current billing period.
  • Pro rata collections - Platform creates one-off pro rata collections when the policy's billing day does not match the policy start date.
  • Ad hoc collections - Dashboard users (agents) can create ad hoc collection requests for policies.
• Review collections - Before collections are submitted to the payment provider, the Root platform performs a set of automated checks to ensure the accuracy of the collection.
• Submit payments - Collections are submitted to be actioned by a collections provider, which will depend on the type of collection method linked to the policy.
  • Collection modules - When using collection modules, payments are submitted according to the requirements of the specific payment integration defined in the collection module.
  • Native debit orders - For native Root debit orders, Root will submit the payments to Nedbank to be actioned, taking into account the required process times for different types of debit orders.
• Process payment responses - Depending on the payment provider, Root receives the responses via a callback endpoint or a flat file. The platform will update the collection status and, in case of a successful collection, add a corresponding credit entry to the policy ledger.

📘

Payments are assumed to have been successful after five days

The Root platform automatically assumes that a payment was successful if it does not receive a payment failure notification within five days.

If a failed payment notification is received more than five days after the submission date, the platform will create a corresponding payment reversal, and debit the policy ledger with the outstanding amount.