Penalty and Interest (P&I) is the commonly used term to describe a wide range of penalty, interest and fee liabilities. These charges are usually imposed by legislation.
· A penalty is a liability imposed for noncompliance with tax law. Revenue authorities can file penalties against taxpayers for "failure to file," "failure to pay," "substantial understatement," and so on
· Interest compensates the government for cost of money over time
· Fees are imposed to reimburse revenue authorities for their cost of doing business. For example, revenue authorities may incur fees for sending certified mail or for handling defective checks and will pass those fees onto the taxpayers
P&I may be triggered in any of the following ways:
· Event driven, for example, reversing a payment due to non-sufficient funds will impose a fee. These types of transactions are simply one-off adjustments that are created by an appropriate algorithm when the event occurs
· User triggered, for example, auditors may impose an inadequate record-keeping penalty their discretion. The amount may be predefined or determined by the auditor. These types of transactions are created manually or may be created as part of a business process defined by your implementation.
· Ongoing, system-generated charges based on predefined configuration rules. The remainder of this chapter focuses on these types of charges.
The Big Picture of Credit Allocation
The Big Picture of Penalty and Interest
Designing Your P&I Control and P&I Rules
Setting Up Penalty and Interest Options
Before explaining penalty and interest logic, another important concept called credit allocation must be introduced. The following sections provide more information.
Credit allocation is the process of taking credits within an obligation and applying business rules to allocate them against tax, penalty, interest and fees.
Credit allocation sequences specify an order to apply the credit against liability types. This is usually very specific. For example, you could set up the credit allocation sequence to allocate credits in the following order:
1. Defective check fee
2. Failure to pay penalty
3. Interest
4. Failure to pay penalty
5. Tax
6. Outsource collection agency fee
They may also differ based on the type of credit. For example,
· Withholding credit may be allocated differently than a payment
· Payment received before the due date may be allocated differently than a late payment
· Individual payments may have unique priorities dictated by a court order or overridden by a user
The following sections provide more information about credit allocation.
Contents
Debt Categories and their Priorities
Determine Balance Details Algorithm
The term "dynamic" is used to describe credit allocation because the system does not store the matching of credits to debits in the database. Rather, the system applies the credit allocation rules real-time when a request for the detailed balance of an obligation is performed.
In order to be able to apply credits to debits at the granular level shown above, each financial transaction whose amount is a debit (amount is greater than or equal to zero) must be assigned a debt category
· For adjustments that are debits, the debt category is defined adjustment type
· For bill segments, the debt category is defined on the obligation type
· For payments that are debits, for example "negative" payments used to refund money via direct deposit, the base product provides an FT freeze algorithm called C1-CFTZ-RPDC to plug into the Account Type that populates the debt category.
Debt categories may also be linked to credit financial transactions. The base algorithm that allocates credits to debits uses the debt category on credit financial transactions as a prioritization. See Determine Balance Details Algorithm for more information.
The debt category priority defines the order in which credits may be applied to debits.
· The default debt category priority is defined on the obligation type
· If a certain type of credit adjustment, for example a withholding credit dictates a different priority than the default, define the override debt category priority on the adjustment type.
· A financial transaction could reference a debt category priority directly for unusual situations where a payment may require a special debt category priority
The dynamic credit allocation is performed by an algorithm plugged into the Determine Balance Details plug-in spot on the obligation type. The determine balance details algorithm is used throughout the base P&I calculation algorithm but may also be called by other processes to get a balance broken out by assessment / debt category.
The following information highlights the logic in the base algorithm C1-PS-DB-STD.
The algorithm may receive specific FTs in which case it will only use those FTs. Otherwise, it retrieves the FTs for the obligation.
A special plug-in spot Retrieve FT List on obligation type is called to retrieve the FTs for an obligation.
Base plug-in. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot.
Debt Category / Assessment on Credits. This algorithm assumes that if a credit financial transaction references an assessment and/or a debt category that this information is used to prioritize the application of the credit, not restrict its application. This ensures that the results do not include one assessment (or debt category) with an overall debit balance and another assessment (or debt category) with an overall credit balance.
The algorithm processes credits in order from oldest to newest. For each credit found,
· If it references a debt category or assessment (group FT ID) or both, the credit is allocated first to debits with a matching debt category and / or assessment whose effective date is ON or BEFORE the credit's effective date.
· If credit is still remaining, the credit is allocated to debits whose effective date is ON or BEFORE the credit's effective date using the credit allocation rules for the appropriate debt category priority for this credit.
· If credit is still remaining, the credit is allocated to debits with a matching debt category and/or assessment whose effective date is AFTER the credit's effective date.
· If credit is still remaining, the credit is allocated to debits whose effective date is AFTER the credit's effective date using the credit allocation rules for the appropriate debt category priority for this credit.
The algorithm returns a detailed list of FTs including which credits were applied to which debits.
FT Details. The details of the FTs for the obligation and how the credits are allocated to the debits is not hard-coded but rather is defined in a data area supplied to the Determine Detailed Balance plug-in spot. The base algorithm uses the data area C1-PI-MainFtInfo. However, if your implementation requires different information to be supplied for each FT, you may introduce your own data area and an appropriate determine detailed balance algorithm to populate the details accordingly.
The base product provides zones on control central, one on the account information tab and one on the taxpayer information tab, to show the results of credit allocation for the account or taxpayer's current balance.
Refer to Control Central - Account Information for more details.
The following sections describe topics related to penalty and interest calculations.
Contents
P&I is Calculated for an Obligation's Assessments
P&I Rules for a P&I Control Define the Calculation
P&I Calculation Algorithm is the Engine
Forecasting Penalty and Interest
The system creates, stores, and maintains tax liability assessments. These assessments may incur P&I over time. When more than one assessment exists for an obligation, the type of assessment may control P&I rates and rules. For example, if the taxpayer is being audited, harsher penalty rates and rules are used.
As described in Credit Allocation the base product determine detailed balance algorithm allocates credits for an obligation across assessments such that an obligation with multiple assessments would not incur P&I on one assessment while another assessment is in credit. As a result, the P&I calculation algorithm is invoked for an obligation and it always calculates penalty and interest for all assessments for the obligation.
For each obligation type where ongoing, system generated penalty and interest rules apply, you must create a P&I control with its collection of P&I Rules that define the distinct penalty, interest charge or fee.
Each P&I rule controls the actual calculation and allows a user to configure information such as the basis of the charge, the rate used to apply the charge and other controls such as whether there is a maximum amount that the overall calculations may not exceed.
P&I rules to apply to an obligation or configuration related to existing rules may change over time, based on legislation changes or business rule changes. When this occurs, a new P&I control with its new set of rules must be created. The obligation type includes an effective dated link to the P&I controls that govern its P&I charges.
Refer to Apply P&I Rules for Each Time Period for information about how P&I rule calculations are applied during the Calculate P&I process.
Refer to Designing Your P&I Control and P&I Rules for information about designing your rules.
An algorithm plugged into the P&I Calculation plug-in spot on the obligation type is responsible for calculating / forecasting penalty and interest for an obligation.
Configuration Requirements. The base product P&I calculation algorithm relies on many other algorithms plugged into obligation type for it to work properly. In addition, it expects effective P&I controls with at least on P&I rule to exist for the obligation type. Refer to Setting Up Penalty and Interest for more information.
Contents
Calculate For Discreet Time Periods
Apply P&I Rules for Each Time Period
The following sections highlight the logic in the base algorithm C1-PI-CALC. It has been designed to call many other algorithm plug-in spots to perform key steps in the calculation. The goal is for your implementation to use the base product P&I calculation algorithm and implement your organizations specific rules by plugging in appropriate algorithms in the various plug-in spots called by the base algorithm. However if the logic in the base algorithm does not satisfy your business requirements, you may introduce your own, using this algorithm as a sample.
At a high level, the base algorithm follows these steps
· Determine whether or not this obligation is eligible for P&I calculations.
· For eligible obligations
· Determine discreet time periods and perform any other pre-processing needed for the calculations.
· For each time period, apply the P&I rules. Calculations are performed in memory.
· Post processing, including canceling and creating the P&I adjustments if the algorithm is called in "update" mode.
· Update the obligation's calculate to date
The algorithm may be called in "update" or "forecast" mode. When calling the algorithm in "forecast" mode, the calling program may provide specific FTs in which case it will only use those FTs. Otherwise, it retrieves the FTs for the obligation.
A special plug-in spot Retrieve FT List on obligation type is called to retrieve the FTs for an obligation.
Base plug-in. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot.
The list of the FTs for the obligation includes detail for each FT that is needed by the penalty and interest calculation. This list of details is not hard-coded but rather is defined in a data area supplied to the P&I Calculation plug-in spot and to the Retrieve FT List plug-in spot. The base algorithm uses the data area C1-PI-MainFtInfo.
If your implementation requires different information to be supplied for each FT, you may introduce your own data area.
Besides the details of the FTs passed back and forth to services that invoke this plug-in spot, the base P&I calculation algorithm uses data internally that must be passed to the various plug-in spots it invokes.
The base algorithms use the data area C1-PI-InternalCalculationInfo. The data area has the following information:
· A calculation periods collection. This includes start and end dates along with the P&I rules in effect for those dates.
· Existing FT collection. This includes all the FTs that exist for the obligation and is used to compare to the P&I charges being calculated in the current execution to determine if any changes are needed to historical periods.
· Running charges collection. This is the list of charges that are populated by the P&I rule algorithms that calculate the charges. The amounts in this collection are captured with detailed precision to minimize ongoing rounding discrepancies.
· Working financial transaction collection. This collection represents the new list of FTs that are a result of the current P&I calculation. When the service is invoked in "update" mode, this is the list that will be used when creating the actual FTs at the end of the process. If the service is invoked in "forecast" mode, this is the list of FTs that is used to pass out to the calling program. The definition of this list matches the definition of the list of FTs in the P&I Main FT Info data area.
· Waiver information collection. This list contains detailed information for any active waiver that exists for the obligation.
If your implementation requires different or additional information to be passed around to the various P&I calculation plug-in spots that support the internal P&I information, you may introduce your own data area.
There are some types of taxpayers that may be exempt from penalty and interest. Examples of such taxpayers include other government agencies and non-profit organizations.
The base product provides an obligation type plug-in spot P&I Eligibility where an implementation may plug in algorithms that check an obligation's eligibility for penalty and interest. The P&I calculation algorithm provided with the base product calls the P&I eligibility plug-ins prior to performing any penalty or interest calculations. If the algorithms indicate that the obligation is ineligible, no calculations are performed.
Base plug-ins. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot.
Various events may cause the system to recalculate historic penalty and interest:
· Back-dated payment
· Waive existing penalty or interest
· Change to the obligation's override filing due date
· Canceling an assessment
For normal requests from the system to "bring P&I up to date", where historical calculations are not affected, the system still recalculates the P&I from the beginning every time.
One reason for this logic is to ensure that P&I is always accurate. It could be that something has changed in the system that does affect historical calculations and a request to recalculate historical P&I was not performed. The next time P&I runs, recalculating from the beginning ensures that the latest calculation reflects the correct charge.
Another important reason to recalculate P&I from the beginning every time P&I is brought up to date is to avoid rounding issues that may occur over time.
Consider the following example.
· A monthly penalty amount for a delinquent taxpayer is 34.3444
· If the system calculates, rounds and posts, each month ignoring the running total, the penalty after 2 months is
· Month 1 calculation: 34.3444, rounded to 34.34
· Month 2 calculation: 34.3444, rounded to 34.34
· Total: 68.68
· If instead the system keeps track of the running total and creates the adjustment based on the latest running total, the calculation is as follows:
· Month 1 calculation: 34.3444, rounded to 34.34
· Month 2 calculation: 34.3444 + 34.3444 = 68.6888 less amount already posted (34.34): 34.3488, rounded to 34.35
· Total: 68.69
Over time these rounding differences add up. To avoid that the system calculates from the beginning every time P&I is calculated and the running total is kept throughout the calculations.
There are many discreet time periods for which P&I must be calculated:
· Every date for which a credit financial transaction exists (because the calculations are based on an outstanding balance, which is affected by each credit).
· Any effective dated change in the P&I Control linked to the obligation
· Any accrual day of the month. This is necessary if you have a monthly charge that should accrue on a given day of the month and the charge includes other charges in its calculation basis. For example, if penalty accrues on the first day of the month and includes interest in its calculation basis, you must stop and calculate interest and then the penalty on the accrual day of the month so that your calculation basis is accurate.
· Effective dates of any active waivers. If any assessments for the obligation have a waiver that is effective dated, the system should stop and calculated up to that date and then after that date for the waived amount to be accurate.
· More… Your implementation may identify other events in the system that affect P&I calculations. For example, if a bankruptcy is logged in the system as a case, P&I should be calculated up to the bankruptcy start date and then skipped until the bankruptcy end date
The base product P&I calculation algorithm relies on P&I pre-processing algorithms to build this list of dates. Once the list is built, the P&I calculation algorithm applies P&I rules for each time period.
When preparing to calculate penalty and interest for an obligation, the P&I calculation plug-in must gather some information that is needed throughout the processing. For example:
· The P&I controls and P&I rules in effect for the full calculation period.
· Information about waivers that are in effect for the obligation's assessments.
· Identifying the dates during the full P&I calculation period that affect the calculation such that the process should stop and calculate P&I up to that date.
· Determining whether some P&I rules are not applicable for an obligation or one of its assessments. For example, a failure to file penalty is only applicable for obligations where the taxpayer did not file the return on time; and perhaps only applies to the original return and not any amendments.
· Determining whether some P&I rules are only applicable during certain date ranges. For example, if a taxpayer has extended their filing date, perhaps the failure to file penalty is only applicable after the extended filing date but the failure to pay penalty is applicable starting from the original payment due date.
The system provides two plug-in spots to use for building up all this information.
· An obligation type plug-in spot P&I pre-processing is used to define dates and retrieve and configure information that is related to all P&I rules for the obligation type. For example, dates are built for all credit financial transactions for the obligation.
Base plug-ins. Click here to see the algorithm types available for this system event.
· A P&I Rule plug-in spot Rule Pre-processing is used to define dates and retrieve and configure information that is specific to a given P&I rule. For example, a rule that is for the Failure to File penalty has a pre-processing algorithm to determine if the taxpayer failed to file on time.
Base plug-ins. Click here to see the algorithm types available for this system event.
These algorithms populate information in the P&I Internal Calculation Info data area (C1-PI-InternalCalculationInfo) for use by subsequent algorithms in the process.
The following sections highlight additional details related to the responsibility of pre-processing algorithms.
Contents
Build P&I Controls and Call Rule Pre-processing Plug-ins
Marking Rules as Not Applicable Based on Periods
Marking Rules as Not Applicable for One or More Assessments
Determine if Active Waivers Exist
The base product provides an algorithm that should be the first pre-processing algorithm plugged in on your obligation types. It builds the initial date ranges for the P&I calculation, builds the list of P&I Controls and P&I Rules that are in effect for the full date range and, for each P&I rule, it calls the Rule pre-processing algorithms, if any exist.
For more information, refer to the algorithm type C1-PI-PR-PIC.
Although the initial pre-processing algorithm builds a list of all the P&I rules that are in effect for the full P&I calculation period for this obligation, there may be P&I rules that don't apply for the obligation or rules that should only apply for certain time periods. For example:
· The failure to file penalty should only apply if the taxpayer did not file the tax return by the due date.
· A collection fee that is based on the outstanding balance of the tax should only apply if the taxpayer was selected for overdue processing and should only apply to the time period on or after the creation date of the overdue process
· For a taxpayer that filed for bankruptcy, P&I Rules should not be applied during specific bankruptcy dates.
To mark P&I rules as not applicable for certain time periods (or for all the time periods built for the calculations) P&I pre-processing algorithms on the obligation type or rule pre-processing algorithms on the P&I rule should find the P&I rule in the calculation periods collection in the P&I - Internal Calculation Info data area and mark it as not applicable. Refer to the base product rule pre-processing algorithm Determine Failure to File Applicability C1-PI-RA-DFF for an example of this type of logic.
There may be P&I rules that only apply to a subset of the assessments for an obligation for one or more time periods. For example:
· The failure to file penalty may apply only to the original assessment and not to amendments
· Different failure to pay penalty rules may exist for the original assessment and for amendments
· For a taxpayer that filed for bankruptcy, P&I Rules should not be applied during specific bankruptcy dates.
To mark P&I rules as only applicable for certain assessments in a given time period, P&I pre-processing algorithms on the obligation type or rule pre-processing algorithms on the P&I rule should find the P&I rule in the calculation periods collection in the P&I - Internal Calculation Info data area and indicate the assessments that are not applicable. Refer to the base product rule pre-processing algorithm Determine Failure to File Applicability C1-PI-RA-DFF for an example of this type of logic.
The base product provides a plug-in C1-PI-PR-WVR to retrieve details about waivers that exist for any of the obligation's assessments. This information is used by any subsequent algorithm that may need information about the waivers.
Once the discreet time periods for P&I calculation are determined, the base P&I calculation algorithm needs to determine the balance by debt category for the time period in question and call the P&I rule algorithms.
Contents
Balance By Debt Category During P&I Calculation
P&I Rules Calculate the Charge
To calculate the balance by debt category, Determine Balance Details algorithm is used. However, because the P&I calculation algorithm is recalculating P&I from the beginning every time and needs the balance recalculated for each period, it needs to be explicit about which financial transactions are used in the balance calculation. For example:
· When calculating the balance as of a given date, credits effective on that date should be ignored because the system is trying to find the balance as of that date prior to applying the credit. However all debits on or before the given date should be considered.
· Existing P&I transactions should not be factored into the calculation, only the ones created by this P&I run.
· Existing waiver transactions should not be factored into the calculation. However, waiver transactions corresponding to the P&I transactions calculated in the current run must be considered.
To ensure that the appropriate financial transactions are used to calculate the balance for each time period, a special plug-in spot on the obligation type is used: P&I Prepare Periodic Balance. This plug-in is responsible for calling the Determine Detailed Balance plug-in passing the appropriate financial transactions. Note that this plug-in spot receives an indication as to whether it's the Initial, Interim or Final call to get the balance details. This information allows the plug-in to do extra steps at the beginning or at the end.
Base plug-ins. Click here to see the detailed description for the base algorithm type available for this system event and for more information about the behavior of this plug-in spot.
Adjustment Category. The base plug-in for the Prepare Periodic Balance relies on the adjustment type category values of Penalty and Interest and Waiver to identify adjustments that should not be factored in during the Initial call to the algorithm. Care should be taken to only configure adjustment types with the Penalty and Interest category if they are adjustment types created through the P&I rules driven P&I calculation.
Once the balance is available for each time period, for each assessment linked to the obligation, the P&I calculation algorithm invokes the rule processing algorithm for each P&I rule in effect for the obligation type's P&I control during this time period.
The actual calculation of each P&I rule's charge is done in the Rule Processing algorithm plugged into the business object for the P&I rule. Configuration that the rule processing algorithm needs to successfully calculate the charge for each period is often captured on the P&I rule when defining it.
All logic related to calculating the charge for the P&I rule, including determining if and how much of the charge is waived, must be done by a Rule Processing algorithm.
No updates. The rules processing algorithms provided in the base product do not do any updates to the database for new charges or cancellation of existing charges. These algorithms simply update the internal P&I information with new charges calculated and indicating any charge that should be canceled. Post processing algorithms are responsible for creating / cancelling financial transactions.
The following sections describe the responsibilities of algorithms of this type.
Base plug-ins. Click here to see the algorithm types available for this system event.
Contents
Adjustment / Debt Category Configuration
Calculating New Charges and Canceling Incorrect Charges
Use Rates To Define the Penalty or Interest Rate
In many cases the P&I charges are calculated as a percentage of outstanding debt, referred to as the calculation basis. The calculation basis may simply be the amount of unpaid tax or it may be the amount of unpaid tax plus other unpaid charges, such as unpaid penalty or unpaid interest.
The calculation basis can change over time based on changes to the legislation and recalculation of historic info should use the calculation basis in effect at the time of the charge. A change in calculation basis requires a new P&I control and a corresponding new set of rules to be created and linked to the obligation type for the correct effective date.
The base product P&I rule business objects allow the user setting up the P&I rule to configure one or more debt categories that are used as the calculation basis. The balance by debt category is calculated prior to the call to the P&I rules and is passed in using the working FT collection.
Adjustment / Debt Category Configuration
When the penalty or interest charge is posted to the system to affect the taxpayer's balance, an adjustment is used. The adjustment type is defined on the P&I rule.
Each penalty and interest charge is identified by a debt category and this debt category is important for P&I calculation. Because adjustment type references a debt category, the P&I rules supplied with the base product do not capture the debt category explicitly. They derive the penalty or interest rule's debt category from its adjustment type.
No Duplication of Debt Categories. The base algorithms for calculating P&I expect that no two P&I rules for a P&I control refer to the same debt category (via its adjustment type).
Calculating New Charges and Canceling Incorrect Charges
The Rule Processing algorithm is responsible for calculating the appropriate charge for the current time period. However, because P&I is recalculated from the beginning every time P&I is called for an obligation, it's possible for the calculated charge for this time period already exists in the database.
Once the new charge is calculated and added to the running FT collection, the algorithm should perform logic to align existing and running charges and update the working FT collection appropriately. The base product logic does the following:
· When the current calculation matches the existing P&I charge in the database, the existing charge is added to the working FT collection.
· When the current calculation is more than the existing P&I charge in the database, the existing charge is included in the working FT collection and a new entry for the incremental increase is added to the collection.
· When the current calculation is less than the existing P&I charge in the database, the existing charge is marked to cancel in the working FT collection and a new charge for the new amount is added to the collection. In other words, the base algorithms do not create negative P&I charges.
There are situations where a P&I charge is calculated and after that charge was created, something occurs to cause this P&I charge to no longer be applicable for the taxpayer or for the time period or for the assessment. For example, perhaps a backdated payment is entered and the calculation basis for this time period is now zero. In this case although no new calculation occurs, existing charges must still be marked to cancel. To do this, the algorithm should perform the logic to align existing and running charges whenever it detects that no charge is required. In this case, the running charges will have no entries for the time period / assessment so any existing charges get marked to cancel in the working FT collection.
Use Rates To Define the Penalty or Interest Rate
There are two ways that the actual percentage may be applied to the calculation basis: using a rate schedule or using a rate factor.
· Use a rate factor if the calculation is a simple percentage applied to the calculation basis. The rate factor can contain an effective dated list of percentage rates. Using this method, the appropriate rate factor is defined when configuring the P&I rule and the rule processing algorithm is responsible for retrieving the rate factor value and performing the calculation.
· Use a rate schedule if the calculation is more complicated and you would like to take advantage of the calculation logic built into the various types of rate components for a rate. For example, if your charge has a maximum amount that can be charged (for example, a penalty that is 2.5% of the outstanding tax up to a maximum 25% of the outstanding tax), this can be configured easily using the Maximum rate component type. Using this method requires the rule processing algorithm to set up all the amounts that the rate schedule requires to successfully apply the rate. For the current example, it must supply the outstanding tax amount that is the basis of calculation and the maximum amount allowed. Then it should call the rate application service. The P&I rule defines the rate schedule, rate quantity identifier (RQI) for passing in the calculation basis and any other information needed to supply to the rate application service. In this example, the Not to Exceed percentage and an RQI for passing to rates the calculated Not to Exceed amount.
Rate Schedule vs. Rate Factor. The simple percentage calculation may also be performed using rates. However, it requires an administrative user to configure a rate schedule, rate version and a rate component in addition to the rate factor. Designing the algorithm to apply the rate factor directly saves the need for extraneous rates configuration.
As charges are being calculated for each period, rule processing algorithms must also determine whether or not these charges should be waived and enter appropriate entries in the working FT collection to represent the waived amounts.
The base product provides a separate algorithm for each supported waiver type in the system that should be plugged into any P&I rule whose charge may be waived. Each algorithm does the following:
· Determine if there is a waiver in effect for the current debt category / assessment. This information is in the Waiver information collection in the P&I - Internal Calculation Info data area assuming that the pre-processing algorithm to Determine if Active Waivers Exist is plugged in.
· The algorithm then does the appropriate logic to determine whether the amount should be waived based on the logic for the type of waiver.
· If the amount should be waived, an entry is added to the working FT collection. This ensures that subsequent balance calculations for this debt category do not include the amount that is waived.
No adjustments are created or canceled at this time. Post processing algorithms are responsible for that logic.
The system provides an obligation type plug-in spot P&I post-processing to perform any steps that need to occur at the end of all the P&I calculations.
In the base P&I calculations, post processing algorithms are used to do the actual creation and cancellations of penalty and interest adjustment and waiver adjustments in the system as determined by the rule processing algorithms. This is only applicable when the P&I algorithm is called in update mode.
Base plug-ins. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot.
When penalty and interest is updated for an obligation, it is updated with a Calculation Through Date. This information is captured so that users reviewing the detailed balance for an obligation knows how recently the P&I calculation has occurred.
The balance details are calculated one more time to produce the final results for output.
Your implementation may include business processes that require forecasting of an obligation’s balance to a current or future date without posting the P&I transactions:
· Sending a bill may include amount to pay if late, for example:
· If you pay by January 1, please pay $2000
· If you pay by January 15, please pay $2020
· Etc,
· Sending a collection notice may include “please pay X amount by Y date” where the X amount is the forecasted balance on that date, which P&I included.
· If a payment is received at an account or taxpayer level where the taxpayer has several unpaid obligations, the payment algorithm that determines how to distribute the amount across obligations. When determining how much to direct to each obligation, the algorithm should forecast P&I to the payment event's effective date so that an accurate picture of the balance of each obligation is known.
· Proposing scheduled payments for a pay plan should include logic to forecast P&I to the future so that the scheduled payments cover P&I charges that will continue to accrue
The P&I calculation algorithm may be called to forecast. When forecasting, the algorithm perform all the same calculations, but does not store or cancel any adjustments to affect the obligation's balance.
The credit allocation zones on control central allow a user to forecast P&I for a current or future date. Refer to Control Central - Account Information for more details.
A service that calls P&I calculation in forecast mode may optionally provide financial transactions to use. If financial transactions are not provided, the algorithm retrieves the FTs currently linked to the obligation and forecasts P&I to the input date. If FTs are provided, the algorithm uses them in the P&I calculations. Supplying FTs allows a calling program to forecast the P&I with a "what if" scenario, for example "what if the taxpayer makes a payment on date X?". This is useful when proposing scheduled payments for a payment plan.
It is common for tax authority to practice cash accounting for certain situations. For example, perhaps your implementation is a state revenue agency collects sales tax revenue on behalf of counties in your state. You may only distribute the revenue to the counties after the payment is made and not at the time of posting the assessment.
Refer to Payables Cash Accounting for general information about cash accounting functionality.
When dynamic credit allocation is practiced, where amounts are directed specifically to tax, penalty, interest and fees in a specific order, the allocation of credits to the various debt categories must be performed before any updates to the general ledger can be made as a result of cash accounting.
The base product provides an obligation type plug-in spot Cash Accounting True Up where an implementation may plug-in the algorithm that makes all necessary adjustments to the general ledger to transfer amounts from "holding" general ledger accounts to true payable accounts.
This algorithm is executed by the Calculate P&I service provided with the product when invoked in Update mode. The service determines if the obligation type supports the P&I plug-in and if so, executes it. If the obligation type has a Cash Accounting True Up algorithm, it is then called, regardless of whether the obligation type supports P&I.
It means that any update to the system that impacts a taxpayer's financials where either P&I or Cash Accounting may be affected, the Calculate P&I service should be called. The business service is C1-CalculatePenaltyAndInterest.
Base plug-ins. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot.
There is no hard coded logic in the system to invoke the penalty and interest calculation. All requests to bring penalty and interest up to date are executed using plug-in logic. The base product provides logic to forecast P&I or bring P&I up to date when certain events occur. Your implementation may introduce new events that should cause P&I to be recalculated.
The following events in the system cause P&I to be brought up to date
· When a tax form posts or is reversed, transferred or adjusted, using an appropriate Form Rule. Basically any state transition of a form that causes adjustments to be created should include a rule to bring P&I up to date.
· When a payment is frozen or canceled, assuming that an appropriate plug-in is entered on the account type
· When the effective date of a frozen payment is changed
· If your obligation is governed by the C1-FilingPeriodObligation business object, a post processing plug-in recalculates P&I if the override due date changes.
· When a waiver is activated or canceled
· An overdue event algorithm to calculate P&I is provided
A user may also request that P&I is brought up to date using the Credit Allocation zones on Control Central on both the Account Information portal and the Taxpayer Information portal.
Contents
C1-CALPI - Bring P&I Up to Date
Besides the events in the system that may cause a recalculation of P&I, the system also provides a background process C1-CALPI to periodically bring P&I up to date for all obligations.
The background process looks for all non-canceled non-closed obligations that reference a P&I control and invokes the appropriate P&I calculation algorithm.
The base product does not provide a plug-in to bring P&I up to date when an adjustment is frozen or canceled.
· Certain adjustments are created / canceled from the P&I calculation, for example the penalty and interest charges and waiver charges. For these types of adjustments, penalty and interest recalculation should not be invoked.
· For other adjustments where P&I should be brought up to date, there are many business scenarios where several adjustments are created for various charges. For example, when a tax form is processed, adjustments may be created for the tax assessment due and for the withholding credit and for refundable tax credits. The system should wait until all the adjustments are created before bringing P&I up to date, otherwise a lot of unnecessary calculations will occur.
Rather than building "update penalty and interest" logic into a plug-in for the adjustment, the expectation is that a business process that creates adjustments that affect P&I should include a step to invoke P&I when the adjustments are created.
If your implementation has manually created/canceled adjustments that should affect penalty and interest, you should plug-in Adjustment Freeze and Adjustment Cancel plug-ins to bring P&I up to date.
Also note that when an assessment adjustment is canceled, all related penalty and interest adjustments should be canceled as well. The P&I calculation does not cater for cleaning up penalty and interest for canceled assessments.
Special service. When cancelling an assessment adjustment, the business service C1-CancelAssessmentAdj should be used. This will clean up penalty and interest adjustments for the canceled assessment.
Waivers provide the ability to forgive or waive certain penalties, interest or fees. Sometimes waivers are referred to as abatements. You can waive a full amount or a partial amount (flat rates or percentages) or waive charges during a certain time period.
Contents
A waiver is created for a specific assessment and a specific debt category for that assessment. For example, interest for the obligation's original assessment may be waived or the failure to pay penalty for the amendment may be waived.
The base product provides business objects and appropriate algorithms out of the box that support the following types of waivers:
· One-time waivers. Waivers of this type are used to waive charges for a given assessment / debt category up to a specific amount.
· Effective dated waivers. Waivers of this type are used to waive charges for a given assessment / debt category that occur on or after a given start date. Waiver of this type may optionally specify an end date to waive charges for a specific period.
· Ongoing waivers. Waivers of this type are used to waive all charges for a given assessment / debt category.
A waiver is treated differently from an exemption in the base product algorithms. The assumption is that when an obligation is exempt from penalty and interest, calculations should not even be performed. Refer to Eligibility for more information.
For a waiver, the base product calculates the penalty or interest charge as normal and then creates appropriate waiver adjustments to offset the waived amounts. This allows an implementation to keep track of the amount of penalty and interest that has been waived.
In order for waivers to affect P&I calculation, appropriate algorithms must be plugged in. The following points highlight the algorithms that are required to support waiver functionality:
· Information about existing waivers should be retrieved by a P&I pre-processing algorithm for use by the P&I rule processing algorithms. Refer to Determine if Active Waivers Exist for more information.
· If your implementation supports effective date waivers, the P&I pre-processing algorithm C1-PI-PR-WDT Adjust Calculation Periods for Effective Waivers should be plugged into any obligation type that supports P&I processing with waivers.
· Every P&I rule that calculates a charge that may be waived should include appropriate rule processing waiver algorithms plugged into the P&I Rule BO to adjust calculated charges in the internal P&I information data area based on existing waivers. Algorithms are provided to support one-time waivers, ongoing waivers and effective dated waivers. The base product P&I rule BOs are configured with the waiver algorithms already plugged in.
· P&I post processing algorithms C1-PI-PS-WV1 Process One-time Waivers, C1-PI-PS-WV2 Process Ongoing Waivers and C1-PI-PS-WV3 Process Effective Dated Waivers are provide to create or cancel waiver financial transactions when calling P&I in update mode. These algorithms should be plugged into any obligation type that supports P&I processing for waivers.
No excess waiver. The base product algorithms assume that when a waived penalty or interest charge is later modified to cause the original amount to be less than the waiver, the waiver amount must also be adjusted accordingly. A waiver credit should never be in excess of the debt it's waiving.
The base product provides admin and transaction business object pairs for one-time waivers (C1-WaiverTypeOneTime and C1-OneTimeWaiver), ongoing waivers (C1-WaiverTypeOngoing and C1-OngoingWaiver) and effective dated waivers (C1-WaiverTypeEffectiveDated and C1-EffectiveDatedWaiver). Your implementation can add additional business rules to these BOs as required. If your implementation has waiver rules that aren't satisfied by one of the above business objects, you may create your own using the above as samples.
The base product provides a BO for P&I Control C1-StandardPIControl. Your implementation can add additional business rules to this BO as required. If your implementation has radically different requirements for your P&I controls, you can create a different business objects with their own business rules.
The base product supplies two BOs for P&I Rules.
· C1-MonthlyChargePIRule - this BO includes an algorithm that calculates the monthly charge with a Not to Exceed limit, using a rate schedule.
· C1-SimpleCalculationPIRule - this BO includes an algorithm that calculates a simple charge applying a rate factor to the outstanding calculation basis amount.
Your implementation can define add additional business rules to these BOs as required. If your implementation's P&I rules are not satisfied by one of the above business objects, you may create your own using the above as samples. The following points highlight the important configuration for this business object:
· Develop the appropriate rule processing algorithm to calculate the charge correctly.
· If waivers are applicable for the P&I rule's debt category, be sure to plug in appropriate rule processing algorithms to handle waiving the P&I rule's charge
· For any configuration required by the rule processing algorithm, consider whether it should be defined when configuring the P&I rule by a business user. If so, include the appropriate elements in the P&I rule business object's schema.
· Determine whether any P&I Rule Pre-processing algorithms are applicable for this type of rule.
The topics in this section describe how to set up the system to enable penalty and interest calculations.
Contents
Setting Up Debt Category Priorities
Setting Up Adjustment Cancel Reasons
Setting Up Rate Quantity Indicators
In order for penalty and interest to be brought up to date when a payment is frozen or canceled, configure the account types with the following algorithms:
· System Event: Payment Freeze, Algorithm C1-PI-PAYFRZ
· System Event: Payment Cancellation, Algorithm C1-PI-PAYCAN
Define debt categories for the following:
· One for each separate penalty or interest charge that is calculated by a system P&I rule.
· One for any other type of debt that is not calculated by P&I calculations, but is used in the calculation basis for one of the P&I rules.
· One for any other category of debts. For example, overpayments. When an obligation is overpaid, at some point the overpayment amount is reduced by one or more methods, such as minimum amount write down, carry forward to a future obligation, refund, etc. The adjustments created to reduce an overpayment are debits and therefore require a debt category. The suggestion is to create a special "Overpayment" debt category for these types of debts.
Define appropriate as debt category priorities required by your implementation's business rules. Refer to Debt Categories and their Priorities for more information.
Adjustment types are needed for posting P&I charges.
· A separate adjustment type must be created for each debt category that is part of the P&I calculation.
· Each adjustment type created should use the Penalty & Interest adjustment type category.
Adjustment types are needed for posting waivers.
· A separate adjustment types must be created for each debt category whose P&I charges may get waived.
· Each adjustment type should refer to the Waiver adjustment type category.
· Each adjustment type should define the C1-WAIVR characteristic type as a valid template characteristic. This is used to reference the waiver that caused the adjustment to be created.
An adjustment type is needed for transferring cash accounting amounts from a "holding" general ledger account to the true "payable" account.
For any adjustment that is a manual penalty and should cause P&I to be recalculated, configure and adjustment freeze algorithm to bring P&I up to date. Note that the base product does not supply such an algorithm.
Define appropriate adjustment cancel reasons to use when cancelling P&I adjustments and based on recalculation and cancel reasons to use when cancelling waiver adjustments.
Create appropriate rate factors that define the percentage to use when calculating your various P&I charges.
· If you are defining P&I rules using the base BO C1-SimpleCalculationPIRule, the P&I rule requires a rate factor to use when applying the charge.
· If you are defining P&I rules using the base BO C1-MonthlyChargePIRule, the P&I rule expects to use a Rate Schedule. You may choose to define rate factors for configuring the charges used in the specific rate components defined in this rate schedule.
Create appropriate RQIs required for your P&I rules. If you are defining P&I rules using the base BO C1-MonthlyChargePIRule, you need an RQI for the following information to pass into rate application:
· The calculation basis amount
· The not to exceed amount
Create appropriate rate schedules and their components to calculate the charges appropriately.
If you are defining P&I rules using the base BO C1-MonthlyChargePIRule, you need a rate schedule with rate components that calculate the charge by applying an appropriate percentage to the calculation basis passed in using the RQI defined above. If a Not to Exceed amount is applicable, there should also be a maximum rate component that adjusts the calculated charge based on the Not to Exceed amount.
The following are some additional notes related to the setup of this rate:
· The charges are not expected to prorate for short or long periods. To accomplish this, an appropriate frequency must be configured for the rate schedule. Because the P&I rule is expecting to apply monthly charges, the frequency may be set to have 1 period annually and 365 days for the minimum and maximum offset. Refer to the demonstration data for an example.
· The individual rate components should all be set as follows:
· FCPO is checked
· The Result Type is Charge
· Rounding Precision is set to the maximum allowed to ensure that the maximum calculation precision is returned.
· Create Bill Line is checked
· RCPO Retention Rule is set to Retain amount on bill line
A P&I Control is created to hold all the rules that work together to calculate automated / ongoing penalty and interest. The P&I control includes a list of P&I Rules that make up the individual calculations.
To set up P&I Control, select Admin Menu, P&I Control.
The topics in this section describe the base-package zones that appear on the P&I Control portal.
Contents
The P&I Control List zone lists every P&I Control. The following functions are available:
· Click a broadcast button to open other zones that contain more information about the adjacent P&I Control.
· Click the Add link in the zone's title bar to add a new P&I Control.
This is a standard actions zone. The Edit, Delete and Duplicate actions and appropriate state transition buttons are available.
The P&I Control zone contains display-only information about a P&I Control. This zone appears when a P&I Control has been broadcast from the P&I Control 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.
This zone lists obligation types currently linked to the broadcast P&I control.
This zone lists the P&I rules associated with the broadcast P&I control. Click on a P&I rule in the list to view its details in the P&I rule portal.
If the P&I control is in pending status, Edit and Delete actions are available for each P&I rule. In addition you may add another P&I rule using the Add link in the zone's title bar.
This is a standard log zone.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_PI_CTRL.
This portal is provided to view and maintain details of a given P&I rule. This portal is not available from a menu. You navigate to this portal by drilling into a specific P&I rule from the P&I control portal.
The topics in this section describe the base-package zones that appear on the P&I Rule portal.
Contents
This is a standard actions zone. The Edit and Delete actions are available.
The P&I Rule zone contains display-only information about a P&I rule.
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_PI_RULE.
Each obligation type where penalty and interest charges are applicable must be configured appropriately:
· Define the default debt category priority.
· It should include appropriate P&I controls that define the P&I rules that are in effect
· It should include appropriate P&I calculation algorithms. The following provides a list of the plug-in spots that must are required for P&I calculations. Unless noted, base algorithms are provided. If the functionality provided in the base algorithms does not satisfy your implementation's business rules, you may define your own:
· P&I Calculation
· Determine Balance Details
· Retrieve FT Details
· P&I Prepare Periodic Balance
· P&I Pre-processing
· P&I Post Processing - algorithms are provided for all algorithm types except for the cash accounting algorithm type. That one needs to be configured with the appropriate adjustment type.
· In addition to the required algorithms above, if your implementation's business rules include P&I Eligibility requirements, provide appropriate algorithms.
To open the Waiver Type zone, select Admin Menu, Waiver Type.
Contents
The Waiver Type List zone lists every waiver type. The following functions are available:
· Click a broadcast button to open other zones that contain more information about the adjacent waiver type.
· Click the Add link in the zone's title bar to add a new waiver type.
The Waiver Type zone contains display-only information about a Waiver Type. This zone appears when a Waiver Type has been broadcast from the Waiver 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.
This is a standard actions zone. The Edit, Delete and Duplicate actions and appropriate state transition buttons are available.
This is a standard log zone.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_WAIVER_TYPE.