Defining Financial Transaction Options

Bills, payments and adjustments share one very important trait – they affect how much your taxpayers owe.  This section explains the financial design of the system and describes how to set up the tables that control the financial impact of these transactions.

Contents

The Financial Big Picture

Obligation Type Controls Everything

Tender Management

Automatic Payment Options

Payment Advices

Payment Event Distribution

Cancel Reasons

Miscellaneous Financial Controls

Payables Cash Accounting

Open Item Accounting

Fund Accounting

Defining Bill Cycles and Bill Periods

Other Financial Transaction Topics

This section provides an overview of the relationship between an account and the various financial transactions that influence how much a taxpayer owes.

Contents

Assessments Overview

Penalty and Interest

Bills, Payments & Adjustments

Bill Details

Payment Details

Adjustment Details

Current Amount versus Payoff Amount

Preventing Obligation Balances And The GL From Being Impacted Until Bill Completion

Forcing The Freeze Date To Be Used As The Accounting Date

Assessments Overview

An assessment is a tax liability financial transaction associated with an obligation and represents the legal presentation of a tax liability to a taxpayer.  There are different types of assessments, based on how and why the liability was created, and the assessment type can apply differentiated processing rules, such as different penalty and interest calculation rules or different collections rules. 

Most filing periods only have one assessment created that captures any applicable penalty, interest, or fees.  However, it is possible for additional assessments to be created within a filing period. 

Return and bill based tax types differ in how assessments get created and processed. The following sections discuss these concepts.

Contents

Return Based Taxes

Bill Based Taxes

Group Financial Transactions

Effective Date

Return Based Taxes

Return based taxes are either expected or event based.  Return based taxes represent taxpayers that have an expected obligation to file a Return for a filing period.  Return based taxes can also be based on events such as taxpayers filing an excise tax.  Income tax, withholding tax, and sales tax are examples of return based taxes.

For expected return-based tax types, the obligation is associated with a filing period as it tracks whether a filing obligation has been met for that period, and groups the assessments and financial transactions related to it.  For most tax types, a filing period may be associated with a single type of obligation.  For example, an active monthly Sales Tax filer has a single obligation for each month of the year.  However, some tax types may require multiple filing obligations (of different types) over the same period of time.  For example, a Withholding Tax type may have monthly Withholding Tax Returns as one obligation type, plus an annual Reconciliation Return and an Annual Taxpayer Withholding Detail statement as other obligation types. 

Most return-based tax liability is created through the original self-assessment reported by a taxpayer on their tax return.  There are two common models for self-assessment:

·         Full Self-Assessment.  This is common in the US.  In full self-assessment, a taxpayer reports their income details on their tax return, calculates their tax per the tax return instructions, and files (and pays or expects a refund) by the due date of the filing period.  If the tax return has errors or is changed during processing, the taxpayer receives an adjustment notice, but never receives an assessment notice.

·         Partial Self-Assessment.  This is common in taxes modeled after the British tax system.  Like full self-assessment, the taxpayer reports their income tax details on a tax return.  However, the tax return does not include instructions for calculating tax.   When the tax return is processed, a Notice of Assessment is generated and sent to the taxpayer.  The Notice of Assessment is a legal document informing the taxpayer of their tax obligation, and the due date for paying it. 

The assessment established by the taxpayer’s initial tax return is called the original assessment.  If the taxpayer is later audited, and their income is increased (such that they now owe more tax), the additional tax established by the audit is part of an audit assessment.  The incremental tax from the audit will be subject to different business rules, such as different rates and rules for calculating penalty and interest, and different collections notices or processes.  It is also possible for a change to a tax return to result in a decrease in tax (and therefore a refund). 

Bill Based Taxes

Bill based taxes are billed on a predefined schedule.  Property tax, periodic licensing fees, and metered oil/resource taxes are examples of bill-based taxes. 

For bill-based taxes, the system has all of the necessary information to initiate assessments.  The system creates assessments on a schedule and a single assessment exists for each billing period.  If a taxpayer disputes a bill, the bill is cancelled and rebilled without creating an incremental assessment.

Group Financial Transactions

As financial transactions are created for an obligation, often they are related to a specific liability such as an assessment, which is also a financial transaction (associated with an adjustment or a bill segment).  For example, a payment may be made for a specific assessment.  Penalties, interest and fees are often levied toward a specific assessment.  Associating these subsequent financial transactions with the appropriate assessment FT ensures accurate penalty and interest calculations and accurate views of the balance of each assessment associated with an obligation.

The system provides a means for your implementation to group financial transactions (via the Group FT ID).  When creating a financial transaction that should be associated with a given assessment, set the group FT id to the FT Id of the assessment. The following example shows the usage of the Group FT Id field.

The original assessment FT (sometimes referred to as the "header FT") references its own FT id in the Group FT field.  This allows system functionality to easily identify the assessment financial transaction.

Effective Date

The effective date is the effective date of the payment, bill, or adjustment. For more information about effective dates and payment dates, see Payment Date and Effective Date for Payment Events.  The effective date is used in calculating penalties and interest. For more information, refer to The Big Picture of Penalty and Interest.

Penalty and Interest

Calculating penalty and interest (P&I) for delinquent assessments is an important element of a tax authority's business.

Bills, Payments & Adjustments

The following points are high level descriptions of the various financial transaction supported

·         For bill based taxes, many bills are produced for an account over time.  For more information about a bill, see Bill Details.

·         Over time, many payments may be applied to an account’s debt.  For more information about a payment, see Payment Details.

·         Over time, the debt that is stored on an account’s obligation(s) may be adjusted.  For more information about an adjustment, see Adjustment Details.

Note that the system maintains debt on each individual obligation for an account.  An account’s debt is the sum of its obligations’ debt.

Bill Details

The following points highlight important concepts related to bills:

·         A bill is produced for an account. Over time, many bills may be produced for an account.

·         Bills contain bill segments.  A bill segment is created to levy charges for a bill-based obligation.  You may configure your system to generate a single bill for a single obligation.  For example you may generate one bill for your property tax obligation's charges.  You may also include bill segments for multiple obligations in a single bill.  For example you may generate a bill that includes bill segments for all the personal property obligations.

·         Bill segments contain calculation details.  A bill segment contains information showing how the segment was calculated and how it should be printed on the taxpayer’s bill.

·         A bill segment has a financial transaction.  A bill segment has a related financial transaction.  A financial transaction contains the financial effects of the bill segment on the obligation’s current and payoff balances and on the general ledger. 

·         Canceling a bill cancels the financial transaction.  If the bill segment is eventually cancelled, another financial transaction will be linked to the bill segment to reverse its original financial transaction.  The cancellation financial transaction appears on the next bill produced for the account as a bill correction.

Payment Details

The following points highlight important concepts related to payments:

·         A payment amount is ultimately directed towards an obligation via a payment segment.

·         If an account has multiple obligations that are in debt, the various payment segments created for the obligations may be grouped into a single Payment for the account.

·         A payment segment has a related financial transaction.  A financial transaction contains the financial effects of the segment on the obligation’s current and payoff balances and on the general ledger. 

·         Canceling a payment cancels the financial transaction.  If the payment is eventually cancelled, another financial transaction will be linked to the related payment segment(s) to reverse their financial effect.  The cancellation financial transaction appears on the next bill produced for the account as a negative payment.

Adjustment Details

The following points highlight important concepts related to adjustments

·         Over time, an obligation may have many adjustments.

·         An adjustment has a related financial transaction.  The financial transaction contains the financial effects of the adjustment on the obligation’s debt and on the general ledger. 

·         Canceling an adjustment cancels the financial transaction.  If the adjustment is eventually canceled, another financial transaction will be linked to the adjustment to reverse its financial effect. The cancellation financial transaction appears on the next bill produced for the account as an adjustment.

Current Amount versus Payoff Amount

A financial transaction contains two amount attributes: payoff amount and current amount.  These attributes allow you to keep track separately of amounts related to how much the taxpayer owes.

·         Current amount contains how much the taxpayer THINKS THEY OWE.  In other words, this is the amount that affects the taxpayer's balance.  It is what the taxpayer owes with respect to collections and is the amount that penalty and interest is calculated on.

·         Payoff amount contains how much the taxpayer REALLY OWES.  This is the amount posted to the general ledger.

For most financial transactions, these values are the same.  There are a small number of cases where this amount may be different.  One example is a charitable contribution.  If a taxpayer makes a charitable contribution when paying their tax liability, the payment or adjustment associated with the contribution credit should affect the payoff amount and the general ledger (because this amount is actually cash in hand).  However, it should not affect the current amount because the contribution is not paying off any debt incurred and should not cause the taxpayer's balance to go into credit.

The topics in this section provide more information about these two fields.

Contents

What Controls What Gets Booked To Current And Payoff Amount?

GL Accounting Information

What Controls What Gets Booked To Current And Payoff Amount?

As described in Bill Details, every bill segment has a sibling financial transaction.  The financial transaction defines the bill segment’s affect on current and payoff amounts due.  The system populates these two fields as per the Financial Transaction Algorithm defined on the bill segment’s bill segment type. 

As described in Payment Details, every payment segment has a sibling financial transaction.  The financial transaction defines the payment segment’s affect on current and payoff amounts due.  The system populates these two fields as per the Financial Transaction Algorithm defined on the payment segment’s payment segment type. 

As described in Adjustment Details, every adjustment has a sibling financial transaction.  The financial transaction defines the adjustment’s affect on current and payoff amounts due.  The system populates these two fields as per the Financial Transaction Algorithm defined on the adjustment’s adjustment type. 

GL Accounting Information

Be aware that if payoff amount is non-zero, the financial transaction has general ledger detail lines. 

The effect on your GL is controlled by the financial transaction algorithm defined on your bill segment and payment segment types.

Preventing Obligation Balances And The GL From Being Impacted Until Bill Completion

It’s important to understand that when any type of financial transaction is frozen, the related obligation’s balance is affected.  For example:

·         When a payment is frozen, the taxpayer’s balance is reduced. 

·         When an adjustment is frozen, the taxpayer’s balance is impacted.

·         When a bill segment is frozen, the taxpayer’s balance is increased (typically).

For payments, there is no issue.  However, for bill based tax types, you may NOT want the taxpayer’s balance to be impacted until the bill is completed.  Consider the following:

·         If a taxpayer has multiple obligations that should be presented on the same bill, it’s possible for one of the obligations to have a bill segment that’s in error and the other obligation’s bill segment to be frozen.

·         The frozen bill segment will impact the taxpayer’s balance and the general ledger.  This is because a financial transaction is marked for interface to the general ledger when it is frozen.  This can be problematic if you have a long period between FT freeze and bill completion (you could impact the general ledger but not impact the taxpayer’s balance). 

If this is unacceptable, you can setup the system to not allow certain types of FT’s to be frozen until the bill is completed.  This means that neither the taxpayer’s balance nor the general ledger will be impacted until bill completion time.  To do this:

·         Choose the Freeze At Bill Completion option on Installation Options - Billing.

·         Determine if any of your adjustment types are ones that would be included on a bill-based tax bill.  Select Freeze At Bill Completion for those that should not impact the taxpayer’s balance or the general ledger until the next bill is completed.  Select Freeze At Will for those that should impact the taxpayer’s balance and the GL when they are frozen.

Please be aware of the following in respect of the Freeze At Bill Completion options:

·         If you turn on Freeze At Bill Completion on Installation Options - Billing:

·         Users will not be allowed to freeze bill segments online.

·         Any background process created for batch billing should not freeze bill segments until all segments on a bill are error free.

·         Bill segments will exist in the freezable state until the bill is completed.

·         If you turn on Freeze At Bill Completion on Adjustment Type - Main:

·         Users will not be allowed to freeze adjustments of this type online.

·         Background processes that create adjustments will not freeze this type of adjustment.  Rather, the adjustments will be frozen when the next bill is completed.

·         Adjustments of this type will therefore exist in the freezable state until the next bill is completed.

Please be aware of the following in respect of the Freeze At Will options:

·         If you turn on Freeze At Will on Installation Options - Billing:

·         Users will be allowed to freeze bill segments online.

·         Any background process created for batch billing should freeze bill segments when the individual segment is error-free.

·         Bill segments will exist in the frozen state regardless of whether the bill is completed.

·         The frozen bill segment’s FT will be interfaced to the GL when the interface next runs.

·         All adjustment types must also be set to Freeze At Will (otherwise they wouldn’t get frozen).

·         If you turn on Freeze At Will on Adjustment Type - Main:

·         Users will be allowed to freeze adjustments of this type online.

·         Background processes that create adjustments will freeze this type of adjustment.

·         Adjustments of this type will exist in the frozen state prior to bill completion.

·         The frozen adjustment’s FT will be interfaced to the GL when the interface next runs.

Forcing The Freeze Date To Be Used As The Accounting Date

Every financial transaction references an accounting date.  The accounting date controls the accounting period to which the financial transaction is booked as described below:

·         Every financial transaction references an accounting date and an obligation

·         Every obligation references an obligation type

·         Every obligation type references a GL division

·         Every GL division references an accounting calendar

·         The accounting calendar contains the cross reference between the accounting date specified on the financial transaction and the related accounting period in your general ledger

The accounting date is populated on financial transactions when they are initially generated.  The following points describe the source of the accounting date:

·         The user who creates or cancels a bill segment online defines the accounting date as part of the generation / cancel dialog (note, the current date defaults).

·         The user who creates or cancels an adjustment online defines the accounting date as part of the generation / cancel dialog (note, the current date defaults).

·         Payments are unusual in that their financial transaction is only created when they are frozen (rather than when the payment is first distributed amongst the account’s obligations).  At payment freeze time, the accounting date is set to the current date.

For payments, there is no issue because the accounting date is only populated on the financial transaction when a payment is frozen.  However, for bill segments and adjustments, your business practice may dictate that the freeze date should be used as the accounting date rather than the original accounting date.  Alternatively, your business practice may dictate that the accounting date that’s originally stamped on bill segments / adjustments should be used (unless this associated period is closed at freeze time).  It’s really a question of the interpretation of the local accounting rules.  After you’ve decided on your approach, populate the Accounting Date Freeze Option on Installation Options - Billing with one of the following values:

·         Choose Always change if the accounting date on your financial transactions should be populated with the freeze date (i.e., the current date when the financial transaction is frozen).

·         Choose Change if period is closed if the accounting date defined when the financial transaction is generated should be used (unless the associated accounting period is closed).

Please be aware of the following in respect of your choice:

·         If you choose Always change:

·         When a user freezes a bill segment online, they will be prompted to supply an accounting date.  The current date will default, but the user can override this value.

·         When a user freezes an adjustment online, they will be prompted to supply an accounting date.  The current date will default, but the user can override this value.

·         Any batch billing process should use the current business date as the accounting date on bill segments that it freezes.

