An overpayment occurs when the payment(s) exceeds the liability in an obligation, causing the obligation's balance to become a credit. Not every obligation that is in credit is considered to be an overpayment. This will typically depend on the tax type and the authority’s rules.
Contents
The Big Picture of Overpayments
Setting Up Overpayment Options
For return-based taxes, such as individual income tax, a credit balance will be considered an overpayment only once a return is filed. Any payments or credits received in advance of a tax return are not considered overpayments until the tax form is processed, and an assessment is created. If a tax return is not filed, the obligation will be in a credit balance until the tax authority reviews it.
For billing-based taxes, different rules may apply to determine if an obligation is overpaid.
The following are common scenarios that would result in an overpayment:
· A majority of taxpayers receive refunds for their individual income tax filing because employer withholding tends to exceed the probable liability.
· Recalculation of tax, penalty, interest or fees that results in a reduced liability.
Not all tax types have overpayments. Assessments for sales tax and withholding tax are seldom overpaid because the taxpayer pays for an activity that has already happened. If an overpayment results, it is usually due to a math error on the form.
Contents
An Overpayment Process Can be Created Automatically or Manually
An Overpayment is Typically Reviewed
Not all Overpayments Result in a Refund
Individual Taxpayer Overpayment Process
An overpayment process can be created in a variety of ways:
· As a result of posting a return. A form rule related to the posting system event could be used to create an overpayment process if the form reports a refund.
· An account monitor rule can be designed to create an overpayment process when the obligation’s balance is a credit and a return has already been filed. The base-package provides the algorithm Initiate Overpayment Process (C1-CC-INITOP) that can be plugged in on the Collection Class Overdue Rules. For more information on how account monitor rules can be configured for overpayment, see Overdue Rules Are Embodied In Algorithms.
· An overpayment process can be created manually by selecting Main Menu, Financials, Overpayment Process.
When an overpayment is identified, it typically goes through a review process, which may include a combination of automated checks and user review and/or approval.
Examples of review activities include:
· Processing Rules - these can include checking for a valid mailing address, verifying bank account details.
· Compliance Rules - these include specific criteria defined by the tax authority for overpayments that require additional review.
· Minimum Balance - the overpayment amount is compared against a minimum threshold amount to determine whether the overpayment should be processed.
· Risk-based thresholds and overrides - if the overpayment amount is greater than a predefined maximum threshold, it may require special handling and additional approval.
· Suppression - an overpayment may be suspended if an account is under investigation for other debt or another reason.
· Separation of Duty - the tax officer approving the refund must be different from the tax officer who changed the account’s bank information.
The review rules may differ with each tax authority and tax type. However, the end result is the same: to determine whether the overpayment can be processed further.
Before an overpayment is refunded to the taxpayer, some or all of the overpaid amount may be offset against other existing debt, carried forward to a future period, and/or contributed to designated charitable funds or organizations.
Before any other action is taken, it might be required to calculate interest on the overpayment amount. The calculation rules will differ by tax authority and by tax types. The base-package is supplied with the following algorithms to calculate interest:
· Calculate interest using a rate-able adjustment (C1-OP-CALINT)
· Calculate interest using a rate factor (C1-OP-INTRF)
When an overpayment is offset, the credit is used to extinguish other debts. The order of allocation of overpayment amount to debt depends on the tax authority’s rules. Typically, the credit is applied in the following order:
· Within the same assessment
· Other assessments within the obligation
· Other obligations under the same account
· Other accounts for the taxpayer
In some cases, a tax authority may also allow offsetting against debt from other agencies. This type of debt is called external debt.
Where offset is possible, it is done before attempting to contribute, carry forward or refund. Offset is not allowed on future obligations, but a carry forward is done instead.
The base-package is supplied with an algorithm (C1-OP-OFFST) to offset credit to other obligations.
Taxpayers may opt to pay an amount of an overpayment to a future period. This is known as carry forward. This is common to individual income tax filing, where the taxpayer can indicate on the form a designated amount that will go to the next filing period (next tax year).
A tax authority’s rules may designate certain tax types to only allow overpayments to be carried forward. Some common examples include excise or sales and use taxes. In these cases, the entire overpayment amount is carried forward.
The base business object includes an algorithm (C1-OP-CAFUFP) to carry forward to a future period.
Most tax forms provide an option to contribute to a charitable fund/organization. The taxpayer indicates a specific amount to contribute to each selected fund/organization. The contribution is made only if an overpayment exists.
The base business object includes an algorithm (C1-OP-ACNAMT) to create contributions.
Refunds result after attempts to offset, contribute and/or carry forward. The credit amount is given back to the taxpayer in the form of a paper check or a direct deposit. The taxpayer could either authorize a one-time direct deposit by putting bank account information on the tax return or indicate a recurring direct deposit for all refunds. In the case of a recurring direct deposit, the bank account information stored for the taxpayer on the account will be used.
The base business object includes an algorithm (C1-OP-CREREF) to create a refund.
The base product includes the business object C1-OvrpyProcAutoCredRef, which is designed to cater for overpayment processes typical of individual taxpayers.
Contents
The Overpayment Process Lifecycle
Enabling the System to Use Individual Income Overpayment Process
The lifecycle of the overpayment process depends upon the configuration of the associated business object. The Individual Taxpayer Overpayment Process has a lifecycle typical of overpayments for individual taxpayers:
· The overpayment is initially validated against a number of business rules. The overpayment amount would typically be compared against a minimum threshold write-off amount.
· If issues are detected during validation, the overpayment will transition to an issues detected/error state. The user will be able to see a list of issues and correct them.
· The overpayment may require approval(s). The threshold amounts and approval roles will be defined on the overpayment type. A user can approve or reject the overpayment.
· Once all the required approvals have been obtained, certain actions will take place such as offset, carry forward, contributions and/or refund.
Refer to the C1-OvrpyProcAutoCredRef Business Object metadata for more details.
An overpayment process typically requires one or more levels of approval before any financial activity can take place.
Contents
An Overpayment Process Typically Requires Approval
To Do Entries Are Created To Notify Approvers
Monitoring and Escalating Overpayment Approvals
Rejecting Transitions the Overpayment Process to a Final State
If the overpayment process type defines an approval hierarchy, users will need to approve the overpayment process in order for the process to continue. When the overpayment process is in the Approval in Progress state, two action buttons will appear: Approve and Reject.
If the user chooses to reject the overpayment process, they will be prompted for a reject reason.
When the overpayment process detects an approval is required, it notifies the first approver by creating a To Do entry. The To Do entry is created using the To Do type and To Do role defined on the overpayment process type. All users who belong to the approving To Do role can see the entry. When a user drills down on an overpayment approval To Do entry, the overpayment process portal is opened. This portal contains summary information about the overpayment process. This portal is also where the user approves or rejects the overpayment process.
When the user approves the overpayment process, the To Do entry is Completed and the overpayment process’s log is updated. If there are no higher levels of approval required, the overpayment process will transition to the Approved state. If there are higher levels of approval required, a new To Do entry is created to the next To Do role in the approval hierarchy.
To Do entries can create email. A To Do entry can be configured to create an email message for every user in the To Do role to inform the user(s) of new overpayment processes requiring their attention. Refer to To Do Entries May Be Routed Out Of The System for the details.
The base-package is supplied with an algorithm that your implementation can use to monitor overpayment approval requests that have been waiting too long for approval. This algorithm can complete the current To Do entry and create a new one for a different role when the timeout threshold defined on the algorithm's parameters is exceeded. If you've configured the system to send email for approval, this algorithm can also send x reminder emails (where x is defined on the algorithm's parameters) before the approval request is escalated to the new To Do role. Refer to C1-OP-CHKOTO for more information about this algorithm. If you plan to enable this functionality, plug in your configured algorithm on the Approval In Progress state on the C1-OvrpyProcAutoCredRef business object.
When an overpayment process is being approved, anyone with the right level of access can reject it by using the overpayment approval zone.
When an overpayment process is rejected, the following takes place:
· The user is prompted for a reject reason.
· The overpayment process’s log is updated with the reject reason and the overpayment process is moved to the Rejected state.
To enable this functionality the following configuration tasks are needed:
· Various adjustments are used for calculating interest, write off and offset for the overpayment process. For each of these actions, a suitable adjustment type is required.
· If you wish to specify a minimum amount threshold for the overpayment process, you will need to define a non-calculated adjustment type for the minimum amount write-off.
· If your implementation rules specify that interest should be calculated and the interest is calculated using a rate, you will need to define the following:
· A calculated adjustment type for offset-able interest, or a calculated adjustment type for non offset-able interest.
· An associated rate schedule that includes a RQ rule for calculating number of days
· If your implementation rules specify that interest should be calculated and the interest is calculated using a rate factor, you will need to define the following:
· A non-calculated adjustment type for offset-able interest, or a non-calculated adjustment type for non offset-able interest.
· An associated rate factor.
· If your implementation allows offset, then a non-calculated adjustment type needs to be defined for the offset.
· To allow refunds via a check, an A/P adjustment type needs to be defined.
· Make sure the adjustment types are defined on an associated adjustment profile that is linked to any obligation types that are going to be covered by the overpayment process.
· To allow refunds via direct debit a distribution rule needs to be defined. The distribution rule should be designed to pay a specific obligation.
· If approvals are required as part of the overpayment process, a To Do type is needed. The base product is supplied with a To Do type called C1-OVAPP that should be used as the basis for approval To Do type.
· If you wish to have a To Do created when the overpayment process is automatically cancelled, you will need a To Do type. Note that the base-package is supplied with a To Do type called C1-OVPYX that should be used as the basis for automatic cancellation To Dos.
· If you wish to have a To Do created when issues are detected during the validation of the overpayment process, you will need a To Do type. Note that the base-package is supplied with a To Do type called C1-OVISS that should be used as a basis.
· For each To Do type that you wish to use, you will need a To Do role.
· The system has been currently configured to calculate non offset-able interest using a rate factor. If you wish to change this you will need to inactivate the base-package algorithm by adding an appropriate inactivation option to the business object. You will then need to plug in a different algorithm based on the logic you wish to implement.
· Define an overpayment process type for the business object C1-OvrpyProcTypeAutoCredRef.
The above sections describe how the base-package overpayment process for individual taxpayer works using the C1-OvrpyProcAutoCredRef and C1-OvrpyProcTypeAutoCredRef business objects. Your implementation can add additional business rules and change the overpayment process user interface as required. Alternatively, if your implementation needs a different overpayment process, you can create different business objects with their own business rules.
An Overpayment Process Type defines the configuration information that is common to overpayment processes of a given type. The type of information captured on the overpayment process type is governed by the overpayment process type's business object.
To set up an Overpayment Process Type, select Admin Menu, Overpayment Process Type.
The topics in this section describe the base-package zones that appear on the Overpayment Process Type portal.
Contents
Overpayment Process Type Actions
The following functions are available:
· Click a broadcast button to open other zones that contain more information about the adjacent overpayment process type.
· Click the Add link in the zone's title bar to add a new overpayment process type.
This is a standard actions zone. The Edit, Delete and Duplicate actions and appropriate state transition buttons are available.
The Overpayment Process Type zone contains display-only information about an Overpayment Process Type. This zone appears when an Overpayment Process Type has been broadcast from the Overpayment Process Type List zone or if this portal is opened via a drill down from another page.
Please see the zone's help text for information about this zone's fields.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_OP_PROC_TYPE.
This is a standard log zone.