Table of Contents
Updated by Mitchell Paul-Soumis
Delinquency in Sonar
A single invoice (or even multiple invoices) can become delinquent without affecting the account status. An invoice being delinquent simply means the amount was not paid prior to the due date. Until the Grace Period has elapsed, the account status will not change.
Delinquency in Sonar is a term used in two parts - First, the invoice becomes due, then after a certain period of time - defined as Grace Days - the account becomes Delinquent, which triggers the process flow below.
Invoice Delinquency and Account Delinquency combine functions from multiple portions of the settings page. The primary features you'll be interacting with to establish Delinquency Billing are:
- Account Statuses - Creating an account status for Delinquent Customers. You can learn more about creating an Account Status here
- Address Lists - These will be used to disconnect delinquent customers after a long-period of non-payment, automating the process of taking a delinquent customer and removing them from your network. For more information on address lists, see the article here
- Delinquency Checks, and Delinquency ExclusionsTo have a delinquency exclusion be applied every year, leave the Year field blank when setting up the exclusion.
- Delinquency Grace Periods, configured under Billing Defaults
- Late Fees and reconnection fees
- In the screenshot below we have an account whose invoice is created on the 1st of each month and 15 days later (16th of each month) the invoice becomes due. If the customer has not paid their invoice on the 16, the invoice is considered hast past its due date but not yet delinquent. On the 21st of each month (5 days past the due date) if the customer has still not paid off that invoice, the invoice becomes delinquent and thus moving the account to a delinquent status. If the customer requests additional days to pay off the invoice, you can use the Grace Until section to change the date when the account becomes delinquent.
- Under the Billing Default you're creating for your customers, ensure "Switch status after delinquency" is checked and complete all required fields below:
In this example, we've set Days of Delinquency for Status Switch to 7 days for a very important reason - to ensure the customer does not have another bill run when they're already delinquent, the status must switch before the end of the month. With these parameters, the Account will become inactive the 28th of the month, which means that no matter which of the year the customer is behind, the status will always switch in time for the next billing run.
Process Flow details
In Sonar, there's a flow for Billing and for Delinquency Billing. In our example, this flow begins on the 1st of the month. The Sonar system will check the account's current status against the list of account statuses which activate accounts. If the account in active, then billing runs, tallying the services and discounts into an invoice.
From there, assuming no payment is made until the Due Day has arrived, Invoice Delinquency checks will occur. At this point, the provided Grace Days will begin counting down before the invoice moves into a Delinquent state.
Once the Grace days have elapsed, the Account enters Delinquency. It's at this stage that the system will check against any Delinquency Exclusions for specific dates or days of the week. If there are none, the account becomes delinquent, if not, then the account becomes delinquent at the following opportunity.
At this point, the account is placed into the Delinquent Address list, and the final countdown to the status switch occurs.
Best Practices or Why you should use Delinquency
The ultimate goal of delinquency in Sonar is to encourage some kind of action from the customer, and as delinquency is a result of non-payment the desired action is re-payment of past due balances. Using the Delinquency settings built in to the Billing Parameters should be one of the tools to encourage the desired action.
Generally speaking, effectively using the Delinquency Billing parameters requires some thought in order to ensure the actions being taken will force the customers down the right path. It may be helpful to frame Delinquency as the number of days you're willing to let your customer be late before assuming they won't be paying you, and once those days have elapsed, some action should be taken. When making use of the "Switch status after delinquency" toggle in the Billing Parameters, the Delinquency Account Status should trigger in advance of the next bill due date in order to prevent the customer from paying for an additional month of service for which they'll receive no service.
Rather than taking a passive approach, which is to say simply sending out payment reminders and adding late fees, you can leverage Sonar to take a more active approach the the customer's delinquency. Below, we'll look over some potential scenarios that leverage Delinquency effectively, and explain both the driving force, and the desired action.
Using the Delinquent Status to slow down the connection
The first scenario we'll look at will touch on using Address Lists in greater detail. This scenario was briefly touched on in the Process Flow Details section, but we'll expand on what's involved and how to do it here.
For this scenario, we're going to leave the delinquent accounts active in order to explore a commonly used method of driving our desired action, which is payment of the delinquent amount. This method is to use Address Lists in order to control the customer's speed. The goal here is to create a connection slow enough that basic usability is reduced, but with enough speed that loading the customer portal or their bank account to make a payment is still doable. This encourages the customer to pay in order to restore their full speed in two ways:
- By slowing down their internet rather than cutting the connection abruptly, a sense of goodwill is fostered with the customer without placing on undue burden on your network backhaul due to the reduced speeds.
- If the customer is somehow unaware of their delinquency, slowing down their connection is likely to make them call in in order to troubleshoot connectivity, which will in turn allow you and your support staff to gently remind them of their delinquency and collect payment
Creating the Address List
In order to create an Address List which will handle delinquent customers, go to Settings > Networking > Address Lists, and click on Create Address List
Once that's done, and you have the Create Address List window open, we're going to be creating a very basic Delinquent Address List
This Address List will apply only to delinquent customers, and using it, we can design a policy on the Inline Device which will reduce speeds for customers which are delinquent
Using Status Switching to deactivate an account
This second scenario will look at the configuration of Billing Defaults as this policy would apply across your instance, and cover the most common Delinquency scenario, which is infrequent delinquency across your entire customer base. However, it remains prudent to have some delinquency system in place, as presuming that no customers (or very few customers) will become delinquent will create a larger workload down the line as you grow and scale.
For this scenario, we'll assume that you're utilizing RADIUS for authenticating and delivering service to your customers. For this catch-all Billing Default, which we'll be applying to Residential Accounts, we'll enable status switching after delinquency, and set the Days of Delinquency for Status Switch to 7 days. This is done for two reasons:
- Delinquency checking
- Billing Defaults
Additionally, we also want to make sure we're setting a Delinquency Account Status. In the screenshot provided in the first section of this article, the Delinquency Account Status is simply set to "Inactive", which while it is functional doesn't describe the intended purpose of the status. In this instance, we'll proceed with creating a new account status, named "Delinquent".
In this scenario, we're deactivating delinquent accounts in order to both remove their current service and prevent them from being billed for service they won't be receiving.
This method is an escalation of the previous scenario where customer connections were slowed down, and is designed as a final measure to when slowing down the connection, sending reminders, and charging late fees doesn't work to drive action on the customer's account.