·         Also note, if you have chosen the Freeze At Bill Completion Bill Segment Freeze Option on the installation record, bill segments and certain types of adjustments are frozen when a bill is completed.  This means that the accounting date on the related financial transactions will be set to the completion date (because the completion date is the freeze date with this setting).  Refer to Preventing Obligation Balances And The GL From Being Impacted Until Completion for more information.

·         If you choose Change if period is closed:

·         When a user freezes a bill segment online, they will only be prompted to supply an accounting date if the related accounting period is closed (because the accounting period closes after the bill segment is generated but before it’s frozen).  The current date will default, but the user can override this date.

·         When a user freezes an adjustment online, they will only be prompted to supply an accounting date if the related accounting period is closed (because the accounting period closes after the adjustment is generated but before it’s frozen).  The current date will default, but the user can override this date.

The previous section illustrated three important concepts:

The true financial impact of the three financial events - bills, payments, adjustments - is at the obligation level, not at the account level.  This means that bills and payments are meaningless on their own.  It’s the obligations’ bill segments, payment segments and adjustments that affect how much a taxpayer owes.

·         Every bill segment, payment segment, and adjustment has a related financial transaction.  These financial transactions contain the double-sided journal entries that will be interfaced to your general ledger.  They also contain the information defining how the taxpayer’s debt is affected by the financial event (i.e., current amount and payoff amount).

·         A single bill can contain many bill segments, each of which may have a different frequency. 

You control the financial effects of the various financial events using a single field on the obligation.  This field is called the Obligation Type.  In this section, we describe many of the tables that must be set up before you can create an obligation type. 

Contents

Setting Up Divisions

Setting Up Revenue Classes

Setting Up Debt Categories

Setting Up Debt Category Priorities

Setting Up Distribution Codes

Setting Up Billable Charge Templates

Defining Bill Segment Types

Setting Up Payment Segment Types

Designing And Defining Adjustment Types

Setting Up Divisions

There are two types of divisions referenced on an obligation type: a division and a GL division.

·         General Ledger divisions typically comprise individual entities (e.g., companies) in your general ledger.  You must set up a GL division for each such entity.  The GL division’s sole purpose in the system is to define the accounting period associated with financial transactions linked to obligations associated with the GL division (obligations are associated with GL divisions via their obligation type).  The system cares about accounting periods in order to prevent a user from booking moneys to closed periods.  It also uses accounting periods when it produces the flat file that contains the consolidated journal entry that is interfaced to your general ledger (refer to The GL Interface for more information).

·         A division is used to separate business rules and can often be associated with a jurisdiction.  The definition of a jurisdiction is a geographic-oriented entity with unique business rules.  Another example of where you may use separate divisions is when your tax authority is responsible for other types of debt in the system, such as state university debts or child support debts.  You must set up a division for each segmentation in your authority where business rules may differ.

Division is also referenced on obligation, location and account. 

·         The division on obligation is actually part of the obligation’s obligation type.  Because obligation type controls many business rules, all business rules that are on the obligation type can be thought of as being defined for a given jurisdiction and obligation type combination.  Refer to Defining Obligation Types for more information.

·         The division on location defines the jurisdiction in which the location is located.  This jurisdiction controls the types of obligations that can be associated with the location.

·         The division on account when combined with the account’s account type defines the jurisdiction that governs financial business rules (e.g., the bill’s due date).  Refer to Setting Up Account Types for more information about these rules.  The division on account can also play a part in the addressee of To Do entries associated with the account.  To assign To Do entries to a role based on the division, simply link the To Do type to the division.  Refer to To Do Entries Reference A Role for more information.

The following topics describe the pages used to maintain a division.

Contents

Division - Main

Division - Characteristics

Division - Main

To define a division, select choose Admin Menu, Division.

Description of Page

Enter an easily recognizable Division and Description for the division.

Enter the Work Calendar that defines the days on which this division operates.  This calendar is used to ensure system-calculated dates (e.g., bill due date, credit and collection event dates, etc.) fall on a workday.

Use the To Do Roles scroll area if an account’s division influences the role assigned to To Do entries associated with the account.  In the collection, define the To Do Role to be assigned to entries of a given To Do Type that are associated with accounts that reference the Division.  Refer to Assigning A To Do Role for more information.

Where Used

Follow this link to view the tables that reference CI_CIS_DIVISION in the data dictionary schema viewer.

Division - Characteristics

You can define characteristics for a division.  You may need these for reporting purposes or in your algorithms.  Refer to Characteristic Types for more information.

Open Admin Menu, Division and navigate to the Characteristics tab to maintain a division’s characteristics.

Description of Page

Select a Characteristic Type and Characteristic Value to be associated with this division.  Indicate the Effective Date of the characteristic type and value.

Setting Up Revenue Classes

Every obligation references an obligation type.  Amongst other things, the obligation type defines an obligation’s revenue class.  The revenue class is used when the obligation’s rate books revenue to different GL distribution codes based on the obligation’s revenue class.

To set up revenue classes, choose Admin Menu, Revenue Class.

Description of Page

Enter an easily recognizable Revenue Class ID and Description for every revenue class.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_REV_CL.

Setting Up Debt Categories

Debt Categories are used to categorize financial transactions that are debits.  Debt categories may also be assigned to credit financial transactions if the credit is associated with a given type of debit.  Refer to Debt Categories and their Priorities for more information.

To set up a debt category, open Admin Menu, Debt Category.

The topics in this section describe the base-package zones that appear on the Debt Category portal.

Contents

Debt Category List

Debt Category Actions

Debt Category

Debt Category List

The Debt Category List zone lists every debt category.  The following functions are available:

·         Click the broadcast icon to open other zones that contain more information about the adjacent debt category. 

·         The standard actions of Edit, Duplicate and Delete are available for each debt category.

Click the Add link in the zone's title bar to add a new debt category.

Debt Category Actions

This is a standard actions zone.  The Edit, Delete and Duplicate actions are available.

Debt Category

The Debt Category zone contains display-only information about a debt category.  This zone appears when a debt category has been broadcast from the Debt Category 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_DEBT_CAT.

Setting Up Debt Category Priorities

Debt category priorities allow you to define a priority order of allocating credit financial transactions to debit financial transactions during credit allocation.  Refer to Debt Categories and their Priorities for more information.

To set up a debt category, open Admin Menu, Debt Category Priority.

The topics in this section describe the base-package zones that appear on the Debt Category Priority portal.

Contents

Debt Category Priority List

Debt Category Priority Actions

Debt Category Priority

Debt Category Priority List

The Debt Category Priority List zone lists every debt category priority.  The following functions are available:

·         Click the broadcast icon to open other zones that contain more information about the adjacent debt category priority.

·         The standard actions of Edit, Duplicate and Delete are available for each debt category priority.

Click the Add link in the zone's title bar to add a new debt category priority.

Debt Category Priority Actions

This is a standard actions zone.  The Edit, Delete and Duplicate actions are available.

Debt Category Priority

The Debt Category Priority zone contains display-only information about a debt category priority.  This zone appears when a debt category priority has been broadcast from the Debt Category Priority 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_DEBT_CAT.

Setting Up Distribution Codes

Distribution codes simplify the process of generating accounting entries by defining valid combinations of chart of account field values.

To set up distribution codes, open Admin Menu, Distribution Code.

Description of Page

Enter a unique Distribution Code and Description for the distribution code.

If this distribution code is a holding account used for payables cash accounting, check the Use For Cash Accounting switch, and enter the actual payable Cash Accounting Code.  The system will transfer the holding amount to this distribution code when the cash event occurs.  For more information, refer to Payables Cash Accounting.

Define the GL Account Algorithm used by the system when it interfaces financial transactions that reference this distribution code to your general ledger (refer to GLDL - Create General Ledger Download for more information about the download process).  The logic embedded in this algorithm constructs the actual GL account number.  If you haven’t done so already, you must set up this algorithm in the system.  To do this:

·         Create a new algorithm (refer to Setting Up Algorithms).

·         On this algorithm, reference an Algorithm Type that constructs your general ledger account number.  Click here to see the algorithm types available for this plug-in spot.

The Write Off Controls provides the ability to define configuration to write off debt associated with the distribution code by transferring the written off debt to a separate obligation.  You would only do this if you wanted to the written off debt to remain visible in the account's balance and you don't want it to remain in the original obligation's balance.

·         Define the Division and Obligation Type of the obligation to which bad debt associated with this distribution code should be transferred at write-off time.  Note: only obligation types with a special role of Write Off may be selected.

·         When the system transfers debt to the write-off obligation defined above, the distribution code defined on this Division / Obligation Type will be debited unless you turn on the Override Switch.  When this switch is turned on, the system overrides the distribution code of the transfer to side of the adjustment with the distribution code associated with the debt being written off.  You’d typically turn this switch on for liability distribution codes because you want to debit the original liability account when the debt is written off.  Note: if this switch is on the system also overrides the characteristic type / value with the respective value associated with the debt that is being written off.

Use the GL Account Details scroll to define how the system constructs the GL account associated with the distribution code when it interfaces the financial transaction to your general ledger.  For each distribution code, enter the following information:

·         Enter the Effective Date of the following information.

·         Define whether, on the Effective Date, the following information is Active or Inactive.  The system will only use effective-dated information that is Active.

·         Enter the GL Account that the general ledger uses to process financial transactions tagged with this distribution code.

·         By default, the installation is configured to practice fund accounting.  With this option activated, you can define the Fund associated with this distribution code.  If your installation options indicate that fund accounting is not practiced, the field is not visible.

·         Use the grid to define characteristic values for the Distribution Code.  To modify a characteristic, simply move to a field and change its value.  The following fields display:

·         Characteristic Type.  Indicate the type of characteristic.

·         Characteristic Value.  Indicate the value of the characteristic. 

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_GL_DIVISION.

Setting Up Billable Charge Templates

A user creates a billable charge whenever a taxpayer should be levied an ad hoc charge.  For example, if a taxpayer requires a review of their property assessment, you may charge them an administration fee.

A billable charge must reference an obligation.  This obligation behaves just like any other obligation:

·         Bill segments are created for the obligation.  Whenever billing is performed for an account with billable charge obligations, the system creates a bill segment for each unbilled billable charge. 

·         Payments are distributed to the obligation.  Payments made by an account are distributed to its billable charge obligations just like any other obligation.

·         Overdue debt is monitored.  The credit and collections process monitors billable charge obligations for overdue debt and responds accordingly when overdue debt is detected.

Billable charge templates exist to minimize the effort required to create a billable charge for a taxpayer.  A billable charge template contains the default bill lines, amounts and distribution codes used to levy a one-off charge. 

The information on the template may be overridden by a user when the billable charge is created.

After setting up the billable charge templates, you must indicate the obligation types that can use each template.  Obviously, only billable charge obligation types (as defined on the obligation type’s special role) will reference billable charge templates.

Contents

Billable Charge Template - Main

Billable Charge Template - Line Characteristics

Billable Charge Template - RQ Details

Billable Charge Template - Main

Open Admin, Billable Charge Template to define your billable charge templates.

Description of Page

Enter a unique Billable Charge Template ID and Description for the billable charge template.

Use Description on Bill to define the verbiage that should print on the taxpayer’s bill above the billable charge’s line item details.

Use Currency Code to define the currency in which the billable charge’s amounts are expressed.

Use the grid to define the line item details associated with the billable charge (note, the Total Line Amount field is automatically calculated.  It is the sum of the Charge Amount on each of the Line Sequence items). The following fields are required for each entry in the grid.

Sequence                                            Line sequence controls the order in which the line items appear on the bill segment. 

Description on Bill                               Specify the verbiage to print on the bill for the line item.

Charge Amount                                   Specify the default amount to charge for the line item.

Show on Bill                                        Turn this switch on if the line item should appear on the taxpayer’s printed bill.  It would be very unusual for this switch to be off.

Appears in Summary                           Turn this switch on when the amount associated with this line also appears in a summary line.

Memo Only, No GL                              Turn this switch on when the amount associated with this line does not affect the GL (or the total amount owed by the taxpayer).

Distribution Code                                 Specify the default distribution code associated with this line item.

If you use the drill down button on the left most column in the grid, you will be taken to the Line Characteristics tab with the selected line displayed.

Billable Charge Template - Line Characteristics

Open Admin, Billable Charge Template, Line Characteristics to define your billable charge templates line characteristics.

Description of Page

The Line Sequence scroll defines the billable charge template line to which you wish to assign characteristic values. 

The following fields display:

Characteristic Type                              The type of characteristic.

Characteristic Value                            The value of the characteristic.

Billable Charge Template - RQ Details

Open Admin, Billable Charge Template, RQ Details to define your billable charge templates service quantities.

Description of Page

The following fields display:

Sequence                                            Specify the sequence number of the RQ.

UOM                                                     Select the unit of measure of this RQ.  One or more of UOM, TOU, or RQ identifier must be selected.

TOU                                                     Select the time of use period.

RQ Identifier                                        Select the RQ identifier.

Rate Quantity                                       Specify the number of units of this rate quantity.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_B_CHG_TMPLT.

Defining Bill Segment Types

Every obligation references an obligation type.  Amongst other things, the obligation type references a bill segment type.  The bill segment type controls how bill segments and their related financial transactions are created.

Setting Up Bill Segment Types

To set up bill segment types, open Admin Menu, Bill Segment Type.

Description of Page

Enter an easily recognizable Bill Segment Type and Description for every type of bill segment.

For each bill segment type, define the Create Algorithm.  The logic embedded in this algorithm creates the bill segment. 

If you haven’t done so already, you must set up this algorithm in the system.  To do this:

·         Create a new algorithm (refer to Setting Up Algorithms).

·         On this algorithm, reference an Algorithm Type that creates a bill segment in the appropriate manner.  Click here to see the algorithm types available for this plug-in spot.

For each bill segment type, define the Financial Algorithm. The logic embedded in this algorithm constructs the financial transaction associated with the bill segment.

If you haven’t done so already, you must set up this algorithm in the system.  To do this:

·         Create a new algorithm (refer to Setting Up Algorithms).

·         On this algorithm, reference an Algorithm Type that constructs the bill segment financial transaction in the appropriate manner.  Click here to see the algorithm types available for this plug-in spot.

Define the Pre-creation Algorithm.  The logic embedded in this algorithm retrieves detailed information needed to bill the bill segment.

If you haven’t done so already, you must set up this algorithm in the system.  To do this:

·         Create a new algorithm (refer to Setting Up Algorithms).

·         On this algorithm, reference an Algorithm Type that retrieves details needed for billing in the appropriate manner.  Click here to see the algorithm types available for this plug-in spot.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_BILL_SEG_TYP.

Setting Up Payment Segment Types

Every obligation references an obligation type.  Among other things, the obligation type references a payment segment type.  The payment segment type controls how payment segments and their related financial transactions are created.  To set up payment segment types, open Admin Menu, Payment Segment Type.

Description of Page

Enter an easily recognizable Payment Segment Type and Description for every type of payment segment.

For each payment segment type, define the Payment Segment Fin Algorithm.  The logic embedded in this algorithm constructs the actual financial transaction associated with the payment segment. Refer to Examples of Common Payment Segment Types for examples of how algorithms are used on common payment segment types.

