Tax authorities use pay plans as a collections tool. When a taxpayer agrees to be on a payment plan, it is an acknowledgement of his/her tax debt. Pay plans are typically used to satisfy obligations in which the taxpayer cannot satisfy the total obligation with one lump payment.
The pay plan's terms are typically negotiated between the tax authority and taxpayer. The payment amount and specific date intervals of the pay plan include such factors as total obligation amount and the taxpayer’s ability to pay. Payments received are used to satisfy tax, penalty, and interest.
Contents
A pay plan is a special type of payment plan that encompasses two major elements:
· A set of scheduled payments
· The business rules used to recommend the payment schedule
Pay plans are managed via an obligation whose obligation type has a special role of Pay Plan. This type of obligations must have one or more recommendation rules, and are allowed to have payment schedules.
A pay plan's status is just like any other obligation’s status. An active pay plan implicitly has a “kept” status (i.e. all scheduled payments have been made). A stopped plan implies that the pay plan has been completed, i.e. paid off, or stopped due to non-payment. It is important to note that the scheduled payments have their own status.
A list of the obligations covered by a pay plan is maintained with the pay plan. This list is used at payment distribution to determine which obligation to pay. An obligation may be covered by a pay plan when its obligation type is flagged as Eligible for Pay Plan.
Contents
Distributing Payments for Pay Plans
Automatic Payment and Pay Plans
A payment plan can be created as a result of the following scenarios:
· A collections case is created as a result of overdue debt. One of the available actions for the user responsible for the collections case is setting up a pay plan. Refer to The Big Picture of Collection Cases for details on how a collection case can create a pay plan.
· The taxpayer may also voluntarily seek to enter a payment plan. Refer to Maintaining Pay Plans for details on how to create a pay plan manually.
A pay plan is created in a pending start status. For the pay plan to become effective, it needs to be activated. If the pay plan does not require any special approval, the user can activate the pay plan once they have completed setting up the payment schedule. This can be done by navigating to the obligation page, and using the activate button.
If the pay plan requires approval, a different process might be implemented depending on the tax authority’s rules.
When a pay plan is activated, you can perform special processing using an algorithm plugged in on the obligation Activation system event on the pay plan obligation type. The special processing can be developed to do anything that you would like, for example you could:
· Create a customer contact that with an appropriate letter template can generate a letter to inform the taxpayer of their payment amount and payment schedule.
· Initiate the creation of a payment coupon book for a taxpayer.
· In some cases, the taxpayer may be charged a setup fee for the pay plan. See the base algorithm (C1-OT-LEVFEE) for an example.
The system comes supplied with a sample algorithm type (SAAT-CC) that simply creates a customer contact to indicate that the pay plan is activated.
If the taxpayer does not meet their terms of the pay plan, the pay plan is considered broken. A pay plan can be broken in the one of the following ways:
· The user has used the Break action on the pay plan page.
· An automated process, such as monitor algorithm has determined that the taxpayer has broken the terms of the pay plan.
When the pay plan is broken, the pay plan is transitioned to pending stop status.
A base package break pay plan algorithm type (C1-PAYP-BRK) can be used to create a characteristic value to indicate if a pay plan is manually stopped by a user.
In addition, the algorithm type (C1-OT-TPPRVW) will create an account monitor review trigger if the pay plan is not associated with a collections case.
You can plug in an algorithm (of type SAIS-ST) on the obligation Stop Initiation system event on the pay plan obligation type to automatically stop the obligation (i.e. transition it to stopped status).
To finalize a pending stop obligation, the system calls the stop obligation algorithm plugged-in on the obligation Stop system event on the obligation type.
If the taxpayer pays off the outstanding debt, the pay plan is considered stopped. A pay plan can be stopped in one of the following ways:
· The collection case that created the pay plan was closed as a result of the taxpayer paying off the debt, and updates the pay plan to pending stop.
· An automated process, such as monitor algorithm has determined that the taxpayer has paid off the debt, and updates the pay plan status to pending stop.
As indicated above, an algorithm can be plugged it to transition the pay plan immediately from pending stop to stopped.
A pay plan may need to be cancelled under certain circumstances that are initiated either by the tax authority or the taxpayer. For example:
· A user may need to cancel an erroneous pay plan after it has already been activated.
· A tax authority may cancel pay plans (en masse) in the event of natural disasters.
· When a taxpayer indicates additional hardship, the procedure may involve canceling the existing pay plan and renegotiating a new pay plan.
Canceling a pay plan causes the pay plan status to change to Cancelled. Any specific actions that need to take place can be plugged in on obligation Cancel system event. The base package algorithm type (C1-OT-CRCC) can be used to create a customer contact when the pay plan is cancelled. Alternatively, (SACA-CRTODO) can be used to create a to do entry when the pay plan is cancelled.
For pay plans, payments are distributed directly to the covered obligations using payment distribution rules. A tax authority's business processes will dictate the distribution of payments to the corresponding obligations. For example:
· A tax authority wants payments to be applied to the oldest obligation first. It them moves to the next oldest obligation until all obligations are satisfied. The oldest obligation is given highest priority.
· A tax authority wants payments to be applied to obligations attached to an active collections case. The obligations linked to a collections case are assigned highest priority.
· The base-package provides an algorithm that will distribute payments to obligations covered by a pay plan based on age of debt, and priority indicated on the obligation type (C1-DR-PAYPP).
Refer to Payment Event Distribution Rules for details.
In addition to the pay plan having a status, the scheduled payments each have their own status. A scheduled payment is created in a pending status when the pay plan is activated.
Each scheduled payment is reviewed by the base base-package batch C1-PAYPS on the payment due date. The batch will set the scheduled payment status to processed after executing the Process Pay Plan Scheduled Payment plug-in defined on the obligation type.
This plug-in can contain specific business logic that need to be executed when a scheduled payment is due. Based off the rules that will be configured by the tax authority, a multitude of actions can occur. They range from giving the taxpayer a few extra grace days to make the payment to canceling the current payment plan and forwarding the obligations to a collections authority. A tax authority’s business rules as well as each taxpayer’s personal history and circumstances should be taken into account when determining what actions to take next.
The base-package provides an algorithm (C1-CC-CHKSPP) that will create a to do if a scheduled payment has not been paid. It will also detect when actual payments have fulfilled the pay plan in advance.
If your implementation’s rules require additional status values (e.g. kept, late, partial), you will need to do the following:
· Create your own copy of C1-PAYPS.
· Add custom values to lookup NB_SCHED_PAY_STATUS_FLG.
If a taxpayer wants to pay their pay plan scheduled payments automatically, the account must be set up for automatic payment. In addition, the pay plan must indicate that automatic payment is being used.
Refer to How To Set Up Automatic Payment For A Pay Plan for more information.
When this is done, a background process referred to as C1-PAYPA creates automatic payments on the scheduled payment date by calling the automatic payment creation algorithm plugged in on the installation record.
The base-package provides two auto pay creation algorithms that support pay plans scheduled payments:
· Use algorithm type APAY-CREATE if your implementation distributes payments using the standard account type payment distribution.
· Use algorithm type C1-APAY-CRDR if your implementation distributes payments using distribution rules.
The system provides alerts to highlight the existence of pay plans. These alerts are important to assist the tax authority’s users:
· An alert is displayed if the account has a pay plan that is not stopped (e.g. pending start, active or pending stop).
· For taxpayers who are permanently forbidden from having a pay plan, the user should put a permanent alert on the account.
· Use an algorithm to highlight cancelled pay plans with an entry in the alert zone. The algorithm type to do this is not provided. Use C1-STOP-SA as an example of how to create this type of algorithm.
· Configuring a specific customer contact type with the alert algorithm type (CC BY TYPCL) can cause alerts to be displayed whenever a user adds a customer contact of this type. This method can be used to highlight special conditions relating to the pay plan.
For more information about introducing alert conditions on Control Central, refer to Installation Options - Algorithms.
The topics in this section describe functionality that you must consider when designing pay plans.
Contents
Designing Recommendation Rules
Setting Up The System To Enable Pay Plans
This section describes topics related to designing your recommendation rules.
Contents
What is a Pay Plan Recommendation Rule
Examples of Recommendation Rules
Generate Payment Schedule Algorithm Types
Penalty and Interest Considerations
Users ask the system to recommend the scheduled payments for a pay plan. In general, this recommendation process must establish:
· The amount to be paid
· The dates on which the payments are due
A recommendation rule comprises of three elements:
· Payment schedule algorithms
· An algorithm to calculate an average daily amount. This is optional. If this plug-in must be used, it should be invoked from your payment schedule algorithms
· A collection of default parameter values for the payment schedule algorithm type
The default parameter values for the payment schedule algorithm type may change over time, so the collection contains an effective date. If default values are changed, these changes do not affect pay plans already in effect. Existing pay plans keep the parameter values that were used when the pay plan was started.
A user may override the default parameter values for the payment schedule algorithm type to customize the schedule if an override is allowed for a parameter. Additionally, a user may edit the payment schedule details at any time (provided the payment has not yet been processed).
Note. Normally parameter values for an algorithm type are kept with the algorithm. Because the parameters may vary for each pay plan, while the same algorithm logic is used, the parameter values are kept with the pay plan.
The following are two common methods of calculating a schedule of payments:
· Taxpayer knows how much and when they can pay. The recommendation rule will calculate the schedule of payment dates given the fixed payment amount, frequency, and the first payment date. For example: monthly payments of $1,000 beginning on August 1, 2007.
· Taxpayer knows when they would like to pay the debt by, and how often they can pay. The recommendation rule will calculate the schedule of payment dates and payment amounts given the first payment date, the last payment date and the frequency. For example: monthly payments to be made starting on August 1, 2007 and ending on February 1, 2008.
The core of the pay plan recommendation rule is the Generate Payment Schedule plug-in. The base-package provides two methods for generating a payment schedule: a fixed amount schedule or a fixed duration schedule. Both methods incorporate forecasted penalty and interest charges into the calculations of scheduled payment amount. For more details on these plug-ins see the following:
· A fixed amount payment schedule C1-PP-FIXAMT.
· A fixed duration payment schedule C1-PP-FIXDUR.
If penalty and interest (P&I) rules are applicable to the obligations covered by a pay plan, the payment schedule that is generated by the recommendation rule's generate payment schedule algorithm should factor expected penalty and interest calculations.
The penalty and interest plug-in spot may be called in forecast mode to forecast the charges to a certain date in the future. The plug-in spot also supports receiving financial transactions supplied by a calling service allowing for "what if" scenarios to be supplied. For example, when forecasting P&I to the future, the generate payment schedule algorithm can include proposed scheduled payments along with existing financial transaction to the P&I algorithm to get a more accurate estimate of the future P&I charges.
The above topics provided background information about how pay plans are supported in the system. The topics in this section describe how to set up the system to enable pay plan functionality.
Customer Contact Class And Types
Defining a Pay Plan Recommendation Rule
If your implementation requires a characteristic added to the pay plan when the pay plan is broken, you will need to create a characteristic type that specifies obligation as its characteristic entity.
If your implementation requires certain customer contacts and/or letters created when the pay plan is activated or stopped, you will need to create appropriate customer contact class and customer contact type(s).
If you want to send letters to your taxpayers when a contact of any of these types is created, you must create an appropriate letter template and attach it to the customer contact type.
As described above, in The Big Picture of Pay Plans, the base package provides a number of algorithm types for different system events in the pay plan’s lifecycle. In order to use any one of these algorithm types, you will need to create an associated algorithm and ensure any required parameters are populated.
If your implementation created additional custom algorithm types, you will also need to define associated algorithms.
Recommendation rules are used to recommend scheduled payments for pay plans. To define recommendation rules, navigate to Admin Menu, Pay Plan Recommendation Rule.
Description of Page
Enter an easily recognizable Recommendation Rule code and Description for each recommendation rule.
If applicable, specify the Average Daily Amount Algorithm used to calculate the average daily amount for this recommendation rule.
Specify the Payment Schedule Algorithm Type used to create the recommended payment scheduled for pay plans that use this recommendation rule. The Payment Schedule Algorithm Type cannot be modified if a pay plan that is not stopped or cancelled is using this recommendation rule.
Payment Schedule Parameters enables you to define collections of default parameter values for the payment schedule algorithm type that are effective dated. For each collection:
· Effective Date defines the date on which the collection of parameter values becomes effective.
· Pay Plan Rule Parameter Value specifies the default value of each parameter supplied to the algorithm. Note that the payment schedule algorithm type controls the number and type of parameters.
· Override Flag indicates whether the user can override the default value for the parameter.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_NB_RULE.
This section provides information about setting up the obligation types for the pay plan itself and the obligation types for covered obligations.
Contents
Obligation Type for Obligations Covered by Pay Plans
Consider which types of obligations need to be covered by a pay plan. For each obligation type that should be allowed to be covered by a pay plan, ensure that the Eligible for Pay Plan flag (on the Billing page) to Eligible.
In order to enable pay plan functionality, you will need to define an obligation type that is suitable for a pay plan. Depending on the business rules of the tax authority, you may need multiple pay plan types, which will require you to define multiple obligation types. For example you might want to create a pay plan type for individual taxpayers, and a different pay plan type for a business.
The following points provide guidelines for creating a pay plan obligation type:
Contents
Obligation Type - Pay Plan Recommendation Rule
Tax Type should either reference a specific tax type or a generic tax type (e.g. miscellaneous fees) depending on your authority’s business rules.
Revenue Class should be set to N/A. (Revenue classes are not applicable because pay plans do not apply a rate and revenue classes are only relevant for obligation types that use a rate.)
The Payment Segment Type should reference the Normal Payment.
Do Not Overpay should be on. Payments are not distributed directly against the pay plan.
Special Role is Pay Plan.
Eligible for Billing flag should be off, as pay plans do not get billed.
Additionally, the Characteristic Location Required should not be checked for pay plans.
Eligible for Pay Plan should be set to Ineligible. This option only applies to the obligation types that can be covered by a pay plan.
Pay plans do not use rates, so the Rate Required flag should be off.
Plug in any algorithms defined above for the following system events:
· Break Pay Plan
· Initiate Stop
· Obligation Activation
· Obligation Cancel
· Obligation Stop
· Process Pay Plan Scheduled Payment
Obligation Type - Pay Plan Recommendation Rule
Add the recommendation rules defined above that are valid for obligations of this type. Also, indicate which recommendation rule should be used as the default.
Ensure that the following background processes are scheduled:
· Pay Plan Scheduled Payment Processing (C1-PAYPS)
· Pay Plan Scheduled Payment Automatic Payment Create (C1-PAYPA)