If you haven’t done so already, you must set up this algorithm in the system.  To do this:

·         Create a new algorithm (refer to Setting Up Algorithms).

·         On this algorithm, reference an Algorithm Type that constructs the payment segment financial transaction in the appropriate manner.  Click here to see the algorithm types available for this plug-in spot.

Examples of Common Payment Segment Types

The following table shows several classic payment segment types used by many organizations:

Payment Segment Type	Payment Segment Financial Transaction Algorithm
Normal payment (if you practice accrual accounting).  Refer to Accrual versus Cash Accounting for more information.	Payoff = Pay Amount / Current = Pay Amount (no cash accounting)
Normal payment (if you practice cash accounting). Refer to Accrual versus Cash Accounting for more information.	Payoff = Pay Amount / Current = Pay Amount (plus Cash Accounting)
Charity payment	Payoff =0 / Current = Pay Amount (the GL is affected)

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_PAY_SEG_TYPE.

Designing And Defining Adjustment Types

An obligation’s debt may be changed with an adjustment.  Every adjustment must reference an adjustment type.  The adjustment type contains a great deal of information that is defaulted onto the adjustment, including whether the adjustment amount is calculated.  It also controls many business processes associated with the adjustment.  The topics in this section describe how to design and set up adjustment types.

Contents

Adjustment Types Define Business Rules

Setting Up Adjustment Types

Setting Up Adjustment Type Profiles

Setting Up Adjustment Type Extensions

The Big Picture Of Adjustment Approval

Setting Up Approval Profiles

Adjustment Types Define Business Rules

An adjustment type contains the business rules that govern how its adjustments are managed by the system.  The topics in this section describe how adjustment type controls the behavior of an adjustment.

Contents

Defaults the Adjustment Amount

Generated Adjustments

Controls Which Balance(s) Are Affected

Defines the GL Account Affected by the Adjustment

Controls the Interface to A/P and Income Statement Reporting

Controls Information Printed On the Bill

Controls if the Adjustment Requires Approval

May Control the Adjustment Information

Defaults the Adjustment Amount

The adjustment type may default the adjustment amount in one of the following ways:

·         The adjustment type may specify a default amount.  This would be used for those adjustment types that have a standard charge for all taxpayers that receive this adjustment. 

·         The adjustment type may specify a default adjustment amount algorithm.  This would be used for those adjustment types that have a charge that varies based on other factors.  For example, a non-sufficient funds charge may be based on a taxpayer’s credit rating.

When an amount is defaulted onto a new adjustment it may be overridden by a user.

Generated Adjustments

You can use an algorithm to calculate an adjustment amount or to build details related to the adjustment amount.  The following are some examples of where this may be used:

·         Taking a base adjustment amount and applying a rate to add additional charges.

·         Taking the adjustment amount and capturing or producing additional supporting details in the calculation details collection.  For example, if a P&I adjustment should be "disbursed" into detailed buckets as per the disbursement of the related assessment adjustment, a generate algorithm may be used to produce the appropriate P&I calculation details.  Refer to the base product algorithm type C1-PIDISTRII for an example.

·         Receiving calculation details from a calling program and storing them with the adjustment.

·         Receiving calculation details from a calling program and using them to generate general ledger details for the adjustment's financial transaction.

All generated adjustment types must be set up as follows:

·         Set the adjustment type's Adjustment Amount Type to Calculated Amount

·         Plug in an appropriate Generate algorithm on the adjustment type as per the business rules

·         Configure an appropriate FT creation algorithm on the adjustment type.  A typical reason for using generated adjustments is that additional details are required for the general ledger.  The base product FT creation algorithms all include an option to use the calculation details as a source for the GL.

Contents

Adjustment Calculation Details

Applying a Rate

Adjustment Calculation Details

Generated adjustments are used to produce details related to the adjustment amount.  These details may be provided by a calling program or may be determined using the appropriate business logic.

In general, the adjustment calculation lines are used to capture the details.  But there are unusual points related to this logic:

·         Algorithms that populate the calculation line details must also populate calculation "header" details, including the number of lines and the total amount.  However, calculation "header" details are never instantiated in the database.  The information populated in the calculation header is used by the adjustment logic to process the calculation lines. Refer to any base product Generate algorithm for an example of populating the calculation "header".

·         Calculation lines include a switch called "create bill line."  (Adjustment calculation lines are reusing bill calculation line functionality).  In the adjustment logic, adjustment calculation lines are only instantiated if this switch is set to true.  The reason that an algorithm may produce a calculation line that should not be stored is that this information is available in memory for subsequent processes, namely the FT creation algorithm, which produces the GL details.

There are times when the calling program has the detailed information to be stored in the adjustment calculation lines and in the FT GL details.  The services provided in the product to add and freeze an adjustment do not include the full adjustment calculation details collection or the FT GL details collection as input.  Rather, there is a special field called "custom common area" which may be used to pass information in XML format into the adjustment routines.  The base product provides a Generate algorithm that accepts calculation details passed in the custom common area and returns calculation lines.  Refer to the base product algorithm type C1-ADJ-GN-CL for more information.

Applying a Rate

One use of the adjustment generation plug-in is to call rate application.  The base product supplies an algorithm type ADJG-RT that enables you to call a rate application, passing in the base adjustment amount and receiving calculated details from the rate.

The adjustment type’s generate adjustment algorithm controls which rate is applied to the base amount.  A user supplied calculation date controls which version of the rate is used.  The user may supply the base amount or it may be defaulted from the adjustment type and possibly overridden by the user prior to calculating the adjustment amount.

Controls Which Balance(s) Are Affected

The adjustment type’s financial transaction (FT) algorithm controls how payoff balance and current balance are affected by the adjustment amount. 

Defines the GL Account Affected by the Adjustment

Most adjustments affect the general ledger (GL) in some way.  The following points describe the source of these GL accounts.

·         For many adjustments there is a single accounting entry generated:

·         One side of the accounting entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment.  For example, if you are adjusting the payoff balance on a normal obligation, the A/R account is constructed from the distribution code on the obligation’s obligation type.

·         The other side of the accounting entry is taken from the distribution code on the adjustment’s adjustment type. 

·         For transfer adjustments (i.e., adjustments used to transfer moneys between two obligations), there are two accounting entries generated - one for the “from” side and one for the “to” side.  Each adjustment carries its own set of balanced GL accounting details.

·         For each adjustment, one side of the entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment

·         The other sides of both accounting entries have the same GL account.  This account should be the intermediate clearing GL account that is to be used for the transfer.  The source of this clearing GL account is the distribution code on the adjustment type used to transfer the funds.

·         For generated adjustments, the accounting entry may include several GL details:

·         One side of the entry is taken from the distribution code on the obligation type of the obligation affected by the adjustment.

·         The other side of the entry depends on configuration on the adjustment financial transaction algorithm.  If it is configured to use the Calculation Lines as the source, the distribution codes are taken from the calculation lines.  If it is configured to use the adjustment type as the distribution code source, the other side of the accounting entry is taken from the distribution code on the adjustment type.

Controls the Interface to A/P and Income Statement Reporting

If the adjustment type is associated with a payment of money to a taxpayer (e.g. a refund), the adjustment type indicates such with a reference to an A/P request type. 

When an adjustment that references an A/P request type is frozen, an A/P download request record is created.  This record is the interface request to ask your A/P system to cut a check.  This interface record is marked with a batch process ID and run number.

·         The batch process ID is the process responsible for creating the flat file that contains check request that is interfaced to your account’s payable system.  The batch process ID is defined on Installation Options – Financial.  The base package is supplied with a skeletal background process (referred to by the process ID of APDL) that must be populated with logic to format the records in the format compatible with your accounts payable system.

·         The run number is the batch process ID’s current run number.

If the resultant check needs to be reported for income tax purposes under a specific income statement category, the category is also specified on the adjustment type.  The income statement category is in turn interfaced to the A/P system (the system does NOT manage income statement reporting).

Controls Information Printed On the Bill

If the adjustment is one that appears on a taxpayer’s bill, the verbiage is specified on the adjustment type (and may NOT be overridden on the adjustment).

Controls if the Adjustment Requires Approval

May Control the Adjustment Information

The adjustment information displayed throughout the system is controlled by a plug-in.

It may be formatted by a plug-in algorithm on the Adjustment Type.  Refer to the base package’s C1-ADT-INFO for an example.  If such an algorithm is not plugged-in on the Adjustment Type, the system looks for a corresponding algorithm on the installation record.  Refer to the base package’s C1-ADI-INFO for examples.  If you prefer different formatting logic, your system administrator should configure the system appropriately.

Setting Up Adjustment Types

The topics in this section describe how to set up adjustment types.

Contents

Adjustment Type - Main

Adjustment Type - Adjustment Characteristics

Adjustment Type - Algorithms

Adjustment Type - Main

To set up adjustment types, open Admin Menu, Adjustment Type.

Description of Page

Enter a unique Adjustment Type ID and Description for the adjustment type.

If an adjustment type extension exists for the adjustment type, a link to the extension record is displayed next to the Adjustment Type ID.

The Adjustment Amount Type indicates whether or not the adjustment amount or details to support the adjustment amount is generated or not.  Select Calculated Amount when you want to use a generate algorithm to generate the adjustment amount or generate calculation line details to support the adjustment amount, otherwise select Non-Calculated Amount.  Refer to Generated Adjustments for more information about generated adjustments.

Enter the Distribution Code that references the GL account associated with the adjustment.  For example, if this adjustment type is used to levy a charge for a bad check, the distribution code would reference the revenue account to which you associate such revenue.  Note, the offsetting distribution code is kept on the obligation type.

Use Adjustment Type Category to assign a broad category to the adjustment type.  Valid values are Assessment, Credit, Penalty & Interest, Waiver, Write Off.

Define the Debt Category to assign to the financial transaction for debit adjustments (adjustments with amounts greater than or equal to 0) created for this adjustment type. 

If this adjustment type is for a certain type of credit adjustment and it has special rules for how credits are applied in the base Determine Detailed Balance algorithm, define the appropriate Debt Category Priority.  Refer to Debt Categories and their Priorities for more information.

Enter the Currency Code for adjustments of this type.

Turn on Sync. Current Amount if adjustments of this type exist to force an obligation’s current balance to equal its payoff balance.  These types of adjustments are issued before an obligation’s funds are transferred to a write-off obligation.  If this switch is on, choose an Adjustment Fin Algorithm that does not impact payoff balance or the GL, but does affect the obligation’s current balance (refer to ADJT-CA for an example of such an algorithm).

Enter a Default Amount if an amount should be Default the Adjustment Amount onto adjustments of this type. 

If the AP Adjustment should be recorded in respect of the taxpayer’s income statement amounts, indicate the Income Statement.  The values of this field are Interest and Miscellaneous.  This type of adjustment would also have an A/P Request Type Code selected, as income statement reporting is handled in A/P.

Turn on Print By Default if information about adjustments of this type should print on the account’s next bill.

Choose an A/P Request Type if this adjustment is interfaced to accounts payable (i.e., it’s used to send a refund check to a taxpayer).   Refer to A/P Check Request for more information.

The Adjustment Freeze Option defines when adjustments can be frozen and therefore when an obligation’s balance and the general ledger are affected by an adjustment.  Refer to Preventing Obligation Balances And The GL From Being Impacted Until Bill Completion to understand the significance of this option.  Also note, if the installation option’s Bill Segment Freeze Option is Freeze At Will, this field is defaulted to Freeze At Will and cannot be changed.

Set Allow Manual Creation to Allowed if you want to allow users to manually create adjustments of this type from the adjustment page, otherwise set it to Not Allowed.

Set Allow Manual Cancellation to Allowed if you want to allow users to manually cancel adjustments of this type from the adjustment page, otherwise set it to Not Allowed.

If adjustments of this type require approval, define an Approval Profile.  For more information, refer to The Big Picture of Adjustment Approvals.

Enter the verbiage to appear on the printed bill in Description on Bill.

Use an Adjustment Business Object to define a BO that may govern additional rules related to adjustments of this type.

Use the characteristics collection to define a Characteristic Type and Characteristic Value common to all adjustments of this type.  These can be used for reporting purposes or in your algorithms.

Adjustment Type - Adjustment Characteristics

To define characteristics that can be defined for adjustments of a given type, open Admin Menu, Adjustment Type and navigate to the Adjustment Characteristics tab.

Description of Page

Use the Adjustment Characteristics collection to define characteristics that can be defined for adjustments of a given type.  Turn on the Required switch if the Characteristic Type must be defined on adjustments of a given type.  Enter a Characteristic Value to use as the default for a given Characteristic Type when the Default switch is turned on.  Use Sequence to control the order in which characteristics are defaulted.

Adjustment Type - Algorithms

Description of Page

The grid contains Algorithms that control important adjustment functions.  If you haven’t already done so, you must set up the appropriate algorithms in your system.  You must define the following for each algorithm:

·         Specify the System Event with which the algorithm is associated (see the table that follows for a description of all possible events).

·         Specify the Sequence Number and Algorithm for each system event.  You can set the Sequence Number to 10 unless you have a System Event that has multiple Algorithms.  In this case, you need to tell the system the Sequence in which they should execute.

The following table describes each System Event.

System Event	Optional / Required	Description
Adjustment Cancellation	Optional	When an adjustment is canceled an algorithm of this type may be called to do additional work. Refer to The Lifecycle Of An Adjustment for more information about canceling an adjustment. Click here to see the algorithm types available for this system event.
Adjustment Freeze	Optional	When an adjustment is frozen an algorithm of this type may be called to do additional work. Refer to The Lifecycle Of An Adjustment for more information about freezing an adjustment. Click here to see the algorithm types available for this system event.
Adjustment Information	Optional	We use the term "Adjustment information" to describe the basic information that appears throughout the system to describe an adjustment.  The data that appears in "Adjustment information" is constructed using this algorithm.  Plug an algorithm into this spot to override the "Adjustment information" algorithm on installation options or the system default "Adjustment information" if no such algorithm is defined on installation options. Click here to see the algorithm types available for this system event.
Adj. Financial Transaction	Required	Algorithms of this type are used to construct the actual financial transaction associated with the adjustment.  The financial transaction controls the adjustment’s affect on the obligation’s payoff and current balances.  It also constructs the information that is eventually interfaced to your general ledger. Click here to see the algorithm types available for this system event.
Default Adjustment Amount	Optional	Algorithms of this type are used to default the adjustment amount.  Refer to Default the Adjustment Amount for more information. Click here to see the algorithm types available for this system event.
Determine Obligation	Optional	Algorithms of this type are used to find an obligation for which the adjustment can be posted.  This plug-in is used particularly during adjustment upload when a staging record does not identify the obligation ID.  Refer to Interfacing Adjustments From External Sources for more information. Click here to see the algorithm types available for this system event.
Resolve Suspense	Optional	Algorithms of this type are used to automatically resolve adjustments that are in suspense.  Refer to Suspense Adjustments for more information Click here to see the algorithm types available for this system event.
Generate Adjustment	Optional	Algorithms of this type are used to generate the adjustment amount or generate details to support the adjustment amount if an adjustment type indicates that the adjustment amount is calculated.  Refer to Generated Adjustment for more information. Click here to see the algorithm types available for this system event.
Validate Adjustment	Optional	Algorithms of this type are used to validate information for the adjustment after it is generated. Click here to see the algorithm types available for this system event.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_ADJ_TYPE.

Setting Up Adjustment Type Profiles

Adjustment type profiles categorize your adjustment types into logical groups.  When you link a profile to an obligation type, you limit the type of adjustments to be linked to the obligation type’s obligations.  The creation of adjustment profiles and their linkage to obligation types prevents inappropriate adjustments from being linked to your obligations.  More than one adjustment type profile may be linked to an obligation type.

For example, you can create an adjustment type profile called Miscellaneous Fees and link to it the miscellaneous fee adjustment types.  Then, you would link this profile to those obligation types that are allowed to levy such fees.

To set up adjustment type profiles, open Admin Menu, Adjustment Type Profile.

Description of Page

Enter a unique Adjustment Type Profile and Description for the adjustment type profile.

Indicate the Adjustment Types that are part of the profile.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_ADJ_TYP_PROF. 

Setting Up Adjustment Type Extensions

Adjustment Type Extensions let you maintain additional information related to an adjustment type.  The information you maintain is controlled by the business objects that your implementation defines based on your business needs. 

The base product supplies an adjustment type extension business object that supports mapping between assessment distribution codes and P&I distribution codes. Refer to ??? for more information.

To set up an Adjustment Type Extension, open Admin Menu, Adjustment Type Extension.

The topics in this section describe the base-package zones that appear on the Adjustment Type Extension portal.

Contents

Adjustment Type Extension List

Adjustment Type Extension Actions

Adjustment Type Extension

Adjustment Type Extension List

The Adjustment Type Extension List zone lists every Adjustment Type Extension.  The following functions are available:

Click the broadcast icon to open other zones that contain more information about the adjacent Adjustment Type Extension. 

The standard actions of Edit, Duplicate and Delete are available for each Adjustment Type Extension.

Click the Add link in the zone's title bar to add a new Adjustment Type Extension.

Adjustment Type Extension Actions

This is a standard actions zone.  The Edit, Delete and Duplicate actions are available.

Adjustment Type Extension

The Adjustment Type Extension zone contains display-only information about an Adjustment Type Extension.  This zone appears when an Adjustment Type Extension has been broadcast from the Adjustment Type Extension 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_ADJ_TYPE_EXT.

The Big Picture Of Adjustment Approval

Some implementations require adjustments to be approved by one or more managers before they impact an obligation's balance and the general ledger.  For example, an adjustment used to refund a credit balance may require managerial approval before the refund is sent to the taxpayer.  The topics in this section describe how to set up the system to support the approval of adjustments.

Contents

Approval Is Controlled By Approval Profiles

Approval Profiles Can Be Linked To Multiple Adjustment Types

Adjustments Created In Batch Are Not Approved

Approval Inserts A Step Into An Adjustment's Lifecycle

Approval Requests Manage And Audit The Approval Process

To Do Entries Are Created To Notify Approvers

Monitoring and Escalating Approval Requests

Rejecting Deletes The Adjustment

Designing Your Approval Profiles

Exploring Adjustment Approval Data Relationships

Implementing Other Approval Paradigms

Approval Is Controlled By Approval Profiles

An approval profile contains the rules that define if and how an adjustment is approved.  If an adjustment type does not reference an approval profile, the related adjustments do not require third-party approval before they impact an obligation's debt.  If an adjustment type references an approval profile, the approval profile's approval hierarchy defines if the adjustment requires approval and who the authorized approvers are.  For example, an approval profile can be configured with the following approval hierarchy:

·         Adjustments < $0 require approval by the "credit approvers role"

·         Adjustments >= $0 and <= $10 do not require approval

·         Adjustments > $10 and <= $100 require the approval of a user that belongs to the "level 1 approvers role"

·         Adjustments > $100 require two levels of approval: first a user that belongs to the "level 1 approvers role" must approve the adjustment; afterwards, the adjustment must be approved by a user that belongs to the "level 2 approvers role"

Approval Profiles Can Be Linked To Multiple Adjustment Types

Approval hierarchies are frequently the same for many adjustment types.  The system allows an approval profile to be linked to multiple adjustment types to simplify the definition and maintenance of the rules over time.

Adjustments Created In Batch Are Not Approved

The system assumes that no approval is necessary for adjustments created by batch processes even those whose adjustment type references an approval profile. 

Approval Inserts A Step Into An Adjustment's Lifecycle

The Lifecycle Of An Adjustment explains how an adjustment is transitioned from the Freezable state to the Frozen state when it should impact the general ledger and the obligation's balance.  If an adjustment's adjustment type references an approval profile, the user cannot freeze the adjustment directly.  Rather, the user must submit the adjustment for approval when it's ready and only when the last applicable approver approves the adjustment will it become Frozen.

Approval Requests Manage And Audit The Approval Process

Users submit an adjustment for approval using a dedicated button on the Adjustment page.  When an adjustment is submitted for approval, the system creates an "approval request".  The approval request determines if the adjustment requires approval and, if so, the list of approvers.  If the adjustment does not require approval, the approval request is updated to indicate such and the adjustment is Frozen immediately (if freezing is allowed prior to bill completion).  If the adjustment requires approval, the approval request's state becomes Approval In Progress and the approver(s) are notified.

To Do Entries Are Created To Notify Approvers

When an approval request detects an adjustment requires approval, 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 approval profile.  All users who belong to the approving To Do role can see the entry.  When a user drills down on an adjustment approval To Do entry, the Adjustments - Approval portal is opened.  This portal contains summary information about the adjustment and the approval history of the adjustment.  This portal is also where the user approves or rejects the adjustment. 

When the first user in the To Do role approves an adjustment, the To Do entry is Completed and the approval request's audit log is updated.  If there are no higher levels of approval required, the adjustment is Frozen (if freezing is allowed prior to bill completion) and the approval request is moved 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.

Monitoring and Escalating Approval Requests

The base-package is supplied with an algorithm that your implementation can use to monitor 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-APR-TMOUT 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-AdjustmentApprovalRequest business object.

Rejecting Deletes The Adjustment

When an adjustment is being approved, anyone with access to the adjustment can reject it by using the Adjustments - Approval portal.  Users other than the current approver are allowed to reject an adjustment to allow an "in process" an adjustment to be withdrawn.

When an adjustment is rejected, the following takes place:

·         The user is prompted for a reject reason.

·         The approval request's audit log is updated with the reject reason and the approval request is moved to the Rejected state.

·         The adjustment is deleted.

Designing Your Approval Profiles

The following points describe a recommended design process:

·         Create logical groups of adjustment types where each group has the same monetary hierarchy and approvers.  An approval profile will be required for each of these groups.

·         The number of To Do types (if any) that need to be created is dependent on how the adjustment approval To Do entries should be organized on To Do lists.  For example, if all approval request To Do entries can appear in the same To Do list, you can use the base-package adjustment approval To Do type.  However, if your organization prefers each approval profile's To Do entries to appear in a distinct To Do list, a separate To Do type will be needed for each list.  Note that the base-package is supplied with a To Do type called C1-ADAPP that should be used as the basis for any new approval request To Do type.

·         The number of To Do roles is dependent on who approves your adjustments.  At a minimum, you will require a separate To Do role for each level in your approval profiles.  Remember that every user in a To Do role will see its entries (and receive email if you've configured the system to do such). 

·         Refer to Monitoring and Escalating Approval Requests for how to configure the system to escalate approval requests that have been waiting too long.

·         If your implementation requires email notification when an adjustment requires approval, the following setup is required:

·         Set up an outbound message type, external system, and XAI sender.  Refer to To Do Entries May Be Routed Out Of The System for the details.

·         Every To Do type referenced on your approval profiles should be configured as follows:

·         Define the F1-TDEER batch process as the To Do type's routing process

·         Set up an algorithm that references the C1-ADJAREQEM algorithm type and plug it in the External Routing system event.

Exploring Adjustment Approval Data Relationships

Use the following links to open the application viewer where you can explore the physical tables and data relationships behind the approval functionality:

·         Click C1-APPR PROF to view the approval profile maintenance object's tables.

·         Click C1-APPR REQ to view the approval request maintenance object's tables.

Implementing Other Approval Paradigms

The above sections describe how the base-package adjustment approval process works.  Because adjustment approval has been implemented using the C1-AdjustmentApprovalProfile and the C1-AdjustmentApprovalRequest business objects, your implementation can add additional business rules and change the approval user interface as required.  Alternatively, if your implementation has a radically different approval process, you can create different business objects with their own business rules.

Setting Up Approval Profiles

Approval profiles contain the rules that control how adjustments are approved.  To set up an approval profile, open Admin Menu, Approval Profile.

The topics in this section describe the base-package zones that appear on the Approval Profile portal.

Contents

Approval Profile List

Approval Profile Actions

Approval Profile

Approval Profile's Adjustment Types

Approval Profile List

The Approval Profile List zone lists every approval profile.  The following functions are available:

·         Click the broadcast icon to open other zones that contain more information about the adjacent approval profile. 

·         The standard actions of Edit, Duplicate and Delete are available for each approval profile.

Click the Add link in the zone's title bar to add a new approval profile.

Approval Profile Actions

This is a standard actions zone.  The Edit, Delete and Duplicate actions are available.

Approval Profile

The Approval Profile zone contains display-only information about an approval profile.  This zone appears when an approval profile has been broadcast from the Approval Profile 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.

Approval Profile's Adjustment Types

The Approval Profile's Adjustment Types zone lists every adjustment type that is governed by this approval profile.  This zone appears when there is at least one adjustment type governed by the approval profile displayed in the Approval Profile zone.

When a payment is received, a tender is created to record what was remitted (e.g., cash, check, credit card).  The topics in this section describe control tables that must be set up in order to remit tenders.

Contents

Setting Up Tender Types

Setting Up Tender Sources

Setting Up Tender Types

Tender types are used to indicate the method in which the tender was made. A unique Tender Type must exist for every type of tender that can be remitted.  For example, if you allow cash, checks, direct debits from a checking account, and direct debits from a credit card to be tendered, you’d need the following tender types:

Tender Type	Description	Like Cash	Generate Auto Pay	Require External Source ID	Require Expiration Date	External Type
CASH	Cash	Yes	No	N/A	N/A	N/A
CHEC	Check	No	No	N/A	N/A	N/A
OVUN	Cash drawer – over/under	No	No	N/A	N/A	N/A
DDCH	Direct debit - checking	No	Yes	Yes	No	Checking withdrawal
CRED	Direct debit – credit card	No	Yes	No	Yes	Credit card withdrawal

 

Go to Admin Menu, Tender Type to define your tender types.

Description of Page

Enter a unique Tender Type and Description for the tender type.

Turn on the Like Cash switch if this tender type is cash or the equivalent of cash.  This indicator controls if the system generates a warning if a cash-only account remits a tender other than cash.  It is also used to generate a warning for online cashiers to turn in their tenders when the cash-like amount exceeds the maximum amount balance defined for the tender source.

Turn on Generate Auto Pay if this type of tender causes an automatic payment request to be routed to a financial institution.  For example, this switch will be on if this tender type is used for direct debits from a taxpayer’s checking account (because every tender of this type will have an automatic payment request created when the tender is created).

The following fields are only used for tender types associated with automatic payments:

External Type                                      This field is used by the background process that creates the information that is interfaced to the automatic payment source.  Specifically, it controls the record type associated with the different types of automatic payments that are routed to the automated clearinghouse (ACH).

Require Ext. Src. ID                             This switch indicates if an Auto-Pay Source that references this type of tender must contain an External Source ID.  The External Source ID is the unique identifier of the financial institution to which the automatic payment will be routed. 

                                                            This switch is typically turned on for tender types associated with checking / saving direct debits.  It is turned off for tender types associated with credit card debits (you don’t need an external source for a credit card debit, you just need the credit card number).

Expiration Date Required                    Turn this switch on if an Auto-Pay Option that references an auto-pay source that references this type of tender must also contain an expiration date (e.g., automatic debit / credit cards).

                                                            Turn this switch off for tender types associated with checking / saving direct debits.

Turn on Allow Cash Back if the system should automatically calculate a cash back amount when a tender is remitted for this tender type and the amount tender exceeds the amount being paid.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_TENDER_TYPE.

Setting Up Tender Sources

A unique Tender Source must exist for every potential source of funds.  For example,

·         Every cashiering station will have a unique tender source.

·         Every lock box will have a unique tender source.

·         Your remittance processor will have a unique tender source.

·         If you allow taxpayers to pay bills automatically (e.g., via EFT), you’ll need a tender source for each institution to which you route automatic payment requests.  For example, if you route automatic payment requests to the automated clearinghouse (ACH), you’ll need a tender source for the ACH.

For example, if you have 3 lock boxes, 2 cash drawers at an area office A, 2 cash drawers at area office B, and a single remittance processor, you’d need the following tender sources:

Tender Source	Type	External Source ID (Lockbox ID)	Default Starting Balance	Currency Code	Suspense Obligation
CASH-A01	Cashiering	N/A	150.00	USD	N/A
CASH-A02	Cashiering	N/A	150.00	USD	N/A
CASH-B01	Cashiering	N/A	150.00	USD	N/A
CASH-B02	Cashiering	N/A	150.00	USD	N/A
LB-INDUS	Lockbox	112910-A	N/A	USD	9291019281
LB-COMM	Lockbox	938219-C	N/A	USD	4739837372
LB-RESID	Lockbox	372829-B	N/A	USD	1912910192
REMIT	Lockbox	N/A	N/A	USD	1920038437
ACH	Auto Pay	N/A	N/A	USD	N/A

To set up a tender source, select Admin Menu, Tender Source.

Description of Page

Enter an easily recognizable Tender Source and Description for the tender source.

Define the Tender Source Type.  Valid values are: Ad Hoc, Auto Pay, Online Cashiering and Lockbox.  The system uses this information to prevent tender controls from different sources from being included under the same deposit control.  In other words, you can’t mix ad hoc, automatic payment, cashiering and lockbox tenders under the same deposit control.

If the source is an external system (e.g., a lockbox or an automatic payment destination), use External Source ID to define the unique identifier of the source.  The background process that interfaces tenders from this source uses this information to create the appropriate tender control when it interfaces payments from external sources.

If this source is a cash drawer, define the Default Starting Balance.  This balance is defaulted onto new tender controls and may be overridden.

If this source is a cash drawer, define the Max Amount Balance.  When the amount of cash-like tenders in a cash drawer exceeds this balance, a warning is issued to remind the cashier to turn in some of the funds to a tender control.

Define the Currency Code of tenders linked to this source.  All tenders in a source must be of the same currency.

If this tender source is associated with payments that are interfaced from an external source (e.g., a lockbox or a remittance processor), use Suspense Obligation to define the obligation whose account will hold uploaded payments with an invalid account.  Refer to Payment Upload Error Obligations for more information about suspense obligations.  Also note, because the payment upload process simply books payments that reference invalid accounts to the account associated with this obligation, this account should belong to an account type with the appropriate payment distribution algorithms.  This may entail creating a new account type that will only be used on these "suspense accounts".  This account type would need the following algorithms:

·         We’d recommend using a simple payment distribution algorithm like PYDIST-PPRTY (distribute payment based on obligation type’s payment priority).

·         We’d recommend using an overpayment distribution algorithm like OVRPY-PPRTY (distribute overpayment to highest priority obligation type).

Define the Bank Code and Bank Account into which the tender source’s moneys will be deposited.  The bank account defines the distribution code used to build the GL details for the payment.  Refer to The Source of GL Accounts on Financial Transactions for more information.  Note that the bank code and bank account can later be overwritten when entering Tender Deposits on Deposit Control.

If this tender source is associated with payments that are interfaced from an external source, for example tender sources associated with Auto Pay and Lockbox Tender Source Types, the information is also used as follows:

·         The payment upload process uses this information to populate the bank and bank account when it creates deposit control records for the tender controls it creates during the interface.  Refer to Managing Payments Interfaced From External Sources for more information.

·         The automatic payment interface uses this information to populate the bank and bank account when it creates deposit control records for the tender controls it creates during the interface.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_TNDR_SRCE.

If your taxpayers can pay their bills automatically (via direct debit or credit card debits), you’ll need to set up the various control tables described in this section.

Contents

Setting Up Auto-Pay Route Types

Setting Up Auto-Pay Source Codes

Setting Up Auto-Pay Route Types

Auto Pay Route Types are used to control when and how automatic payment requests are routed to a financial institution, and when the general ledger is impacted.  Select Admin Menu, Auto Pay Route Type to define your route types.

Description of Page

To modify an auto pay route type, simply move to a field and change its value.

To add a new route type, press + to insert a row, then fill in the information for each field.  The following fields display:

Route Type                                          The unique identifier of the route type.

Description                                          The description of the route type.

Tender Source                                     The background process that routes automatic payment requests to a financial institution (e.g., the automated clearing house interface) will mark each automatic payment’s associated tender with a tender control for audit and control purposes.  The following points describe how this happens:

·         When the system sees that it’s time to send an automatic payment to a financial institution, it looks at the automatic payment’s auto-pay source.

·         Every auto-pay source references an auto-pay route type.

·         Every auto-pay route type references a tender source.

·         A Tender Source has a tender control for each group of tenders deposited / interfaced together one batch. 

·         The system marks each automatic payment’s associated tender with the latest tender control for the Tender Source.  The system will create a new tender control each time it routes automatic payments to the tender source.  Refer to Managing Payments Interfaced From External Sources for more information about tender source and tender control.

Extract Batch Cd                                  This field defines the background process that interfaces the automatic payment requests to the financial institution.

Autopay Date Calculation Alg              This algorithm populates 3 dates associated with the automatic payment: 1) the date the automatic payment will be sent to the financial institution, 2) the date the general ledger will be impacted by the automatic payment, 3) the date of the payment.

                                                            If you haven’t done so already, you must set up this algorithm in the system.  To do this, create a new algorithm (refer to Setting Up Algorithms).  On this algorithm, reference an Algorithm Type that populates automatic payment dates.  Click here to see the algorithm types available for this plug-in spot.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_APAY_RT_TYPE.

Setting Up Auto-Pay Source Codes

A unique Auto-Pay Source must exist for every bank / credit card company / bill payment service that your taxpayer’s use as the source of the funds when they sign up for automatic payment.  For example,

·         Every bank will have a unique auto-pay source.

·         Every credit card company will have a unique auto-pay source.

To set up an auto-pay source, select Admin Menu, Auto Pay Source Type.

Description of Page

Enter an easily recognizable Auto Pay Source Code and Description for the auto-pay source.

The Source Name is the name of the financial institution.

When the system creates an automatic payment request, it also creates an associated payment tender.  This tender (like all tenders) must have a tender type.  This field defines the Tender Type associated with this auto-pay source’s tenders.  Refer to Setting Up Tender Types for more information.

The External Source ID is the unique identifier of the financial institution to which the automatic payment will be routed (e.g., the bank routing ID of the bank).  This field is typically blank on automatic payments routed to credit card companies because the credit card company doesn’t have an external source ID (whereas direct debits from banks must have a bank routing number).  Whether this field is required is controlled by the Tender Type.

The Auto Pay Route Type controls when and how automatic payment requests get routed to a financial institution.  It also controls when the general ledger is impacted by the automatic payments financial transaction.  Refer to Setting Up Auto-Pay Route Types for more information.

The Work Calendar defines the financial institution’s workdays.  This information is used to determine the date on which automatic payment requests will be sent to the financial institution.  Refer to Setting Up External Workday Calendars for more information.

The Validation Algorithm defines how the system validates the taxpayer’s account ID at the financial institution.  If you haven’t done so already, you must set up this algorithm in the system.  To do this:

·         Create a new algorithm (refer to Setting Up Algorithms).

·         On this algorithm, reference an Algorithm Type that validates the taxpayer’s account ID at the financial institution.  Click here to see the algorithm types available for this plug-in spot.

Refer to Account – Auto Pay for more information.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_APAY_SRC.

The topics in this section provide background information about payment advice functionality. 

Contents

What Is A Payment Advice?

Payment Advice vs. Direct Debit

Setting Up The System To Enable Payment Advices

What Is A Payment Advice?

Payment advice is a money order that is established at the initiative of the tax authority.  When a bill is completed, the tax authority sends the taxpayer a document that indicates a payment amount and the taxpayer’s bank details.  If the taxpayer agrees to the information on the payment advice, he or she signs it and returns it to the clearinghouse address that is indicated on the payment advice.  The clearinghouse, in turn, sends the dated and signed payment advice to the taxpayer’s bank, which completes the payment. 

Payment Advice vs. Direct Debit

The existing functionality that creates automatic payments is referred to as direct debit processing.  Payment advice processing differs from direct debit processing in the way that automatic payments get initiated.  With payment advice processing, the usual automatic payment records - i.e. payment event, payment, tender and auto pay clearinghouse staging – are not created.  Instead, a payment advice is printed and sent to the taxpayer.  The taxpayer sends the approved payment advice directly to the clearinghouse.

Setting Up The System To Enable Payment Advices

You must set up a Feature Configuration to define parameters that control payment advice functionality. 

The following points describe the various Option Types that must be defined:

·         Payment Advice Functionality Supported.  This option controls whether the system allows for payment advice processing. 

·         Enter Y if the system should allow for both direct debit and payment advice processing.   

·         Enter N if the system should only allow for direct debit processing. 

·         Default Auto Pay Method.  This option is used for defaulting the auto pay method on new account auto pay records.

Refer to Account – Auto Pay for more information on auto pay method.

The base package, by default, creates a single payment for a payment event.  If your business requires potentially many payments to be created when payment events are added, you’ll need to set up the various control tables described in this section.

Contents

Making Payments Using Distribution Rules

Common Distribution Rules

Payments Linked To Assessments

Setting Up The System To Use Distribution Rules

Making Payments Using Distribution Rules

As part of this method, one or more distribution details are provided at payment time along with the usual payment and tender information.  Each distribution detail record references a distribution rule and a corresponding value.  The distribution rule encapsulates the business rules that govern the distribution of the payment amount into payments using the specified value. 

The type of value being captured on the distribution detail and the logic that uses it to create payments are defined on the distribution rule.

Contents

Rule Value

Determine Tender Account

Creating Payment(s)

Rule Value Can Capture Additional Information

Rule Value

The primary use of the rule value is to identify the business entity whose balance is to be relieved by creating payment(s).  In most cases where the payor account is the same as the payee account it may also used to identify the tender account associated with the payment(s). 

Determine Tender Account

The very first step in processing a distribution detail is to identify the tender account (i.e. the payor) associated with the payment.  To do that the system calls the Determine Tender Account algorithm defined on the distribution rule providing it with the rule value and other tender information.         

Creating Payment(s)

The business logic that distributes a payment amount into one or more payments(s) targeted towards the entity identified by a rule value is held in designated Create Payment algorithms defined on the distribution rule.

Rule Value Can Capture Additional Information

A rule value can also be used to capture additional information provided at payment time, like address information, comments, etc.  Obviously payment distribution details with this type of rule value should have a zero payment amount, as they are not real payments.  These distribution details end up being linked to a payment event, but unlike other distribution details they do not contribute any payments.  You can think of these details as payment event characteristics. 

You don't have to set up a Create Payment algorithm for distribution rules intended solely to capture additional payment information. 

The base package provides a sample Distribution Rule - Create Payment C1-PAYFRM that caters for multiple distributions rule values. 

Common Distribution Rules

Tax authorities have complex payment distribution rules.  Most of these rules follow a similar pattern, with a few key differences.

The following lists common payment distribution methods:

·         Pay a specific obligation.

·         Pay all the accounts of the taxpayer.

·         Pay an account.

·         Pay a specific filing period.  This is common for estimated payments where a payment form indicates the filing period.  Some tax authorities may use paper forms in check processing that indicate the filing period to which the payment should apply.  This information is keypunched with the payment.  The base package provides Distribution Rule - Create Payment C1-PAYFRM for paying a filing period.  Refer to Directing a Payment to a Form or Filing Period for more details.

·         Pay a tax form.  The payment is directed to the obligation on the tax form.  The base package provides Distribution Rule - Create Payment C1-PAYFRM for paying a form.  Refer to Directing a Payment to a Form or Filing Period for more details.

·         Pay a pay plan.  The payment is directed to the obligations that the pay plan covers.  The base package provides a Distribution Rule - Create Payment algorithm C1-DR-PAYPP for paying a pay plan.  Refer to Distributing Payments for Pay Plans for more details.

·         Pay a collection case.  The payment is directed to what the collection case is collecting on - e.g. obligations, assessments, etc.

·         Pay a collection letter.  A collection letter can be generated from overdue processing.  The payment is directed to what the overdue process is collecting on - e.g. obligations, assessments, etc.

Payments Linked To Assessments

When dynamic credit allocation is practiced, a payment targeted to a specific assessment must have the payment FT referencing the assessment's FT ID.  If there is excess credit on the payment segment, it is dynamically allocated to any other assessments for the obligation. 

The base package provides a payment freeze algorithm C1-PYFZ-PYAS that links a payment FT to a specific assessment.  This algorithm looks for a match value on the payment that references the assessment.  The assessment is linked to the payment by populating the assessment's FT ID on the payment FT's Group FT ID field.

For more information, refer to Credit Allocation.

Setting Up The System To Use Distribution Rules

Contents

Setting Up Distribution Rules

Feature Configuration

Set Up Account Type

Set Up Match Type

Setting Up Distribution Rules

Define a Distribution Rule for each payment event distribution method practiced by your business.   

Contents

Distribution Rule - Main

Distribution Rule - Algorithms

Distribution Rule - Main

To set up a distribution rule, navigate to Admin Menu, Distribution Rule.

Description of Page

Enter a unique Distribution Rule and Description for the distribution rule. 

Provide a short and unique Distribution Rule Label to be used as rule's name throughout the system.

Characteristic Type defines the type of entity whose balance is relieved by the payment(s) this rule creates.  For example, if this rule targets payments(s) towards a specific obligation, you'd reference a characteristic that its value identifies an obligation.  We use the term "rule value" for the characteristic value. 

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_DST_RULE

Distribution Rule - Algorithms

Navigate to Admin, Distribution Rule, Algorithms to set up the algorithms appropriate for your distribution rule.

The Algorithms grid contains algorithms that control important functions.  You must define the following for each algorithm:

·         Specify the algorithm's System Event (see the following table for a description of all possible events).

·         Specify the Algorithm to be executed when the System Event executes.  Set the Sequence to 10 unless you have a System Event that has multiple Algorithms.  In this case, you need to tell the system the Sequence in which they should execute.

The following table describes each System Event (note, all system event's are optional and you can define an unlimited number of algorithms for each event).

System Event	Optional / Required	Description
Create Payment	Optional	This algorithm is executed to distribute a payment distribution detail payment amount into one or more payments.  Click here to see the algorithm types available for this system event.
Determine Tender Account	Optional	This algorithm is executed to determine the tender account associated with the payment distribution detail.  Only one such algorithm may be specified. Click here to see the algorithm types available for this system event.

Feature Configuration

You must set up a Feature Configuration to define parameters that control various payment event distribution options.  The following is an example of how the Feature Configuration would look for an implementation:

The following points describe the various Option Types that must be defined:

·         Always Enable Distribution Rule.  This option controls whether the system should only use the distribution rule method to add payment events or rather allow both the default method and the distribution rule method to coexist. 

·         Enter Y if the system should always use distribution rules.  With this setting, navigation to the Payment Event page in add mode opens up the Payment Event Quick Add page (defaulting it to the single payment event dialog).  This dialog is designed to create a payment event using distribution rules.

·         Enter N if the system should allow both methods.  With this setting, navigation to the Payment Event page in add mode opens up the standard Payment Event - Add Dialog that uses the default method to create a payment event.  If you want to use the distribution rule method, navigate to the Payment Event Quick Add page from the menu. 

·         Default Distribution Rule.  This option states your default distribution rule that appears throughout the system. 

Set Up Account Type

If you do dynamic credit allocation, set up the payment freeze algorithm C1-PYFZ-PYAS.

We recommend specifying payment distribution and overpayment algorithms because they are used as default logic in case distribution rules are not supplied.

Set Up Match Type

If you use set the payment freeze algorithm C1-PYFZ-PYAS, set up a match type for assessment.  This match type should NOT reference an override payment distribution algorithm (if this algorithm is blank, the account type’s payment distribution algorithm is used).  Refer to Payments Linked to Assessments for more details.

As described in The Financial Big Picture, the various types of financial transactions can be canceled if their financial impact needs to be reversed from the system.  Whenever a financial transaction is canceled, a cancel reason must be specified.  This section describes the control tables that contain the cancel reason codes.

Contents

Setting Up Bill (Segment) Cancellation Reasons

Setting Up Payment Cancellation Reasons

Setting Up Adjustment Cancellation Reasons

Setting Up Bill (Segment) Cancellation Reasons

Open Admin Menu, Bill Cancel Reason to define your bill segment cancellation reason codes.

Description of Page

Enter an easily recognizable Cancel Reason and Description for the bill cancellation reason.

Only use System Default on those reason codes that are placed on bill segments that are automatically canceled by the system.  Valid values are: Turn off auto-cancel, Bad estimated read auto-cancel,and Mass Cancel.  The reason code identified as Turn off auto-cancel is placed on bill segments that are automatically canceled when the final bill segment ends before the prior bill (and therefore we have to cancel the prior bill).  The reason code identified as Bad estimated read auto-cancel is placed on bill segments that are automatically canceled by the system when it detects that it used an estimated read whose consumption is greater than the next actual read (and therefore we have to cancel the estimated bill segment).  The reason code identified as Mass Cancel is placed on bill segments that are canceled as a result of the execution of the Mass Cancellation background process.  Refer to Mass Cancellation for more information.

Setting Up Payment Cancellation Reasons

Open Admin Menu, Pay Cancel Reason to define your payment cancellation reason codes.

Description of Page

Enter an easily recognizable Cancel Reason and Description for the payment cancellation reason.

Turn on the NSF Charge switch if the system should invoke the non-sufficient funds (NSF) algorithm when a tender is cancelled using this reason code.  Refer to NSF Cancellations for more information.

The following fields are used to change an account’s compliance rating if a tender is canceled using the respective reason code.

·         Use Affect Compliance Rating By to define how tenders canceled using this reason will affect the account’s compliance rating.  This should be a negative number.  A taxpayer’s compliance rating is equal to the start compliance rating amount defined on the installation record plus the sum of compliance rating demerits that are currently in effect.

·         Use Months Affecting Compliance Rating to define the length of time the demerit remains in effect.  This information is used to define the effective period of the compliance rating demerit record.

The System Default Flag is specified on those cancellation reasons that are placed on payment segments that are automatically cancelled by the system.  Valid values are: Re-opened Bill.  The Re-opened Bill value is used as follows:

·         Payments are automatically created for accounts who pay their bills automatically when their bills are completed.

·         If such a bill is reopened before the automatic payment is interfaced to the paying authority, the system automatically cancels the payment.  The Re-opened Bill cancellation reason is placed on such payments.

Setting Up Adjustment Cancellation Reasons

Open Admin Menu, Adjustment Cancel Reason to define your adjustment cancellation reason codes.

Description of Page

Enter an easily recognizable Cancel Reason and Description for each adjustment cancellation reason.

This section describes miscellaneous control tables.

Contents

A/P Check Request

Bill Charge Line Type

A/P Check Request

Adjustments whose adjustment type is marked with an A/P check request code are interfaced to your A/P system.  Your A/P system then cuts the checks.

You must set up at least one A/P check request code if you want A/P to cut checks. 

To set up A/P check request types, open Admin Menu, A/P Request Type.

Description of Page

Enter an easily recognizable A/P Request Type for the accounts payable request type.

Use Due Days to define when the check is cut.  The cut date is equal to the adjustment date plus due days.

Select a Payment Method.  Choose from these options:

System Check                                      System check

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_APREQ_TYPE.

Bill Charge Line Type

Billable charge line types will simplify the effort required to interface billable charges from an external system.  Each line type contains values that will be defaulted onto the line details associated with the uploaded billable charges.  Obviously, this defaulting is possible only if you specify a billable charge line type on the billable charge upload staging lines.

To set up billable charge line types, select Admin Menu, Bill Charge Line Type.

Description of Page

Enter an easily recognizable Bill Charge Line External Type and Description.

Use Currency Code to define the currency to be defaulted onto billable charge upload lines that reference this line type.

Use Show on Bill to define the value to be defaulted into the Show on Bill indicator on billable charge upload lines that reference this line type.

Use App in Summary to define the value to be defaulted into the App in Summary indicator on billable charge upload lines that reference this line type.

Use Memo Only, No GL to define the value to be defaulted into the Memo Only, No GL indicator on billable charge upload lines that reference this line type.

Use Distribution Code to define the values to be defaulted into the Distribution Code field on billable charge upload lines that reference this line type.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_BCHG_UP_XTYP.

In some cases certain amounts such as sales tax distributions and 3rd party liabilities are not truly payable until the taxpayer remits payment.  We refer to this as "payables cash accounting".  This practice should be contrasted with "payables accrual accounting" in which the liability is realized when the bill is created (as opposed to when it is paid).

If your organization does not practice payable cash accounting, you may skip this section as accrual accounting is the system default.  If you practice payables cash accounting, the contents of this section describe how to configure the system appropriately.

Contents

Accrual versus Cash Accounting Example

Distribution Code Controls Cash Accounting For A GL Account

Cash Accounting and Incurring Debt

Cash Accounting and Relieving Debt

Accrual versus Cash Accounting Example

Accrual accounting means that all payables are booked when the debt financial transaction (bill segment or adjustment) is created. 

If the payable is subject to payables cash accounting, the liability is not booked when the bill segment or adjustment is created, rather, the amount of the liability is placed in a "holding" GL account.  When the taxpayer pays, the moneys are transferred from the "holding" GL account to the true tax payable account.

The following is an example of the financial events that transpire when a simple sales tax assessment is posted and a payment is received using accrual accounting.

Event	GL Accounting	County A Payable Balance
Tax assessment created	A/R 110 Revenue - State <100> Payable - County A <10>	(10)
Payment received	Cash 110 A/R <110>	(10)

In the above example, you’ll notice that the payable is booked when the adjustment is created.  Let’s contrast this with what takes place if the payable is subject to payables cash accounting.

Event	GL Accounting	County A Payable Balance	County A Holding Balance
Tax assessment created	A/R 110 Revenue - State <100> Holding - County A <10>	0	(10)
Payment received	Cash 110 A/R <110> Holding - County A 10 Payable - County A <10>	(10)	0

Notice that when the adjustment is created, the payable for the county is not booked, rather, the amount is placed in a “holding” GL account.  When the taxpayer pays, the moneys are transferred from the “holding” GL account to the true County A payable account.

If the above seems simple, consider the following complications that must be considered:

·         What happens if a partial payment is received?

·         What happens if there are multiple amounts subject to cash accounting rules?

·         What happens if the payment is cancelled?

·         What if the payment isn’t received and we have to write-off debt?

·         What happens if the taxpayer overpays?

·         What happens if the obligation is subject to penalty and interest and dynamic credit allocation?

The above points, and more, are discussed below.

Distribution Code Controls Cash Accounting For A GL Account

Whether or not cash accounting is used for a specific GL account is defined on HOLDING GL account’s distribution code (i.e., the holding GL account references the true payable account).

It is very important that unique payable and holding distribution codes be used for each type of amount subject to cash accounting rules.  For example, for sales tax distribution, a pair of payable and holding accounts is required for each separate distribution amount.

Without unique distribution codes for each payable and holding account, the system cannot keep track of how much of a given amount is being held, awaiting payment.

Cash Accounting and Incurring Debt

When calculating debt that includes payables, the distribution codes associated with the payables (for example on the rate components that calculate payables) must be the holding payable distribution codes.  No other logic is needed for cash accounting at this time.

Cash Accounting and Relieving Debt

The following section describes functionality required for obligations that practice cash accounting and do NOT practice penalty and interest or dynamic credit allocation.

Contents

Payment Segment Financial Transaction Algorithms Transfer Holding Amounts to Payable GL

How Does The System Know What Amounts To Transfer From Holding To Payables?

Partial Payments Result In Partial Payables

Adjustments That Behave Like Payments

Overpayment Of Taxes Due To Cancel/Rebills

Cash Refunds

Over Payments

Payment Segment Financial Transaction Algorithms Transfer Holding Amounts to Payable GL Accounts

Logic exists in the pay segment’s FT algorithm that transfers amounts from payable holding distribution codes to their respective payable real distribution codes. 

The following table shows what happens to the financial transaction associated with the payment segment for a cash accounting taxpayer.

Event	GL Accounting
Adjustment is created	A/R 110 Revenue - State <100> County Holding <10>
Payment segment relieves receivables	Cash 110 A/R <110>
Additional GL details created when the payment segment FT algorithm transfers the holding amount to a payable account	County Holding 10 County Payable  <10>
Net affect of the above	Cash 110 A/R <110> County Holding 10 County Payable <10>

How Does The System Know What Amounts To Transfer From Holding To Payables?

When a payment segment is created for an account that is subject to cash accounting processing, the system determines if there is a credit balance for any holding distribution code in respect of the obligation.  If so, it generates additional GL details to transfer moneys from the holding distribution code to the payable distribution code in proportion to the amount of receivables relieved by the payment.  Therefore, if 100% of receivables are relieved by the payment segment, 100% of the holding amounts will be transferred to payable distribution codes.  Refer to Partial Payments Result In Partial Payables for an example of what happens when a partial payment is created. 

Partial Payments Result In Partial Payables

The previous example showed the entire County holding amount being transferred to the County payable account.  The entire holding amount was transferred because the obligation was paid in full.  If a partial payment is received, only part of the holding amount will be transferred to the payable amount (proportional to the amount of receivables reduced by the payment).  An example will help make the point. 

Event	GL Accounting	County Payable Balance	County Holding Balance
Adjustment created	A/R 110 Revenue - State <100> County Holding <10>	0	(10)
Partial payment received	Cash 27.50 A/R <27.50> County Holding 2.50 County Payable <2.50>	(2.50)	(7.50)

Adjustments That Behave Like Payments

There are several types of adjustments that behave just like payments (in respect of payables cash accounting), for example an overpayment transferred one obligation to another

The above events should cause the system to transfer holding amounts to true payable amounts (notice that the above examples are all transfer adjustments).

However, there are many other adjustments that should not behave like payments.  You control how the adjustment works by selecting the appropriate FT algorithm when you set up adjustment types (refer to ADJT-AC and ADJT-TC for a description of the base package algorithms that causes the holding amounts to be manipulated in proportion to the amount of receivable being adjusted).  In other words, there are adjustment FT algorithms that cause the transference of holding payable amounts to real payable amounts when the A/R balance is decreased by the adjustment.

Overpayment Of Taxes Due To Cancel/Rebills

Lets assume a cancel / rebill occurs after a payment is received and the net affect of the cancel / rebill is that the taxpayer has overpaid their taxes.

Event	GL Accounting	County Payable Balance	County Holding Balance
Bill segment created	A/R 110 Revenue - State <100> County Holding <10>	0	(10)
Payment received	Cash 110 A/R <110> County Holding 10 County Payable <10>	(10)	0
Cancel	A/R <110> Revenue 100 County Holding 10	(10)	10
Rebill	A/R 27.50 Revenue <25> County Holding <2.50>	(10)	7.50

You’ll notice that the amount payable to the county still indicates $10 (the amount of amount that was paid by the taxpayer).  However, you’ll notice that the county holding balance is 7.50 (debit).  This looks a bit odd, but it’s correct.  Remember that at this point, the taxpayer has a credit balance of $75 and this will be whittled down as successive bills are produced as shown below.  Note: refer to Cash Refunds for an example of what happens if you refund the credit with a check rather than letting it whittle down.

Event	GL Accounting	County Payable Balance	County Holding Balance
		(10)	7.50
Bill segment created	A/R 55 Revenue <50> County Holding <5>	(10)	2.50
Bill segment created	A/R 110 Revenue <100> County Holding <10>	(10)	(7.50)

In the unlikely event of a payment being received while the county holding has a debit balance, nothing will be done in respect of transferring funds from holding to payable (there is nothing to transfer).

Cash Refunds

If you refund moneys to a cash accounting taxpayer, it’s important to do the opposite of what was done when the payment was received (i.e., you need to transfer the payable back to the holding account).  The following example should help clarify this situation (this example shows a refund due to a credit balance that occurred as a result of a cancel/rebill).

Event	GL Accounting	County Payable Balance	County Holding Balance	Obligation’s Payoff Balance
Bill segment created	A/R 110 Revenue <100> County Holding <10>	0	(10)	110
Payment received	Cash 110 A/R <110> County Holding 10 County Payable <10>	(10)	0	0
Cancel	A/R <110> Revenue 100 County Holding 10	(10)	10	(110)
Rebill	A/R 27.50 Revenue <25> County Holding <2.50>	(10)	7.50	(82.50)
Payment refunded (via an A/P adjustment)	Cash <82.50> A/R 82.50 County Holding <7.50> County Payable 7.50	(2.50)	0	0

We understand this is tricky, but consider this - when a cash accounting taxpayer makes a payment, the system transfers county holding credit balances to county payable distribution codes in proportion to the amount of the receivable debit amount that was reduced by the payment.  Therefore, when cash is returned to the taxpayer, the system should transfer county holding debit balances to county payable distribution codes in proportion to the amount of the receivable credit that was reduced by the refund.

Over Payments

If a taxpayer overpays a tax amount (i.e., we receive more cash than receivables), we strongly recommend you set up the system to NOT keep the excess credit on the taxpayer’s regular obligation.  Rather, we recommend you segregate the receivable onto an “excess credit” obligation.  If you do this, the system can transfer any excess credits to the regular obligations at bill completion time or at form posting time.  When this transfer occurs, the same accounting described under Payments Segment Financial Transaction Algorithms Transfer Holding Amounts To Payable GL Accounts occurs as shown in the following example.  Note: this example assumes an excess credit of $110 was transferred to a normal obligation and the normal obligation had $10 of held payables.

Event	Normal Obligation GL Accounting	Excess Credit Obligation GL Accounting
Bill segment created	A/R 110 Revenue <100> County Holding <10>
Payment of $300 is received	Cash 110 A/R <110> County Holding 10 County Payable <10>	Cash 190 Overpay <190>
Bill segment created	A/R 110 Revenue <100> County Holding <10>
Transfer excess credit amount to normal obligation (when bill is completed).	Xfer 110 A/R <110>	Overpay 110 Xfer <110>
Because the transfer adjustment is the equivalent of a cash relief outstanding county holding is relieved in proportion to the amount of receivables that are reduced by the transfer	County Holding 10 County Payable  <10>
Net affect of the transfer	Xfer 110 A/R <110> County Holding 10 County Payable <10>	Overpay 110 Xfer <110>

The topics in this section provide background information about open-item accounting. 

Contents

Open-Item Versus Balance-Forward Accounting

Accounting Method Defined On Your Account Types

Match Events

Disputing Items

Overpayments

Setting Up The System To Enable Open Item Accounting

Setting Up Match Types

Setting Up Match Event Cancellation Reasons

Open-Item Versus Balance-Forward Accounting

If you practice open-item accounting, you match payments against bills.  The term "open-item accounting" is used to describe this accounting practice because:

·         Payments are matched against  "open items" (i.e., unpaid bills and adjustments)

·         Only unmatched bills and adjustments (i.e., open items) affect aged debt.

Contrast open-item accounting with "balance-forward" accounting - in a balance-forward world, payments are not matched to bills.  Rather, payments implicitly relieve a taxpayer’s oldest debt. 

Accounting Method Defined On Your Account Types

You define the type of accounting method that is practiced (balance-forward versus open-item) on your account types.  The account type should be configured based on the accounting method practiced for that tax type.

Match Events

Match events are used to match open-items (i.e., debit and credit financial transactions) together.  The topics in this section provide an overview of match events.

Contents

Match Events Match Debit FTs To Credit FTs

When Are Match Events Created?

Match Event Lifecycle

Payments And Match Events

How Are Match Events Cancelled?

Current Amount Is Matched, Not Payoff

Match Events Match Debit FTs To Credit FTs

For open-item taxpayers, the system matches credit financial transactions (FT’s) to debit FT’s under a match event.  The following are important points about match events.

·         A match event may contain an unlimited number of FT’s. For example, the match event can match 2 credit FTs against a single debit FT.

·         A match event contains FTs associated with a single account.  While the FTs under a match event may belong to multiple obligations, all FTs under a match event must belong to the same account.

·         The status of the match event is balanced when the sum of the debits equals the sum of the credits.  If debits do not equal credits, the status of the match event is open and the various FTs would still affect the taxpayer’s aged debt.  Refer to Match Event Lifecycle for more information.

When Are Match Events Created?

The following points describe when match events are created for open-item accounts:

·         The system can create one or many match events when a payment is added.  This match event matches the payment’s credit FTs with the debit and credit FTs from bill segments and adjustments.  The FTs that are linked to the match event are controlled by the payment’s match type and match value (payments made by open-item taxpayers must reference a match type and match value).  Refer to Payments And Match Events for more information.

·         The system may create a match event when any type of financial transaction is cancelled.  This match event groups together the original FT with its cancellation FT.  Refer to How Are Match Events Cancelled? for more information.

·         The system creates a match event when a bill is completed for taxpayers that pay automatically (i.e., direct debit taxpayers).  The match event groups together the bill’s new charges against the automatic payment’s payment segments.

·         The system creates a match event when a bill is completed where the new charges are offset by other financial transactions.

·         The system creates a match event when an obligation closes and the obligation has unmatched FTs.  For example, consider an obligation for debt that is written off.  This obligation closes when the system creates transfer adjustments to transfer the debt to a write-off obligation (or writes down the debt).  The system creates a match event to match the original debt to the transfer adjustments used to write-off the debt. 

·         A user can create a match event manually at any time.  Manual match events would be created under a variety of situations.  For example:

·         If a taxpayer disputes a charge.  Refer to Disputing Items for more information about disputes.

·         To handle unusual situations when the system is unable to automatically match FT’s together.

Match Event Lifecycle

The following diagram shows the possible lifecycle of a match event:

Match events are initially created in the open state.  Financial transactions (FT’s) linked to open match events affect arrears, but not in an open-item fashion.  Rather, FT’s linked to open match events affect arrears in a balance-forward fashion.  Refer to Open Item Versus Balance Forward Accounting for more information about these two accounting methods.

A user may delete an open match event.  When an open match event is deleted, its FT’s may be linked to other match events.

The system automatically changes an open event’s status to balanced when the sum of the debit financial transactions (FT’s) equals the sum of the credit FT’s for each obligation on the match event.  It’s worth stressing that a match event may contain FT’s from many obligation’s and each obligation’s FT’s must sum to zero before the match event can become balanced.

A user may reopen a balanced event (by adding / removing FT’s so that the match event becomes unbalanced).

A user may cancel a balanced or open match event.  Refer to How Are Match Events Cancelled? for more information about cancellation.

Payments And Match Events

As described under When Are Match Events Created?, the system creates a match event when a payment is added for an open-item account.  The system uses the payment’s match type and match value to determine the FT’s (e.g., bill segments and adjustments) that will be matched with the payment’s FT’s (i.e., the payment segments). 

Another way to think of this is as follows:

·         When most payments are distributed, the system calls the payment distribution algorithm that is plugged-in on the account’s account type.

·         However, a payment that is made in respect of a specific bill requires a different distribution algorithm because the payment should only be distributed amongst the debt associated with the specific bill being paid.  This is accomplished by referencing a match type / match value on the payment.  The match type references the appropriate payment distribution algorithm.  This algorithm is used rather than the account type distribution algorithm.

For example, if a payment were made in respect of bill ID 192910192101, this payment would reference a match type of bill ID and a match value of 192910192101.  At payment distribution time, the system calls the override payment distribution algorithm associated with this match type.  The base package bill ID distribution algorithm does several things:

·         It distributes the payment amongst obligations associated with the bill.

·         It creates a match event and links the bill’s bill segment and adjustment FT’s to it.

·         Refer to the Bill ID Match Type Algorithm for more information about this algorithm.

It’s worth noting that payment distribution and freezing are two separate steps that typically happen in quick succession.  The system’s standard match event algorithms create the match event during payment distribution.  This match event exists in the open state (because the payment segment’s FT’s have not yet been linked to the match event and therefore debit FT’s do not equal credit FT’s).  The open match event references the debit FT’s (the bill segments and adjustments) for which it pays.  It is only at payment freeze time that the credit FT’s (the payment segments) are linked to the match event thus allowing the match event to be become balanced.

If, at freeze time, the payment’s credit FT’s do not equal the debit FT’s on the match event, the match event is left in the open state.  An alert will appear on Control Central to highlight the existence of open match events (if the appropriate alert algorithm is plugged in the installation record).  In addition, you can also set up a ToDo entry to highlight the existence of open match events.

How Are Match Events Cancelled?

A user can cancel an open or balanced match event at any time.  When a match event is cancelled, the event’s FT’s again affect arrears (and they can be associated with new match events).  In other words, when a match event is cancelled, its FT’s are released from the match event and become open-items.

In addition to manual cancellation, the system may automatically cancel a match event when the last of its payment FT’s, if any, is cancelled (if you plug-in the appropriate FT freeze plug-in on your open-item account types).

For example, consider a match event that was created when a payment was made.  If the payment is subsequently cancelled, the match event is also cancelled (thus releasing the match event’s FT’s) if no other payment FT’s are linked to the match event.  Please be aware that FT cancellation also causes a new match event to be created.  This match event matches the original FT (the payment segment) and its cancellation FT.  This means that the only "open items" that will exist after a payment is cancelled are the debit FT’s that were originally paid. 

While payment cancellation is the most common type of FT cancellation, be aware that bill segment or adjustment cancellation may also cause a new match event to be created.  We don’t necessarily want to always link the cancellation FT and its original FT to the same match event.  For example, when the cancellation FT is swept on to the next bill it affects the next bill and not the original FT’s bill.  For cancellations that will not be swept on to the next bill (payment cancellation, cancellation of an adjustment that is not shown on bill, and bill segment cancellation before the bill is completed) the system creates a new match event that matches the original FT and its cancellation FT.  This way, neither FT affects aged debt.  If the original FT was linked to an existing match event and no other FTs are left on this match event it is automatically canceled. 

Current Amount Is Matched, Not Payoff

The system matches the current amount of financial transactions, not the payoff amount.

Disputing Items

Open-item taxpayers may dispute FT’s that they are not comfortable paying.  For example, a taxpayer who receives a bill with an anomalous charge may decide to dispute it.

When an open-item taxpayer disputes a charge, a user creates a match event and links the disputed FT(s) to it.  This match event will be in the open state (because it does not contain FT’s that sum to zero).  In addition, the match event’s "disputed switch" is turned on. 

While the dispute is being researched, the disputed amount will not affect aged debt, but it still forms part of the taxpayer’s balance. 

If the dispute goes in your company’s favor, the disputed match event should be cancelled (thus allowing the FT’s to again impact aged debt). 

If the dispute goes in the taxpayer’s favor,

·         You may decide to cancel the offending bill segment(s) / adjustment(s).  As described above, these cancellations are going to be swept on to the next bill.  The system therefore will not automatically cancel the disputed match event.  Notice that the cancellation effect of the disputed items is carried over on to the next bill.  This means that the previously disputed items still need to be paid.  

·         You may decide to issue an adjustment to counter the effect of the disputed FT’s.  In this situation, you would simply link the adjustment FT to the disputed FT’s (thus allowing the match event to become balanced).  It is important to use in this case an adjustment that does not show on bill. 

Overpayments

An overpayment, by definition, does not "match" to open items.  However, the match type algorithms supplied with the base package will result in a balanced match event if an overpayment is made.  The following points explain how this is achieved:

·         The base package’s match type algorithms will distribute the payment until the taxpayer’s current debt is satisfied.

·         The amount of the overpayment will be kept on a separate obligation (this only happens if you plug-in the appropriate Overpayment Distribution algorithm on your account types).  Refer to Overpayment Obligations for more information.

·         When the payment is frozen, the payment segments that satisfy current debt will be matched against their respective open-items.  The payment segment used to book the overpayment (on the overpayment obligation) will not be matched.

·         When future bills are completed, the credit balance on this "overpayment obligation" will be transferred to the "real obligation’s" when future bills are completed (if you have plugged in the appropriate bill completion algorithm on the overpayment obligation’s obligation type).  If the overpayment satisfies all newly calculated charges, a match event is created that matches the new charges against the funds transferred from the overpayment obligation.  Refer to When Are Match Events Created for information about how the system creates match events at bill completion time when the new charges on the bill are satisfied by other credits such as overpayments.

·         At some point in the future, the overpayment will be exhausted (i.e., all funds will be transferred to "real obligation’s").  At that point in time, the overpayment obligation will close (assuming you set up the overpayment obligation’s obligation type as a "one time").  At close time, the system creates a match event that matches the original overpayment payment segment with the adjustments that were used to transfer funds to the "real obligation’s". Refer to When Are Match Events Created for information about how the system creates match events when an obligation closes.

Setting Up The System To Enable Open Item Accounting

The following section provides an overview of how to enable open-item accounting.

Contents

Match Type Setup

Match Event Cancellation Reason Setup

Account Type Setup

Overpayment Obligation Type Setup

Installation Record Setup

ToDo Entry Setup

Match Type Setup

The number of match types that you will need is dependent on the number of ways you want payments to be matched to open items.  At a minimum, you will probably need the following match types:

·         Bill ID.  This match type should reference an override payment distribution algorithm that distributes the payment based on the bill ID specified on the payment (in match value).  Refer to Payments And Match Events for more information.

·         Obligation ID.  This match type should reference an override payment distribution algorithm that distributes the payment based on the obligation ID specified on the payment (in match value).  Refer to Payments And Match Events for more information.

·         Pay Plan.  This match type should NOT reference an override payment distribution algorithm (if this algorithm is blank, the account type’s payment distribution algorithm is used).  Refer to Pay Plans for more information.

Match Event Cancellation Reason Setup

The number of match event cancellation reasons that you will need is dependent on the number of ways your organization can justify the cancellation of a match event.  At a minimum, you will probably need the following match event cancellation reasons:

·         FT Cancellation.  This cancel reason should be referenced on the account type FT Freeze algorithm that is responsible for canceling match events when one of its financial transactions is cancelled.

·         Incorrect Allocation.  This cancel reason should be specified by users when they cancel match events that were created by the system erroneously.

Account Type Setup

The following points describe account type oriented set up functions:

·         Turn on the open-item accounting switch.

·         Set up the following algorithms for each division:

·         Specify a payment freeze algorithm that causes a payment’s FT’s to be linked to the match event that was created when the payment was distributed.  Refer to Payments And Match Events for more information.

·         Specify a FT freeze algorithm that causes match events to be cancelled (and a new match event to be created) when a FT is cancelled.  Refer to How Are Match Events Cancelled for more information about cancellation.

·         We strongly recommend specifying an overpayment algorithm that causes overpayments to be segregated onto an "excess credit / overpayment" obligation. Refer to Overpayments for more information.

Overpayment Obligation Type Setup

Specify a bill completion algorithm that causes the credit amount on overpayment obligation’s to be transferred to newly create debt (created when the bill is created).  This algorithm transfers an overpayment obligation’s balance to regular obligation’s and creates a match event if the overpayment covers the entire bill.  Refer to Overpayments for more information.

Installation Record Setup

Specify an automatic payment algorithm that causes a match event to be created when automatic payments are created for open-item accounts.  The base package algorithm will do this for you if you specify the appropriate parameter on the algorithm.  Refer to APAY-CREATE for more information about this algorithm.

If you want a Control Central alert to highlight when the current account has any open match events, plug in the appropriate control central alert algorithm on your installation record.  Refer to C1-OPN-MEVT for more information about this algorithm. 

If you want to enable manual pay segment distribution for open item accounts, along with other functions, you will need to plug in an installation algorithm for bill balance calculation.  Refer to C1-OI-BI-AMT for more information about this algorithm.

ToDo Entry Setup

Two ToDo types are supplied with the base package:

·         TD-MODTL.  This ToDo type highlights the presence of open, disputed match events.

·         TD-MONTL.  This ToDo type highlights the presence of open, non-disputed match events.

Each of the above ToDo types should be configured with the roles that work on entries of each type.

In addition, the account management group and/or divisions from which the default roles are extracted should be updated to define the role that should be defaulted for each of the above ToDo types.

Setting Up Match Types

Most payments are distributed amongst obligations using the payment distribution algorithm specified on the payment’s account’s account type.  This algorithm decides how to distribute a payment amongst an account’s existing debt if the taxpayer doesn’t specify how the payment should be distributed.

A taxpayer can specify how a payment is distributed by specifying a match type and match value on their payments.  Consider the following examples:

·         Taxpayers that are subject to open-item accounting (this is defined on the account’s account type) tell the system exactly which debt is covered by their payments.  For example, an open-item taxpayer might make a payment in respect of bill ID 123919101919. 

·         Even non open-item taxpayers can direct payments to specific obligations.  For example, the system allows a balance-forward taxpayer’s payment to be directed to a specific obligation (however, they cannot direct payments to specific bills as only open-item taxpayers can do this).

Match types are used to define the specific type of debt that is covered by a payment.  The match type contains the algorithm that effectively overrides the standard payment distribution algorithm defined on the account’s account type.

To set up match types, select Admin Menu, Match Type.

Description of Page

Enter an easily recognizable Match Type and Description.

Define the Pay Dist Override Algorithm used to distribute payments that reference this match type.  If you haven’t done so already, you must set up this algorithm in the system.  To do this:

·         Create a new algorithm (refer to Setting Up Algorithms).

·         On this algorithm, reference an Algorithm Type that overrides the normal payment distribution algorithm.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_MATCH_TYPE.

Setting Up Match Event Cancellation Reasons

When a match event is canceled, a cancel reason must be supplied. 

To set up match event cancellation reasons, select Admin Menu, Match Event Cancel Reason.

Description of Page

Enter an easily recognizable Match Event Cancel Reason and Description.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_MEVT_CAN_RSN.

The topics in this section provide background information about fund accounting. 

Contents

Fund Accounting Overview

Accounting Method Is Defined On The Installation Options

Fund Controls Fund-Balancing Entries

Building Fund-Balancing GL Details

Setting Up The System To Enable Fund Accounting

Fund Accounting Overview

Regulations or other restrictions may require some organizations to account for the finances of each of its departments as a separate entity.

To track the finances of departments separately, the organization sets up a fund for each department.  A fund is an accounting entity with its own self-balancing set of accounts.  Each fund has its own "sub general ledger" with its own chart of accounts, and within each fund, its debits equal its credits at all times.  This allows the organization to report on the financial state of each fund independently.

In addition to having a fund for each department, there is also a general fund, which is used to handle inter-fund transfers as well as shared accounts.

A single obligation may have debt related to different funds.  For example, tax liability and penalty and interest may go to the same "revenue" fund, and a collection fee may go to a "collection" fund.

In fund accounting, debits and credits must balance for the whole general ledger and debits and credits within each fund must balance.

Contents

Fund Accounting Example

An Example Of A Bill Segment That References Multiple Funds

Fund Accounting Example

Consider an obligation that owes tax liability and then incurs a collection fee.  Note that penalty and interest would also accrue, but are not shown in this example.

The accounts receivable (A/R) distribution code to use for financial transactions that affect A/R is linked to the obligation type.  The assumption is that the fund for this distribution code is the same "revenue" fund.

For this example, three funds exist:

·         Tax (fund 01)

·         Collections (fund 39)

·         General (fund 99)

When a tax is levied, the following adjustments are made to the tax fund account producing the following GL entries.

For the tax fund, the GL details of the bill include a debit to the accounts receivable (A/R) account and credits to the revenue account.  The taxing authority is owed the entire portion of the adjustment by the taxpayer.  The tax fund is balanced.

The following diagram illustrates the initial GL accounting that occurs when a collection fee is levied.

Because A/R is added to the tax fund and the revenue is added to the collections fund, the funds are out of balance. 

As the tax authority takes on the responsibility to collect the fee, additional entries are created to balance the funds.

The following diagram illustrates the initial GL accounting that would occur when the payment arrives.

The tax authority's general cash account is debited, and the tax fund's A/R account is credited.

If the accounting were left in this state, the fund accounting principal – that each fund represents an independent entity with a self-balancing chart of accounts – would be violated.  This violation is caused due to the fact that cash is recorded on the general fund, not the tax fund, causing the general fund to have an excess debit and the tax fund to have an excess credit. 

From an organizational viewpoint, to make the tax fund whole, the tax fund needs to note what portion of the cash it owns, and correspondingly, the tax authority needs to note what portion of the cash is owed to each fund.  The following diagram illustrates this point.

To maintain a balance of debits and credits within each fund, the tax and collection funds have an "equity in pooled cash" (EPC) account and the general fund has a liability account for each fund.  In addition to debiting the general fund’s cash account and crediting the tax fund's A/R accounts, the tax and collection funds’ EPC accounts are debited and the general funds liability accounts are credited.

And so, with the additional GL entries, all funds have matching debits and credits.

An Example Of A Bill Segment That References Multiple Funds

Consider a tax liability that is distributed to multiple jurisdictions where 60% is allocated to the county where the store is located and 40% is allocated to the state.

Note that in this example only two jurisdictions are used; however, a real scenario may break this down further into town, school districts, and so on.

For this example, three funds exist:

·         State (fund 01)

·         County (fund 24)

·         General (fund 99)

When a $100.00 tax is levied, the following diagram illustrates the initial GL entries for this scenario.

The state fund’s A/R is debited, and the state and county funds' revenue accounts are credited.

If left at this, the funds would be out of balance; the state fund would have an overall excess debit and the county fund would have an excess credit.

To balance the funds, the state fund accepts the responsibility for collecting the county taxes from the taxpayer but immediately remunerates the charges to the county fund.

This transfer is done using the general fund.  The state fund’s EPC account is credited and the liability to state is debited with the amount of the county sales tax revenue.  Also, the county fund’s EPC account is debited and the general fund’s liability to the county account is credited by the county sales tax revenue.  In effect, the state fund owes the county charges to the general fund, and the general fund owes the county charges to the county fund.

The following diagram illustrates the initial GL accounting that would occur when the payment arrives.

When the payment arrives, the cash is debited to the general fund’s cash account, and the state fund’s A/R is relieved.  Again, the funds would be unbalanced if left in this condition; the state fund would have an excess of credits and the general fund would have an excess of debits. 

To maintain each fund’s balance of debits and credits, the general fund’s liability to the state fund is credited by the amount of the fund’s share of the cash, and the state fund’s EPC is debited.  Note that the payment has no effect on county fund’s EPC and the general fund’s liability to the county fund.  The county fund "received" its money from the state department when the adjustment was created.

And so, all funds have matching debits and credits.

Accounting Method Is Defined On The Installation Options

You must turn on a switch on the Installation Record to enable fund accounting.

Fund Controls Fund-Balancing Entries

There are two levels of debit and credit balancing in fund accounting.  There is the balancing required by double entry accounting: the total debits in the entire GL must equal the total credits.  This is required regardless of whether fund or corporate accounting is used.  The distribution codes for these entries come from varying sources, depending on the type of financial event.

The second level of balancing is specific to fund accounting.  Within each fund—not just across the GL—the total debits must equal the total credits.  The original distribution code from the financial event has a fund specified.  For example, a bill would cause a debit to a fund’s A/R distribution code, and included in that A/R distribution code is the fund.  It is the definition of the fund that specifies whether fund-balancing entries are required and provides the distribution codes for these entries.

For a departmental fund, the fund-balancing debit and credit would be specified.  When a debit is applied to a departmental fund’s GL account, an additional account (typically the general fund’s liability to the departmental fund) is debited and an account (typically the departmental fund’s EPC) is credited.  When a credit is applied to a departmental fund’s account, an additional account (typically the general fund’s liability to the departmental fund) is credited and an account (typically the department’s EPC) is debited.

For the general fund, no fund-balancing debits and credits are specified.

Building Fund-Balancing GL Details

Building the GL details for a financial event is a two-step process.

·         First, the system generates the regular GL details for a financial transaction (FT).   This is done regardless of whether corporate or fund accounting is used. 

·         Second, with fund accounting activated, the system analyzes the distribution code on each GL detail associated with the FT.  If a fund is specified on a distribution code, the system checks the definition of the fund.  If fund-balancing entries are specified on the fund, two additional GL entries are added to the FT:

·         An offsetting entry to the Equity in Pooled Cash account is created for the departmental fund (e.g., if the FT is debiting a given fund, an offsetting credit is created in the funds EPC account).

·         Another entry to the departments liability account is created for the general fund.

The result is a consolidated set of GL entries for the FT, incorporating the regular entries as well as the fund-balancing entries.

Setting Up The System To Enable Fund Accounting

The following section provides an overview of how to enable fund accounting.

Contents

Turn On Fund Accounting

Defining Funds

Distribution Codes Must Include Fund ID

Update Your Funds With Their Respective Equity and Liability Distribution Codes

Turn On Fund Accounting

On the Installation Record, indicate that fund accounting is Practiced.  This is the default setting.

Defining Funds

A fund must be setup for each specific fund in your organization.  Don’t forget to also set up a fund for the general fund.  Navigate using Admin Menu, Fund.

Description of Page

Enter a Fund and a Description to identify the fund.

If this fund is used to balance other funds or to hold cash, indicate a Fund Type of General, otherwise indicate that it is Specific.

If the fund type is Specific, specify the Equity Distribution Code and Liability Distribution Code.  These codes are used to balance financial transactions that span funds.  The equity distribution code should belong to the same Fund as the one you are defining.  The liabilitydistribution code should belong to the general fund.

Distribution Codes Must Include Fund ID

All of your distribution codes must include their respective fund ID.

Update Your Funds With Their Respective Equity and Liability Distribution Codes

After distribution codes have been setup, you must update your funds to indicate the equity and liability accounts used to balance inter-fund financial transactions.

This section discusses issues related to defining bill cycles and bill periods in the system.

An account may reference a bill cycle.  An account’s bill cycle may be used to control cyclical billing.

In this section, we describe how to design and set up this cycle.  In addition, we discuss how to set up bill period schedules.  These are used to define the bill segment end date for special types of obligations.

Contents

The Big Picture Of Bill Cycles and Bill Periods

Setting Up Bill Cycles

Setting Up Bill Periods

The Big Picture Of Bill Cycles and Bill Periods

The topics in this section provide background information about a variety of bill cycle and bill period issues.

Bill Cycles

The topics in this section provide background information about a variety of bill cycle features.

Contents

The Cyclical Billing Process & Window Billing

Designing Your Bill Cycles

How Does An Account Get Its Bill Cycle?

Protecting An Account's Bill Cycle

The Cyclical Billing Process & Window Billing

The cyclical bill creation process creates most bills.  This process works as follows:

·         An account can reference a bill cycle.  The bill cycle’s schedule controls WHEN a cyclical billing process attempts to create bills for the account.

·         Every bill cycle has a bill cycle schedule that defines the dates when a cycle’s accounts are to be billed.  Rather than attempt to create bills on one evening, your implementation may use a concept of "window billing" where the system attempts to produce bills for accounts over a few nights. This concept is useful if your billing is based on information being sent from an external source.  It allows you to start billing accounts on the earliest possible day and then bill the stragglers over successive evenings.  This results in much better cash flow.

·         When the bill cycle creation process runs, it looks for bill cycles with open bill windows.  It then attempts to create bills for the accounts in each such cycle.  If a bill is successfully created, it is completed immediately and ready to send to the taxpayer.  If a bill cannot be created, the system will create a bill in the “error” state and initiate a To Do entry with a message that can be analyzed by your billing staff.  When the bill cycle creation process next runs, it deletes all “error” bills and attempts to recreate them.  It continues this throughout the bill window.  If bills are in error at the end of the window, they will remain in this state until a user fixes them.  If the bills are still in error when the cycle’s next window opens, a billing error will be generated.

Designing Your Bill Cycles

The number of bill cycles is determined by how much you want to stagger the billing of your taxpayers.  You may do this to smooth out calls you may receive for your call center with questions about tax bills.

How Does An Account Get Its Bill Cycle?

Most accounts are created behind-the-scenes through taxpayer registration processing.  An account created like this doesn’t have a bill cycle.  Rather, it sits in limbo awaiting the activation of its first obligation that should be billed using cyclical billing.  When an obligation is activated, an activation algorithm should assign the account to an appropriate cycle based on business rules.

Note, an account may be configured to protect its bill cycle from being changed by an algorithm. Refer to Protecting An Account’s Bill Cycle for more information.

Protecting An Account's Bill Cycle

An account has a single bill cycle, but may have multiple obligations that are billed via cyclical billing process.  In this case, when a cyclical obligation is activated, you may not want an algorithm to change the account's bill cycle.  To prevent this you need to turn on the account's protect bill cycle flag.

When the last obligation for an account is stopped, the protect bill cycle flag is reset.  This is to ensure that if the taxpayer starts a new obligation in the future the bill cycle can be set based on the new obligation's activation algorithm rules.

Setting Up Bill Cycles

An account may reference a bill cycle.  The bill cycle defines the schedule for cyclical billing of its accounts.  To define a bill cycle and its bill cycle schedule, open Admin Menu, Bill Cycle.

Description of Page

Enter a unique Bill Cycle and Description for every bill cycle.

Use the Bill Cycle Schedule collection to define when bills are produced for the accounts in a given bill cycle.  The following fields are required for each instance:

Window Start Date                              Specify the date on which the system should start trying to create bills for accounts in the cycle.

Window End Date                                Specify the last day on which the system will create bills for accounts in the cycle. 

Accounting Date                                  Specify the financial date associated with the bills’ financial transaction.  The accounting date defines the financial period(s) to which the bills will be booked in your general ledger.

Freeze and Complete                          Turn on this switch if the system should freeze and complete any bill that is created without errors.  If this switch is turned off, all bills created by a cyclical billing process should be left in the unfinished state. You would only turn this switch off if you want to verify an entire bill run prior to freezing it (e.g., if you are introducing a new version of a rate).  If you turn this off, you will need to return to this page after verifying a bill run and turn it back on for the taxpayers to receive bills.  When the cyclical billing process next runs, it should delete all unfrozen bills and recreate them as per the instructions on the bill cycle schedule.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_BILL_CYC.

Setting Up Bill Periods

Some obligation types reference a bill period.  The bill period defines when the obligation’s bill segments are produced and the respective end date of each bill segment. 

To define a bill period and the bill period schedule, open Admin Menu, Bill Period.

Description of Page

Enter a unique Bill Period and a Description for every bill period.

Use the Bill Period Schedules collection when the system should create bill segments for obligations that use a given bill period.  It also defines the end date of each respective bill segment. The following fields are required:

Bill Date                                               Specify the earliest date on which the system is allowed to create a bill segment for obligations using this bill period.

Bill Seg End Date                                Specify the end date of the bill segment.  For future bills, this will be after the bill date.  For retro bills, this will be before the bill date.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_BILL_PERIOD.

This information is used by the bill segment creation process to determine the end date of obligations that use a bill period.

Various topics about financial transactions are discussed in this section.

The Source Of GL Accounts On Financial Transactions

The following is a summary of the source of GL accounts on financial transactions:

·         If a bill segment has a financial effect, the distribution code to debit comes from the distribution code on the obligation type; the distribution code to credit comes from the rate component(s) used to calculate the bill segment.

·         Payment segments always have a financial effect; the distribution code to debit comes from the bank account on the tender source of the tender control of the tender, the distribution code to credit comes from the obligation type.

·         For adjustments that have a financial effect, refer to ??? for more information.

The following table lists some examples of financial events, their standard accounting, and the source of distribution codes used to derive the GL accounts sent to your general ledger.

Financial event	GL Accounting	Source Of Distribution Code
Create a normal bill segment. Bill Segment FT Algorithm is Payoff Amt = Bill Amt / Current Amt = Amt Due	Debit: A/R	Obligation Type
	Credit: Revenue	Rate Component
Create a bill for company usage. Bill Segment FT Algorithm is Payoff Amt = 0 / Current Amt = 0	Debit: Company Usage Expense	Obligation Type
	Credit: Revenue	Rate Component
Create a bill for charity. Bill Segment FT Algorithm is Payoff Amt=0 / Current Amt = Bill Amt	N/A – charity bills have no effect in the GL	N/A
	N/A	N/A
Create a payment segment for a normal obligation	Debit: Cash	Bank Account on the Tender Source of the Tender Control for the Payment Segment’s Tender.
	Credit: A/R	Obligation Type
Create a payment segment for a charitable contribution obligation	Debit: Cash	Bank Account on the Tender Source of the Tender Control for the Payment Segment’s Tender.
	Credit: Charity Payable	Obligation Type
Create a payment segment for auto-pay at bill completion time	Debit: Cash	Bank Account on the Tender Source on the Auto-pay Route Type of the Auto-pay Source.
	Credit: A/R	Obligation Type
Canceling a payment	Debit: A/R	Obligation Type
	Credit: Cash	Bank Account specified by the user on the cancel tender page.  Note that this defaults to the original tender's bank account.
Create an adjustment to levy a charge	Debit: A/R	Obligation Type
	Credit: Revenue	Adjustment Type
Create an adjustment with disbursement details	Debit: A/R	Obligation Type
	Credit: Revenue (multiple)	Adjustment calculation line details