Revenue Accounting
This chapter describes revenue accounting. It covers the following topics:
The revenue module provides detailed revenue accounting records for both financial and cost accounting. It also provides detailed receivable management and comprehensive collection support, and allows revenue accounting on a cash or accrual basis.
Receivables are entered and maintained using the documents discussed in detail below.
|
Records the received revenue when payment is remitted by the debtor. The billed receivable is liquidated and the cash collection recorded. When revenue is received before it is earned, it is recorded on the cash receipt document as deferred revenue. |
|
|
If a cash receipt document has been processed for a customer's check, and the check is returned for insufficient funds, a Non-Sufficient Funds (NF) document is processed. This document is used only when the check references a Receivable document. The Non-Sufficient Funds (NF) document reverses out the payment to the referenced receivables, and optionally applies a non-sufficient funds check charge. |
|
|
Enters revenue that is earned and billable into the system. Earned revenue is recognized, a billed receivable recorded, and an invoice is sent to the debtor. |
|
|
Credits a customer's account. For example, a Receivable Credit Memo (RM) is entered when a customer receives the incorrect quantity of goods or if the customer overpays. |
|
|
Reclassifies deferred revenue as earned. Journal voucher documents are discussed in detail in See Journal Vouchers. |
|
|
The Journal Voucher Correction (JVC) document is used to correct previously posted expenditure or revenue transactions. The Journal Voucher Correction (JVC) document is a generalized document that records accounting corrections that cannot or should not be made on other financial system documents. |
|
|
The Journal Voucher Transfer (JVT) document is used to process all cash transfers, both on budget and off budget |
|
|
Once a customer's receivable becomes significantly past due, and collections are doubtful, a Write-Off (WO) document can be processed to write off the receivable. |
|
|
The Customer document is used to establish and maintain customer information. This document updates the customer tables (CUST, CUS2, CEFT). |
The revenue accounting steps are summarized in the example below.
The revenue accounting consists of the following tables and corresponding windows:
The Advanced Receivable Revenue Ledger stores Receivable (RE), Receivable Credit Memo (RM), Cash Receipt (CR, C1), Write-Off (WO) and Non-Sufficient Funds Checks (NF) transaction details. It is updated nightly in the run split process, and old records are purged by the Monthly Ledger Purge program.
The purpose of the ledger is to facilitate inception-to-date tracking and reporting of billed receivables. Modifications to previously entered lines are stored in the ledger as separate entries, producing an audit trail of all receivable related activity that has not been cleared from the system.
The Revenue Ledger also contains items closed during the current and preceding accounting period. (Entries normally remain in the ledger for one accounting period beyond the period when the receivable was closed.) The ledger generally corresponds to the contents of the open receivable tables (unless ledger clearing is performed on a separate schedule from open item table clearing).
The revenue module provides additional detailed accounts receivable information which is not available online through a series of reports. Detail document, aged receivable, collection support, and system assurance reporting is provided. Each of these reports is normally generated during nightly batch processing.
The revenue module includes the reports listed below.
Figure 54 shows an overview flowchart of revenue accounting. The various processes involved, which are identified with circled numbers in the figure, are listed below:
- The documents are: receivables, cash receipts, credit memos, write-offs, and non-sufficient funds checks. These documents are processed by the system online or offline. The information submitted to the system for the documents is edited and validated by MARS. If the documents are error free, they are accepted by the system, and the appropriate table and ledger updates are made.
- Daily Ledger Update (SPLT) executes the RUNSPLIT program which writes all records to the offline ledgers (the Revenue Ledger (REVLED) and General Ledger (GENLED) exactly as they exist on the ledger holding tables. It writes one record for each revenue related record it reads. REVLED is created for receivables reporting, and is used as an audit trail for receivables.
- The following jobs are executed:
- Accrue Interest Charges and Late Fees (ARFC) accrues interest charges and late fees for past due receivables.
- Process Recurring Receivables (ARRE) processes recurring receivables.
- Process Write-offs (ARWO) writes off uncollectible receivables.
- Deposit Ticket Update (KDETU)
- Invoice Print (AR11) prints invoices.
- Collection Letter Print (AR12) prints collection letters.
- Customer Statement Print (AR13) prints customer statements.
- Replacement Statement Print (AR14) prints replacement statements.
- Renewal Notice Print (AR20) prints renewal notices.
- Advanced Receivables Monthly Table Purge (ARMT), Advanced Receivables Monthly Statement Table Purge (ARSP), and Advanced Receivables Monthly Ledger Purge (ARML) are the monthly clearing programs for the MARS.
- New Year Initialization (ARNY) rolls year end financial data for a customer to the corresponding prior year fields, and creates a next-fiscal-year record for various receivables options and control tables.
- Figure 54
Accounting Basis of MARS Revenue Accounting
MARS performs various functions that aid in properly accounting for revenue. Some of these functions include:
- Users entering only the revenue line of a revenue document on the document window. The implied offset, or balance sheet, entry is automatically generated. The actual offset lines generated are listed in subsequent sections of this chapter.
- The system automatically decreases billed receivables when cash receipts are recorded against them. That is, in addition to the entry generated to offset the cash receipt, another entry is generated to reverse the outstanding billed receivable that was created by the receivable.
If a cash receipt closes a receivable for greater than or less than the receivable amount (because of short or overpayment tolerances), the recognized amount is increased or decreased by the amount of the difference. The increase or decrease is recorded in the accounting fiscal year when the cash receipt was recorded and the budget fiscal year when the receivable was recorded (unless the budget fiscal year is closed, in which case, it is recorded in the current fiscal year).
- A closed receivable may be reopened in the accounting period when it was closed or in the accounting period immediately following. Reopening is accomplished with a modifying document that is entered as if the receivable were still open.
- Recognized revenues are adjusted by only the net change when:
- Final cash receipts differ from previously recognized revenues.
- A modifying receivable or cash receipt document changes the amount of the original document.
The following terms are used throughout this chapter:
MARS requires the establishment of a number of system controls and options. This includes the system option to specify the installation of Advanced Receivables Subsystem and revenue accounting system-wide and agency/revenue source options. Standardized billing rates, billing profiles and collection notice cycles must also be established. These items are discussed in See Key Concepts.
Revenue options are defined system-wide for each fiscal year and can be further refined at the agency or revenue source level. System-wide options are used to define revenue sources or balance accounts to be used for NSF (non-sufficient funds) check charges and overpayments, finance charge accrual, and other MARS processes. Options at the agency or revenue source level are used to override NSF check charge, tolerance level, and the finance charge options defined system-wide.
To process receivables functions, MARS needs to know that the Advanced Receivables Subsystem is installed. Select the Advanced Receivables option on System Control Options (SOP2) to indicate that the subsystem is installed. For more information, see the User's Reference .
Budgetary control on revenue transactions is accomplished by using the Revenue Budget Presence Control Option. This option requires that lines exist in the revenue budget that must match the account code distribution of revenue transactions.
At a minimum, Fund, Agency and Revenue Source codes are entered on revenue accounting transactions; Fund and Balance Sheet Account codes are entered on balance sheet transactions; and Fund, Agency, and Object codes are entered to process vendor refunds. However, the options and controls used in MARS may tighten coding requirements.
To preserve consistency between budgetary and accounting data maintained at different levels of detail, MARS automatically sums to the level of the budget before applying budgetary controls and updating balances in the budget master files. Therefore, users only need to enter each transaction properly from an accounting standpoint.
The following options affect the way that revenue transactions are entered. A brief description of each is presented below.
Revenue Options (ROPT) establishes options and controls used throughout MARS. Revenue Options (ROPT) includes the following options and controls. Each one is explained briefly in the sections that follow.
- Receivable controls
- Non-sufficient funds check charge controls
- Finance charge options
- Short/overpayment controls
Receivable controls provide a Receivable Due Date Lag and a Receivable Minimum Amount . The Receivable Due Date Lag field is used in calculating a payment due date for each receivable. The Receivable Due Date field is calculated as the transaction date (or statement date if statements are used instead of invoices) plus the lag. The Receivable Minimum Amount is used to specify the minimum receivable amount which is cost efficient to process.
Non-Sufficient Funds (NSF) Check Charge Controls
The NSF Check Charge and the NSF Charge Revenue Source fields are used to define a system-wide charge for non-sufficient funds processing and the revenue source for accounting of non-sufficient funds charges.
The Finance Accumulation Type field specifies whether interest charges, late fees, both or neither are applied to past due receivables. Interest can be compound or simple. One-time Late Charge Amount and interest rates used in finance charge accruals are also designated. Unique revenue sources for the finance charges are specified on Revenue Options (ROPT).
Short and overpayment tolerances provide a range in which customer payment closes a receivable. If a cash receipt is processed and the payment is within short and overpayment percentages and amounts, the receivable is closed. Short payments outside of the tolerance are treated as partial payments, while overpayments outside of tolerance are maintained as credit balances on the receivable using the overpayment liability account. Short and overpayments are discussed in detail in See Cash Receipt Document - Issues and Concepts.
Revenue Options by Agency/Revenue Source (ROAR)
Finance charge revenue options which are defined at the system-wide level by Revenue Options (ROPT) and can be overridden on Revenue Options by Agency/Revenue Source (ROAR). Agency specific, or revenue source within agency options can be specified on Revenue Options by Agency/Revenue Source (ROAR). If an option from Revenue Options (ROPT) is not overridden, the Revenue Options (ROPT) value is used. For example, if both interest and late fees are required for an agency, and the interest rate is not entered on Revenue Options by Agency/Revenue Source (ROAR), the Revenue Options (ROPT) interest rate is used.
Open Receivable Options (OREO)
Open Receivable Options (OREO) is used to provide receivable specific processing options and controls. For example, if a customer disputes a receivable, this can be identified on Open Receivable Options (OREO). If a receivable is disputed, finance charge accrual as well as the generation of dunning invoices and collection letters is suppressed. Finance charge accrual and billing can also be individually suppressed.
Receivables can also be assigned to a collections agency on Open Receivable Options (OREO) by setting the Collection Status to Collections and entering a valid Collection Agreement Number from Master Service Agreement (MSAT). A receivable can be flagged for legal action by setting the Collection Status to Legal Action . When a receivable is flagged for collections or legal action, the corresponding fields on Customer Credit History Inquiry (CUSC) are updated.
Receivables which are on a payment schedule or are being written off are also flagged on Open Receivable Options (OREO).
MARS has many different chains of accounting transactions used for recording revenue events (see Figure 55). Revenue is recognized at the time of receipt by a receivable document or, if no receivable is referenced, the cash receipt document.
Alternative Revenue Accounting Processing Chains
When a receivable document is processed and accepted, a line is created on Open Receivable Line Inquiry (OREL) for every line listed on the document. One entry is also created on Open Receivable Header Inquiry (OREH) storing data from the header portion of the receivable document. When the record is added to Open Receivable Header Inquiry (OREH), records are also added to Open Receivables by Customer Inquiry (OREC) and Open Receivables by Due Date Inquiry (ORED).
Receivable amounts on Open Receivable Line Inquiry (OREL) are changed when modifications are submitted on Receivable (RE) or Receivable Credit Memo (RM) documents, or the receivable is written off. The Closed Amount fields are changed when cash receipts or non-sufficient funds checks are processed against them.
A line on Open Receivable Line Inquiry (OREL) is closed when:
- The sum of all cash receipts referencing a receivable document line equals the line amount.
- A cash receipt forces a close on a receivable line when the payment is within the short or overpayment tolerances.
- A Receivable Credit Memo (RM) amount cancels the original receivable or, if a cash receipt already referenced it, reduces the amount to the collected amount.
- The receivable is written off using the Write Off (WO) transaction.
- The receivable is cancelled.
When all the lines in a Receivable document are closed on Open Receivable Line Inquiry (OREL), the appropriate record on Open Receivable Header Inquiry (OREH) is closed. All records are deleted from Open Receivable Header Inquiry (OREH) and Open Receivable Line Inquiry (OREL) a user-specified number of accounting periods after the period in which the header record is closed.
If a cash receipt references a receivable with a payment within the short or overpayment tolerance, then the receivable closed amount is the receivable line amount, regardless of the amount of the cash receipt causing the close. For example, if a receivable line exists for $100, a cash receipt closes the receivable for $99, and the short payment tolerance allows a $1 difference, the receivable closed amount on Open Receivable Header Inquiry (OREH) is $100. However, recognized revenue is decreased by $1, cash is increased by $99 and the receivable is reduced by $100.
A receivable line cannot be closed by an amount greater than the line amount plus the allowable overpayment. If cash is applied to a line for more than the line amount plus an overpayment, a credit balance remains outstanding for the receivable.
A receivable, credit memo, cash receipt, non-sufficient funds check and write-offs that apply to the same event are linked together in MARS using the document referencing facility (Note: The Prior Document Reference field on System Control Options (2 of 2) (SOP2) must have a value of Yes for the Advanced Receivables Subsystem). For example, when a cash receipt is entered against a previously entered receivable, the referenced receivable number must be coded on the cash receipt line. This referencing facility accomplishes two objectives:
- Ensures that funds are recognized only once for a particular item or service.
- Ensures that financial records are not cluttered with dangling receivables.
Since revenue can be billed or received in installments, a single receivable line can be referenced more than once. For example, it may take a series of cash receipts to clear one item on a receivable.
Receivables can also be referenced indirectly on the cash receipt by using the customer account referencing facility. This allows the entry of a customer account identifier on the cash receipt which applies cash to receivables by customer account in due date order.
MARS provides the following document cross-reference windows to monitor document referencing:
- Document Cross Reference (DXRF)
- Vendor (Customer) Cross Reference (VXRF)
- Document History (DHIS) Billing Rates
Standardized billing rates can be established in the MARS to facilitate the billing of common goods sold to customers. These rates are defined on Billing Rate (BRTE). For each fiscal year a set of Rate codes can be defined by agency to specify a billing rate per unit of measure. These Rate codes are then used by the receivable transaction to calculate receivable amounts.
Billing profiles identify a set of controls used in processing invoices, statements, collection letters and renewal notices for customers, and are defined on Billing Profile (BPRO). The key parameters associated with a Billing Code are a remittance Address and the Invoice/Statement indicator, which specifies whether the Billing Code is to be used for statements, invoices, or both.
If invoices are specified on the Invoice/Statement indicator, all receivables processed with the Billing Code generate an invoice. If statements are specified, the receivables processed with the Billing Code are listed on a monthly statement. If both invoices and statements are specified, the customers are billed using invoices and receive a monthly account summary statement.
The remittance name and address specify where customers must send their payments. The Pay To field indicates to whom the customer's check should be written.
The Invoice/Statement indicator specifies whether invoices or statements are generated for the Billing Code . If statements are specified, a Statement cutoff day must be entered. Each month on this cutoff day, MARS generates statements for each customer with the Billing Code .
Other Billing Profile Information
The Billing Profile (BPRO) Receivable Due Date Lag field can be used to override the system-wide due date lag for receivable and statement due dates. The Instruction Code on Billing Profile (BPRO) is used as a default for all invoices or statements generated with the Billing Code.
The billing collection cycle is used to identify a collection notice cycle other than the system default (for more information, see See Collection Notice Cycles). If a billing cycle is specified, the alternate cycle is used instead of the system default when dunning or collection letters are processed for the receivables with this Billing Code.
Collection notice cycles establish a schedule by which customers are notified of past due accounts. The cycle specifies the number of days past due that a dunning message or collection letter is sent to the customer.
Collection Control (CCTL) and Billing Profile Collection Cycle (BPCC) are used to schedule which notification is sent to a customer. Both are used to determine which dunning messages and collection letters are generated at specified ages of the delinquent receivable. System-wide defaults are established on Collection Control (CCTL); billing profile defaults are established on Billing Profile Collection Cycle (BPCC) and override Collection Control (CCTL) defaults.
The dunning message text and associated codes are defined on Dunning Message (DUNN). Collection letter text and associated codes are established on Collection Letter (COLT).
The collection notice cycle specifies the type of notice a customer receives regarding a past due account. Collection Control (CCTL) and Billing Profile Collection Cycle (BPCC) are used to establish a schedule for dunning messages and collection letters. For example, dunning messages can be scheduled to be printed 1, 31, and 61 days past due and one collection letter can be generated at 91 days past due.
Alternate Collection Notice Control
Billing Profile Collection Cycle (BPCC) is used to override the system defaults on Collection Control (CCTL). Billing Profile Collection Cycle (BPCC) entries schedule dunning messages for invoices 5 and 25 days past due. At 45 days past due, a collection letter is generated.
A collection cycle can be defined on Billing Profile Collection Cycle (BPCC) for each billing profile defined on Billing Profile (BPRO). A single Billing Collection Code can be used for many different billing profiles.
All customer information windows are updated by the MARS. The Customer (CU) document updates Customer Information (CUST, CUS2) and Customer Electronic Funds Transfer (CEFT, CEF2).
The customer tables are used to identify individuals, organizations or other entities providing revenue. Customer codes are required on all receivables transactions except for the cash receipt. If a Customer code is entered on a document, various financial and credit history information is automatically maintained by the system.
The customer file contains descriptive data and status information about customers. Customer information is presented on five screens which are listed below. To establish a customer within the system, the customer's information must be entered on a Customer (CU) document. Default entries on the other customer tables are automatically created. All four tables have the same key, but each displays different information about the customer. The tables listed below contain customer information.
The customer tables are keyed by the Customer code, which is a unique identifier of an individual or organization who either purchases goods or services from or provides funding to the government entity. The Customer code has two parts:
The Address Indicator field allows a single customer to have multiple locations.
Customer Information (CUST, CUS2) contains primary customer data which uniquely identifies a customer, and other key information needed to process the customer within the system. Information provided on Customer Information (CUST) includes the Customer code, as well as customer Name and Address . The accounts payable Contact Name , Bank Name , Vendor code cross-reference, and other customer specific information is also defined on Customer Information (CUST). Customer Electronic Funds Transfer (CEFT) contains customer electronic funds transfer account information.
Miscellaneous or summary customers can be defined on Customer Information (CUST). These are Customer codes which can be used for summary document or reused for one-time customer transactions. Customer personal/organizational information is displayed on Customer Information (CUS2). This information includes an Organization Type , a Tax Exempt indicator, and a License/Permit Number .
Customer Text (CTXT) is used to specify special notes about a customer. These notes can be used to explain the customer's credit or financial history. This free form text window is used only for informational purposes.
Customer Financial History Inquiry (CUSF) contains current and prior year financial information about the customer. All of the information on Customer Financial History Inquiry (CUSF) is automatically updated as receivables documents are processed. Customer Financial History Inquiry (CUSF) is only updated if a receivable document is entered and then referenced by the other documents. Cash receipts with no receivable or customer account reference do not update Customer Financial History Inquiry (CUSF).
Amounts on Customer Financial History Inquiry (CUSF) are maintained for both the inception-to-date and prior year ending balances. The dates and amounts on Customer Financial History Inquiry (CUSF) are of the last receivable and cash receipt processed against the customer.
Customer Credit History Inquiry (CUSC) is a system-maintained table which contains counters and last occurrence dates of events which affect the credit rating of a customer. These events are:
- Dunning Messages (updated from OREO)
- Non-sufficient funds check processing (updated from Non-Sufficient Funds Check Transactions)
- Disputes (updated from OREO)
- Intercept Attempts (updated from Open Receivable Options (OREO)
- Collections processing (updated from Open Receivable Options (OREO)
- Legal actions (updated from Open Receivable Options (OREO)
- Receivable write-off (updated from Write-Off Transactions)
- Collection (referrals to collection agencies)
The Text Exists on Customer Text option on this window indicates that text pertaining to the customer's payment history is stored on Customer Text (CTXT).
Information about customer documents is available in the system. These screens provide both document detail information and cross-reference information between documents.
Customer Document Inquiry (CDOC) provides detail information, in chronological order, of all transactions processed for a particular Customer code. This table is updated online as original and modifying transactions are processed.
Other tables, updated in batch processing, provide document information by customer. They are Document Cross Reference (DXRF), Vendor (Customer) Cross Reference (VXRF), and Document History (DHIS).
Customer information can be accessed using two alternate views of Customer Information (CUST): Customer Name Inquiry (CUSN) and Alternate Customer Code Inquiry (CUSA).
Customer Name Inquiry (CUSN) is keyed by customer Name ; Alternate Customer Code Inquiry (CUSA) is keyed by alternate Customer code. The alternate views are automatically updated whenever a Name or alternate Customer code is updated on Customer Information (CUST).
Customers having an outstanding account balance of zero, and not having had documents processed for a user-defined amount of time, are automatically marked for deletion. A last transaction date is entered on an Application Dates (LDAT) parameter. Customers without having a transaction processed since the Application Dates (LDAT) date, and having a zero balance, are processed for deletion.
The customer deletion batch process performs two main functions:
- Those customers who have already been marked for deletion manually or in a previous pass of the purge process are deleted from the customer tables if they still meet the deletion criteria.
- Customers meeting the deletion criteria and name currently active or inactive are marked for deletion and listed on a report. Customers can also be manually marked for deletion.
If a customer has been inadvertently marked for deletion, the Customer Status must be manually changed to active or inactive, to prevent deletion.
Both of these windows display customer status, which can either be active or inactive. An inactive customer cannot have original receivable transactions or modifying increases processed against them. Cash Receipts (CR, C1), Non-Sufficient Funds Checks (NF), Credit Memos (RM) and Write-Offs (WO) can be processed against inactive customers.
Receivables are entered and maintained using one of the following documents:
The information entered using these documents is stored in the open items tables and ledgers. Accounting entries are stored in the General Ledger and Balance Sheet Account Balance (BACC).
Cash Receipt Document - Issues and Concepts
Cash Receipts record all monies collected, including collections against outstanding accounts receivable and cash basis revenue (straight cash revenue). Cash receipt transactions record cash received against an outstanding receivable, a specific receivable line, or a customer account (by referencing a statement). The cash receipt also records prepayments and vendor refunds. Cash receipts may also be used in summary form, to record receipts that were processed in detail through a separate billing and collection system. Cash receipts apply a credit balance due to an overpayment from one receivable to another. Cash receipts can post cash to objects of expenditure.
Short payment and overpayment tolerances control the acceptance of payments against receivables for amounts greater than or less than the receivable amount. If a payment is received within the short or overpayment tolerances, the referenced receivable document is automatically closed.
Summary cash receipts can be entered for multiple small cash receipts. The summary cash receipt recognizes the revenue and provides summary information about the receipt. Detailed receipt information can then be maintained outside the system.
The cash receipt document is divided into two parts: header and line. The header information includes the transaction date, bank account being deposited to and the document total amount. Line information includes the referenced receivable or statement, accounting distribution, and line amount. System master tables are referenced to verify data entered on both the header and lines.
Samples of the cash receipt, which are set up to record cash received and reference a receivable to be deposited into bank account 67 are shown in Figure 56.
Cash Receipt (CR) Document (All Attributes View)
Bank and Offset Cash Account Codes
Enter the Bank Account code on the cash receipt header. All of the cash processed on a cash receipt document is recorded against this one bank. This Bank Account code must be valid on Bank Account (BANK).
The cash account used on the system-generated offset entries is specified in one of the following ways:
- If a Cash Account is entered on the cash receipt input window, that cash account is used.
- Otherwise, the Cash Account is inferred from Bank Account (BANK), using the bank account entered on the header.
When an offset Cash Account is entered on the header section of the input window, it applies to all lines on the transaction.
Receipts can be distributed to multiple funds, revenue sources and Account codes by entering multiple cash receipt lines. Revenue transactions require fund, agency and revenue source. Balance sheet transactions require only Fund and Balance Sheet Account codes while vendor refunds require Fund, Agency, and Object codes, as well as a Vendor code. If a cash receipt document references a receivable or statement, the accounting distribution is automatically inferred. The accounting distribution is only displayed if a receivable line is referenced.
In addition to Fund , Agency , and Revenue Source , Organization , Activity , Function , Reporting Category , and Sub-Revenue Source , codes may be required on standard cash receipt transactions depending on the control options selected by your installation.
Cash receipt lines are affected by the Revenue Budget Organization and Revenue Budget Activity Options on Fund Agency (FGY2), the Sub-Revenue Source Option, the Reporting Category option on Agency (AGC2), and the Prior Document Reference option on System Control Options (SOP2), as well as the Revenue Budget Control Option on Fund (FUN2). The Recognized Amount field is updated in Revenue Budget Inquiry (REV2). Additionally, if the revenue budget is linked to an appropriation, the Actual Receipts Amount field in the corresponding Appropriation Inquiry (Extended) (EAP2) record is updated.
Fund, Agency, and Revenue Source are required codes on standard cash receipt documents. Balance sheet transactions require only Fund and Balance Sheet Account codes. Vendor refunds require Fund, Agency, and Object codes, as well as a Vendor code. An Appropriation code is also required if you are performing extended budgeting and your Appropriation Control option is set to Full or Presence on Fund (FUN2).
If a receivable was previously entered recognizing the revenue, the receivable document number and line number should be referenced on the cash receipt. Otherwise, the receivable will not be closed in the open invoice tables and ledger.
When a reference occurs, the accounting distribution provided on the cash receipt must match the accounting distribution on the referenced receivable line. More line detail may be introduced on the cash receipt, but none of the codes may be changed. For example, if the Reporting Category field is left blank on the receivable, a Reporting Category code may be added on the cash receipt. However, if the referenced receivable contains a Reporting Category code, a different reporting category cannot be entered on the cash receipt.
If the Prior Document Reference option in System Control Options (SOP2) is set to Yes for your installation, you do not have to code the accounting distribution on the cash receipt when an receivable is referenced. The system infers all codes from the referenced receivable line.
The customer is not required on the cash receipt except when cash is being applied to a customer statement. If it is entered, it must be valid on the Customer Information (CUST). If a receivable is referenced on a cash receipt document, the Customer code and Customer Name are automatically inferred from the receivable document.
The Customer Name is inferred from Customer Information (CUST) if a non-miscellaneous customer is entered on the cash receipt document. The name cannot be changed on the cash receipt if it is inferred.
The Miscellaneous Customer option can be used to enter one-time customers, or summary receipts. These customer numbers can be reused for many different customers or summary cash receipts. These must be defined as miscellaneous customers on Customer Information (CUST). The Customer Name can be manually entered on the cash receipt line for these customers.
The line amount is the amount of payment which is to be applied to the account or receivable. The value entered in the cash receipt document line amount must always be positive. The Default/Increase/Decrease indicator determines if the line increases or decreases collected cash. If the Default/Increase/Decrease indicator field is Inc (Increase), the cash receipt document line increases collected cash. If the Default/Increase/Decrease indicator field is Dec , the cash receipt line is to decrease collected cash.
Accounting Model and Ledger for Cash Receipts
There are four accounting models for processing:
- Cash basis revenue. Cash receipt for over the counter cash specifying a revenue source, but not referencing a receivable.
- Accounts receivable. Cash receipt referencing previously entered receivable either individually or by referencing a statement.
- Liability accounts. Cash advance (unearned revenue) identified by a special Revenue source or Balance Sheet Account.
- Expenditure accounts. Vendor refund with Object code reference.
Over the counter cash can be processed by entering an accounting distribution and the receipt amount on the cash receipt line. The cash receipt may optionally specify a customer. Over the counter cash receipts do not reference receivables, and therefore update the Recognized revenue amount on Revenue Budget Inquiry (REV2).
The following ledger entries are posted for these cash basis revenue transactions:
To apply cash to receivable documents, a receivable must be referenced on the cash receipt line to close it and complete the revenue accounting cycle. The open receivable tables are updated as well as the budget and ledger files. The cash receipt decreases, and eventually closes the receivable on the open receivable tables and ledger.
When a receivable is referenced, the cash receipt header information is entered as it was for a cash account application. The accounting distribution and customer information is inferred from the referenced receivable on the cash receipt line. Multiple receivable can be referenced on a single cash receipt by entering multiple cash receipt lines on the document.
The following ledger entries are posted when a receivable, receivable line or statement is referenced:
To apply cash to a specific receivable line, the Referenced Document ID and Line number must be entered in the referenced document fields on the cash receipt line. When the cash receipt document is processed, the accounting distribution and customer information are inferred from the open receivable tables and displayed on the cash receipt line. The line Amount is the only other field which must be entered on the cash receipt line.
Additional accounting distribution can be introduced on the cash receipt, but none of the codes may be changed. For example, if the sub-revenue source was left blank on the receivable, a sub-revenue source may be added on the cash receipt. However, if the referenced receivable contains a sub-revenue source, a different sub-revenue source cannot be entered on the cash receipt.
Overpayments are not accepted when referencing a specific receivable line. To apply an overpayment, the entire receivable document must be referenced.
To apply a cash receipt to all lines of a receivable, the referenced receivable line number must be blank. Cash is then applied in increasing line number order to the receivable lines. Line 01 is closed first, followed by 02. If any finance or non-sufficient funds check charges have been accrued, cash is applied to them first.
The accounting distribution is inferred from the open receivable tables during processing, but is not displayed on the cash receipt line. The Customer code and name are inferred and displayed. The cash receipt Line Number , Referenced Document ID and line Amount are the only fields which are required on the cash receipt line when applying cash to a receivable.
If the cash receipt references a receivable or receivable line which was flagged for dispute, collections, intercept, or legal action, a warning message informs the user that a receivable in an exception status was referenced.
The amount of the payment received from the customer must be entered on the cash receipt line. If a receivable is referenced, this amount can be greater than, equal to, or less than the referenced receivable amount.
Short payments are accepted and processed in MARS. If the payment amount is within tolerance levels defined on Revenue Options (ROPT), the receivable is closed and the amount of the underpayment is written off. This only occurs for receivables with a Billing Code specifying invoice processing. A short payment within tolerance is defined as being within or equal to the lesser of the tolerance percentage and amount. A warning message is displayed when a short payment within the tolerance is entered.
If a short payment is entered on a cash receipt referencing a receivable, and it is outside of the short payment tolerance, the cash receipt is processed as a partial payment and the receivable remains open. If the payment is within the short payment tolerance, the short payment is accepted and the amount short is written off.
For example, the tolerance percentage is one percent, the tolerance amount is $2.00 and a receivable is entered for $100.00. If a cash receipt is processed for $99.00, the payment will be accepted as full. It is considered within tolerance because the payment is within the lesser of the tolerance percentage (1% of $100 = $1.00) and the tolerance amount ($2.00). The following general ledger entries are posted:
If the referenced receivable's Billing Code specifies statement processing (The Invoice/Statement indicator for the Billing Code is equal to Statement on Billing Profile (BPRO).), short payments within tolerance are not accepted for receivable reference processing. To process a short payment within tolerance, the customer account must be referenced on the cash receipt.
Overpayments on a receivable are also accepted by MARS. If the overpayment is within the overpayment tolerance established on Revenue Options (ROPT), it is accepted as revenue and the receivable is closed. An overpayment within tolerance is defined as an overpayment which is over the receivable balance by an amount less than or equal to the overpayment tolerance amount.
A warning message is displayed when an overpayment within tolerance is processed. Cash and revenues are increased by the amount of the overpayment.
The following general ledger entries are posted when an overpayment is processed.
If the overpayment is outside of the tolerance levels, all of the lines on the receivable are closed out, and a new line is added for the credit balance. This line contains a negative balance and uses the Overpayment Balance Sheet Account from Revenue Options (ROPT). The Receivable Balance on the Open Receivable Header (OREH) table also has a negative balance.
A warning message indicates that a credit line has been added to the receivable for overpayments outside of tolerance. Credit receivables are automatically flagged for reprint on Printed Receivables (PRRE). The Replacement Indicator is set to Y when the receivable becomes a credit.
The reprinted invoice informs the customer of a credit on their account. Invoices are printed for the flagged receivables in the next printing cycle.
The accounting entries for an overpayment outside of tolerance are:
If the referenced receivable's Billing Code specifies statement processing (the Invoice/Statement indicator for the Billing Code is equal to Statement on Billing Profile (BPRO)), overpayments are not accepted for receivable reference processing. To process an overpayment within tolerance, the customer account must be referenced on the cash receipt.
Processing a Credit Balance on Customer Account
To process the check for the receivable amount less the balance, a two line modifying cash receipt must be entered (original entry decreasing lines are not permitted on the cash receipt). One line must reference the normal receivable and the other line must reference the credit receivable. The Default/Increase/Decrease indicator must be set to Inc for the positive receivable line, and the line amount must equal the amount of the check plus the credit. This amount is applied to the normal receivable. The amount of the credit alone should be entered on the other line of the cash receipt. This cash receipt line must have an Default/Increase/Decrease indicator of Dec representing a decrease to cash collected, thereby zeroing out the credit balance.
If a customer receives statements for billing, cash can be applied to the receivables listed on the statement, or any that are open from the past statements. Cash is applied to receivables in chronological order, starting on the receivable with the oldest due date and applying cash until the complete cash receipt has been applied.
To apply cash to a customer statement, only the following information must be entered on the cash receipt line:
The Customer code and Billing Code together make up the account number on the actual statement. Cash is applied to the customer's open receivables with the specified Billing Code based on Open Receivables by Due Date Inquiry (ORED). This window lists receivables and their outstanding balances, for a particular Customer/Billing Code, in receivable due date order.
If a short or overpayment results from the customer statement process, payment is accepted whether it is within tolerance or not. All partially paid statement receivables remain open until full cash payment is received. Overpayment receivables remain open with credit balances until the credit is applied to another receivable or a refund is issued.
Receivables which are disputed by customers are bypassed in the cash application process. If an overpayment results from the statement application and one of the receivables is being disputed, the cash receipt rejects. The dispute must be removed from the receivable for the customer account reference to work. If the receivable remains disputed, cash must be applied to each receivable individually.
Prepayments of taxes, professional license registration renewals, and similar items can be recorded in MARS. Revenue can then be deferred to requisition proper reporting period.
The receipt of the cash advance is recorded as a balance sheet transaction using the Balance Sheet Account code for deferred revenue.
Cr Liability (deferred revenue)
A journal voucher master must be submitted to recognize the revenue in the accounting period in which it is earned. This journal voucher master moves the funds to the correct revenue source.
Vendor refunds are actually cash receipts, but the receipt may be credited back to the account from which the funds were expended. For this, an Object code may be used on a cash receipt line instead of a Revenue Source code. On these transactions, you must also provide a Vendo r code.
When an Object code is used on a cash receipt transaction, the following transaction is recorded in the Current Detail General Ledger:
The amount used is the cash receipt line amount. Also, the expended amount is decreased on the appropriate lines in the following budget master tables.
The cash receipt updates payment detail, open receivable, customer, budget and other tables to recognize the cash received. Following are the key updates in the cash receipt process.
Payment Detail Inquiry (PDET) is updated to reflect that a cash receipt has been processed against a specific Receivable. Payment Detail Inquiry (PDET) lists all of the cash receipts which have been applied to a receivable. The Receivable Number , Transaction Date and Receivable Amount are listed.
When a receivable is processed, entries are made to the open receivable tables. When a receivable is referenced on a cash receipt line or cash is applied to a customer statement, the closed receivable amount is increased and the outstanding balance decreased on Open Receivable Header Inquiry (OREH).
The date of the cash receipt is entered in to the Last Cash Receipt Date field on Open Receivable Header Inquiry (OREH). The receivable totals on Open Receivables by Customer Inquiry (OREC) and Open Receivables by Due Date Inquiry (ORED) also updated to reflect the payment. The Collected and Closed amount fields on Open Receivable Line Inquiry (OREL) are also updated by the cash receipt. If the payment reduces the outstanding balance to zero, the receivable is closed and the Closed Date is updated on Open Receivable Header Inquiry (OREH).
The recognized amount on Revenue Budget Inquiry (REV2) is updated by the cash receipt for the accounting distribution specified on the cash receipt line if the cash receipt does not reference a receivable or statement. If a receivable or statement is referenced on the cash receipt, no changes are made to the recognized amount since the revenue is recognized when the receivable document is entered. Additionally, if the revenue budget is linked to an appropriation, the Actual Receipt Amount on the corresponding Appropriation Inquiry (Extended) (EAP2) record is updated.
The Received to date amount and Total Outstanding Balance on Customer Financial History Inquiry (CUSF) are updated by the amount of the cash receipt. The amount and date of the last cash receipt processed for the customer is maintained on Customer Financial History Inquiry (CUSF).
Cash Receipt (Electronic Deposit) (C1)
The Cash Receipt (Electronic Deposit) (C1) document is used in place of the standard cash receipt document, however, general ledger entries created by a Cash Receipt (Electronic Deposit) (C1) document will have a Transaction code of CR.
The Cash Receipt (Electronic Deposit) (C1) document records all monies collected and deposited directly to the bank electronically. This includes collections against outstanding accounts receivables, and cash basis revenue. You can enter this document as a stand-alone or it can reference receivable documents.
The C1 document will be used for electronic funds transfer (EFT) deposits. Once approved and processed by the treasury, the C1 will update Treasury EFT (TEFT) with the system date, bank account code, the C1 transaction number, document batch ID and amount.
Non-Sufficient Funds Document (NF) - Issues and Concepts
Defining the Non-Sufficient Funds (NF) Document
A Non-Sufficient Funds (NF) is a check that is returned because the customer's account does not have enough money to cover the amount of the check. If a customer pays off a receivable with a non-sufficient funds check, the cash receipt must be backed out and a non-sufficient funds check charge accrued for the customer. The Non-Sufficient Funds (NF) document automatically backs out the cash receipt and adds the non-sufficient funds check charge accrual (if the option is activated). Unlike the cash receipt which can process cash from many customers, each Non-Sufficient Funds (NF) transaction can only process non-sufficient funds checks for one customer.
The Non-Sufficient Funds (NF) document references the receivable to which cash from the non-sufficient funds check was applied. One of the receivables from the Non-Sufficient Funds (NF) lines can be specified on the header as the receivable to which the non-sufficient funds check charge is applied.
Figure 57 shows a sample non-sufficient funds input window, entered to record the non-sufficient funds for a $300.00 check with a non-sufficient funds charge of $20.00.
Non-Sufficient Funds (NF) Document
Entering the Non-Sufficient Funds Check (NF) Document
The main function of the Non-Sufficient Funds Checks (NF) document is to back out the cash receipt lines which were processed for the non-sufficient funds check. The Non-Sufficient Funds Checks (NF) document total must be the amount of the non-sufficient funds check and should equal the sum of all the line amounts (the non-sufficient funds check charge is not included in the document total). Each line on the Non-Sufficient Funds Checks (NF) is used to back out a receivable or a receivable line which was referenced on the original cash receipt document. The Non-Sufficient Funds Checks (NF) line amount should be the amount of the check which was applied to the receivable or line. The line amount cannot exceed the closed amount on the receivable.
A non-sufficient funds check charge can be applied to a customer's account as an NSF check charge fee. If Waive Charges is not selected, a non-sufficient funds check charge is automatically applied to the receivable specified on the Non-Sufficient Funds Checks (NF) header. If the NSF Check Charge Receivable Number is not entered on the header, the receivable from the first document line is inferred. The fields for the non-sufficient funds check charge are inferred from Revenue Options (ROPT).
If the non-sufficient funds charge accounting distribution is not manually entered, it is inferred from the first line of the receivable selected for the non-sufficient funds check charge. When the Non-Sufficient Funds Checks (NF) is processed, a new line is added to the specified receivable with line number NF. Additional non-sufficient funds check charges are added to the Non-Sufficient Funds Checks (NF) line. The accounting distribution for additional non-sufficient funds check charges must match the original Non-Sufficient Funds Checks (NF) line.
If a non-sufficient funds charge is applied to an invoice receivable, a new customer invoice is automatically generated to inform the customer of the additional non-sufficient funds check charge. The receivable is flagged for reprint on Printed Receivables (PRRE) by the NF. If a statement receivable is specified, the Non-Sufficient Funds Checks (NF) document and non-sufficient funds check charge are both listed on the next statement.
Modifying the Non-Sufficient Funds Check (NF) Transaction
NF transactions which have been entered and are on the Document Listing (SUSF), but have not been processed can be changed in correction mode. Non-Sufficient Funds Checks (NF) lines can be added, or changed and the document can be marked for deletion.
If the Non-Sufficient Funds Checks (NF) transaction has been entered and processed, non-sufficient funds processing can be reversed by entering a Receivable Credit Memo (RM) to reverse the non-sufficient funds check charges and entering a new cash receipt for the amount received.
Non-Sufficient Funds (NF) Accounting Model
The Non-Sufficient Funds (NF) transaction is posted to the General Ledger when the document is processed. This entry to the ledger provides an accounting trail of the Non-Sufficient Funds (NF) transaction. The Revenue Ledger is also updated by Non-Sufficient Funds (NF) documents.
The following ledger entry is posted to reverse the cash receipt.
Dr Assets (billed receivables)
The following ledger entry is posted for the non-sufficient funds charge amount:
Dr Assets (billed receivables)
Updates for the Non-Sufficient Funds (NF) Document
The key tables updated by the non-sufficient funds check transaction are the open receivable tables listed below. A brief discussion of the updates to each follows.
The open receivable tables are updated to reflect the backed out cash receipt and the new non-sufficient funds check charge line (if applicable). The Closed Amount on the lines of the open receivable tables reflect the backed out cash receipt. The NSF Check Charge appears on a new line on the receivable (line number NF ) and is reflected in the receivable Amount .
The Number of Occurrences NSF Checks counter on Customer Credit History Inquiry (CUSC) is automatically updated whenever a Non-Sufficient Funds Checks (NF) transaction is processed for the customer. The Last Occurrence Date NSF Check on Customer Credit History Inquiry (CUSC) maintains the date of the last Non-Sufficient Funds Checks (NF) document.
The Received to date on Customer Financial History Inquiry (CUSF) is decreased by the Non-Sufficient Funds Checks (NF) document total. Billed to date is increased by the amount of the non-sufficient funds check charge.
A line is added to Payment Detail Inquiry (PDET) for each receivable referenced on the Non-Sufficient Funds Checks (NF) lines. The line amount for the Non-Sufficient Funds Checks (NF) transaction is negative, reflecting the decrease to the cash receipt. An updated Receivable Amount on Open Receivable Options (PDET) reflects the non-sufficient funds check charge.
Receivable Document (RE) - Issues and Concepts
A Receivable (RE) is a transaction to bill a customer for goods or services provided. General accounting procedures normally require receivables to record earned revenue. Receivables can be entered online (individually or batches), or entered and scheduled as recurring receivables. A receivable transaction can also be used for tracking receivables for reimbursements.
A receivable is a recognition that money earned now will be received in the future. The transaction posts amounts to the revenue account on the transaction and to the billed receivables balance sheet account defaulted from Revenue Source (RSRC) or System Special Accounts (SPEC). Money is subtracted from an expenditure account for reimbursements.
Most receivables are entered individually or in batches using the online document processing function. Once the entered document data has been verified, the document can be processed immediately, or scheduled to be processed in nightly batch processing.
Decreases to receivable amounts are performed through a Receivable Credit Memo (RM). For more information, see See Receivable Credit Memo Document (RM) - Issues and Concepts. Only decrease modifications are allowed for prior year receivables. Adjustments to prior year revenues are charged against prior year revenue budgets and posted to the current accounting year. This process occurs, for example, when a cash receipt clears a prior year receivable for less than the billed amount. Then, the revenue adjustment is reflected in the Revenue Budget Inquiry (REV2) entry for the prior budget year and the accounting event is correctly posted to the current accounting year.
Entering Receivable (RE) Documents
Receivable documents record billed receivables. They are entered using a header and line format. The header contains document total and customer information while the lines contain the individual items the customer is being billed for and accounting information.
The receivable header displays fields providing processing information for the entire receivable document. Following are descriptions of important fields and their uses.
Customer information is required on the receivable. The Customer code is used to identify the customer being billed for the goods or services provided. The referenced customer must be an active customer on Customer Information (CUST). If the Customer code Status is Inactive or Marked for Deletion , the receivable document rejects.
The receivable infers and displays the Corporation Name and Address information for the customer unless the Customer code is defined as miscellaneous. The Corporation Name and Address must be entered in this case. If the Corporation Name and Address are inferred, they cannot be changed on the receivable document.
If a customer's billing is to be handled by a third party, the third party's name and address is inferred instead of the customer's. This address is printed on the customer's invoice. To select third party processing, the Third Party flag on the receivable must be selected. The name and address of the third party is inferred from Third Party Billing (TPAR).
The receivable due date can be established two different ways:
- It can be entered directly on the receivable document if the customer is to be billed using an invoice. If the customer is billed with statements, the due date is inferred and cannot be entered on the receivable.
- The due date can be left blank, allowing the system to calculate it. The Receivable Due Date Lag from Revenue Options (ROPT) or Billing Profile (BPRO) is used. (If a lag is entered on Billing Profile (BPRO), it overrides the lag defined on Revenue Options (ROPT)). The due date is calculated as the lag number of days after the receivable document accept date for customers who receive invoices. For customers who receive statements, the due date is the lag number of days after the next statement date.
A valid Billing Code from Billing Profile (BPRO) is required on receivable documents to specify billing information such as the remittance address and type of billing. If the Billing Code on Billing Profile (BPRO) specifies statement processing, the day of the month on which the statement is generated is also specified.
If the Billing Code is not entered online, and one has been entered on Customer Information (CUST), the code defaults from Customer Information (CUST). The Billing Code cannot be entered for summary receivables since these are not used to bill a customer.
A summary of small dollar amount receivables can be entered through a summary receivable document. To flag a receivable as a summary receivable, the RE Type field must be set to S (summary). When this flag is set, the accrual of finance charges and the printing of invoices for the summary receivable is suppressed. Summary receivables must be processed with miscellaneous Customer codes.
The RE Type field also used to identify receivable modifications for interest or late fees. If interest or late fees are to be manually entered, the RE Type field must be set to I (interest) or L (late fees). All lines on the modifying document must then be for interest or late fees.
The comments on the receivable are used as a general description of the receivable. These are printed on customer statements for each receivable document. (The line description is used on invoices).
The receivable document total must equal the sum of all the receivable lines. The document total must also be greater than or equal to the Receivable Minimum Amount on Revenue Options (ROPT). Otherwise, the document will reject.
Each line on the receivable includes a Fund , and either an Agency and Revenue source, or a Balance Sheet Account code. Reimbursements require Fund , Agency , and Object codes.
The description on the receivable line is used to describe a specific line item on a receivable. These are printed on the customer invoice lines. (The comments on the receivable are used for statements).
Billing rates can be used to standardize the amounts billed for commonly billed items. These rates are established on Billing Rate (BRTE) and are used on the receivable to calculate the line amount.
The receivable document allows for the recording of a receivable amount in two ways:
- Directly entering the receivable line Amount on the receivable line.
- Entering a billing Rate Code and Quantity on the receivable line; the system calculates and displays the receivable line amount using the following formula:
Line Amount = Billing Rate x Quantity
If the receivable line Amount , Rate Code , and Units are entered, the manually entered receivable line Amount must equal the rate computation.
A reason code is entered to justify the reason for adjusting (canceling or modifying) Receivable (RE). Reason code must be a valid value on Receivable Adjustment Reason (REAR).
Figure 58 and Figure 59 show a sample receivable input screen setup to record the building rental charges. This example shows both the required and the inferred fields on the receivable document.
Receivable (RE) Document (Other Attributes View)
Receivable (RE) Document (Customer Details View)
Once a receivable has been entered and processed, it can be modified using either a modifying receivable document or a receivable Credit Memo (RM) document. Modifying receivable documents are used to increase a receivable amount, or to change accounting information. Receivable Credit Memo (RM) documents are used to credit a customer's account and act like a decreasing receivable. For more information on Receivable Credit Memo (RM) documents, see See Receivable Credit Memo Document (RM) - Issues and Concepts.
Receivable documents can be canceled when the receivable is entered in error. Canceling the transaction reverses the revenue recognition and clears the item on the appropriate open item application tables. Canceling is achieved by using the Cancellation option on a modifying receivable document. The Cancellation option can only be used on receivables for which no cash has been collected.
If a receivable has been partially closed, canceling is achieved by using a Receivable Credit Memo (RM) and decreasing each line by its outstanding balance. For more information on Receivable Credit Memo (RM) documents, see See Receivable Credit Memo Document (RM) - Issues and Concepts.
Billed Receivables Offset Account for a Receivable (RE)
The balance sheet account used in the system-generated offsetting entry for receivables is inferred as follows:
- If an offset receivables balance sheet account is recorded on the document, that account is used for all the lines.
- If a billed receivables balance sheet account is recorded in Revenue Source (RSRC) for the Revenue Source code used, that receivable account is used.
- If the Billed Receivables field on Revenue Source (RSRC) is blank, the system-wide default billed receivables account, specified in System Special Accounts (SPEC), is used.
Accounting Model and Ledger for Receivable (RE) Documents
When a receivable document is processed in MARS, ledger records corresponding to each receivable line are posted to the Current Detail General Ledger. Generally, receivables are used to record earned revenue and the following accounting entries are posted:
Dr Assets (billed receivables)
The basic accounting model for receivables used to recognize earned revenue is displayed in the following example. Depending on the nature of the receivable document, one of the accounting models identified below is used in place of the standard revenue recognition accounting model.
When the receivable is used to record a reimbursement document, the collection of cash is recorded and the expenditure corresponding to the reimbursement is reduced. An example of this is a vendor owing money due to an overpayment or incorrect quantity shipped. The accounting model is:
Dr Assets (billed receivables)
When a receivable records a balance sheet account transaction, the billed receivable is recorded and a balance sheet account credited to record the unearned revenue (rental income). The accounting model is:
Dr Assets (billed receivables)
On revenue transactions, the recognized amount in the appropriate entry on Revenue Budget Inquiry (REV2) is increased by each line amount. On reimbursement transactions the expended amount is decreased on the appropriate lines on Expense Budget Inquiry (Extended) (EEX2) and Appropriation Inquiry (Extended) (EAP2).
Updates for Receivable (RE) Documents
When a receivable document is accepted, a line is created on Open Receivable Line Inquiry (OREL) for every line listed on the document. One entry is also created on Open Receivable Header Inquiry (OREH) to store data from the header portion of the document.
When the record is added to Open Receivable Header Inquiry (OREH), records are also added to the Open Receivables by Customer Inquiry (OREC) and Open Receivables by Due Date Inquiry (ORED). Open Receivables by Customer Inquiry (OREC) lists all of the receivables processed (in receivable document number order) for a particular customer. Open Receivables by Due Date Inquiry (ORED) provides a list of all receivables (in due date order) by Customer and Billing Code. This window is useful for monitoring what is outstanding for a customer for each billing location.
Receivable Credit Memo Document (RM) - Issues and Concepts
Defining the Receivable Credit Memo (RM)
Receivable Credit Memo (RM) documents are used to modify and cancel receivable documents. For example, if a customer receives the incorrect quantity of goods or if the customer overpays, a Receivable Credit Memo (RM) document is processed, crediting a customer's account.
Entering a Receivable Credit Memo (RM) Document to Modify a Receivable
A Receivable Credit Memo (RM) document can be used to modify the line amount established on the original receivable. You must give the Receivable Credit Memo (RM) the same Transaction ID as the Receivable (RE) document you are modifying. Accounting distributions cannot be changed, and new lines cannot be added to existing receivables. Header information is also protected on the Receivable Credit Memo (RM).
The receivable line Amount cannot be decreased to less than the portion of the receivable already closed. If the Fund Balance Control Option on Fund (FUN2) is Select for the fund, a Receivable Credit Memo (RM) document cannot decrease the fund balance amount below the minimum fund balance control amount.
Figure 60 and Figure 61 display sample Receivable Credit Memo (RM) windows. The only information required on the Receivable Credit Memo (RM) document is the Document Total , the Line number, and the line Amount . All other information is inferred from the original receivable.
Receivable Credit Memo (RM) Document (Other Attributes View)
Receivable Credit Memo (RM) Document (Customer Details View)
Entering a Receivable Credit Memo (RM) Document to Cancel a Receivable
If a receivable has been partially closed, a Receivable Credit Memo (RM) document is processed to cancel the receivable The Receivable Credit Memo (RM) document decreases each line on the receivable by its outstanding balance.
The canceled receivable is marked closed on Open Receivable Header Inquiry (OREH) and posted to the historical files in the following clearing cycle.
If a Receivable Credit Memo (RM) reduces the receivable to less than zero, the Replacement Indicator on Printed Receivables (PRRE) is automatically changed to A (adjustment) and a credit invoice is generated during the Nightly Cycle.
Write-Off Document (WO) - Issues and Concepts
Receivables deemed uncollectible can be written off as a reduction in revenue using the Write-Off (WO) document. The Write-Off (WO) document is generated offline based on Potential Uncollectible Receivable (PUNR). This window contains a list of receivables which have been selected as significantly past due. A nightly process creates the Write-Off (WO) documents based on a flag on Potential Uncollectible Receivable (PUNR).
The write-off process is controlled and scheduled from Potential Uncollectible Receivable (PUNR). Once this table is loaded, write-offs can be scheduled.
Receivables are loaded into Potential Uncollectible Receivable (PUNR) in a nightly process. An Application Dates (LDAT) parameter is specified to define the number of days past due a receivable must be to be added to Potential Uncollectible Receivable (PUNR). Records can also be manually entered onto Potential Uncollectible Receivable (PUNR). See Figure 62.
Potential Uncollectible Receivable (PUNR)
Once a receivable has been entered on Potential Uncollectible Receivable (PUNR), it can be scheduled for write-off by entering S (scheduled for write-off) in the Write-Off Indicator . This schedules the receivable to be written off during the next run of the write-off batch process. To stop the write-off process for a receivable, the Write-Off Indicator must be spaced out, or the Potential Uncollectible Receivable (PUNR) record deleted from the table. The Write-Off Indicator is also displayed on Open Receivable Options (OREO), but cannot be updated there.
Once a receivable has been marked for write-off, the nightly process automatically generates a Write-Off (WO) document for the receivable. WO documents should not be entered online . When the Write-Off (WO) is processed, the recognized revenue is reversed for the uncollected balance of the receivable. If cash has been collected, only the outstanding balance is written. Samples of the generated Write-Off document are shown in Figure 63 and Figure 64.
Receivable Write-Off Document (Other Attributes View)
Receivable Write-Off Document (Customer Details View)
Accounting Model for the Write-Off (WO) Document
The Write-Off (WO) document is posted to the General Ledger when the document is processed. This entry to the ledger provides an accounting trail for the Write-Off (WO) document. The Revenue Ledger is updated in the nightly batch processing with the Write-Off (WO) documents posted to the General Ledger. The entries posted for the Write-Off (WO) document depend on the type of receivable that is referenced.
The following entry is posted to reverse the accounts receivable of a write-off that credited revenues:
Cr Assets (Billed Receivables).
The recognized amount on Revenue Budget Inquiry (REV2) is also decreased by the amount of the write-off (receivable outstanding balance). The current year's revenues are decreased by the amount of the receivable, regardless of the year the receivable was processed.
Updates for the Write-Off (WO) Document
When the Write-Off (WO) document is processed and accepted the following tables are updated:
Once a receivable has been written off, the Write-Off Indicator on Potentially Uncollectible Receivable (PUNR) is changed to W to indicate that the receivable has already been written off. This flag is also displayed on Open Receivable Options (OREO).
Open Receivable Header Inquiry (OREH) and Open Receivable Line Inquiry (OREL) are updated to reflect the amount written off. The Billed Amount field on Open Receivable Header Inquiry (OREH) and the Billed Line Amount field on Open Receivable Line Inquiry (OREL) are both decreased by the amount of the outstanding balance. The receivable is then marked closed.
The Write-Off (WO) documents update the total amount written off on Customer Financial History Inquiry (CUSF). This is increased by the document total of the Write-Off (WO) document. The number of receivables written off and the Last Occurrence Date Write-Off on Customer Credit History Inquiry (CUSC) are also updated.
The external billing facilities are used to bill customers using invoices or statements. Invoices or statements are automatically generated based on user-defined billing specifications. Renewal notices can also be defined and automatically generated.
Customer invoices are printed in the nightly cycle in MARS or on demand to bill customers. Invoices are generated whenever invoice processing is selected for the customer or receivable, and one of the following conditions exists:
- A new receivable is entered into the system
- A replacement invoice is requested
- An adjustment has been made to a receivable amount
- A credit balance exists on the receivable
Original invoices are processed on the same schedule as replacement, adjusted, or credit invoices. Original invoices are printed whenever new receivables are entered into the system. Replacement, adjusted and credit invoices are generated based on the Replacement Indicator on Printed Receivable (PRRE).
Original invoices are generated from data entered in the system through the receivable transaction. Reprints use the original data plus any modification data.
A variety of special features are available to enhance the invoice generation process. These features include the ability to:
- Print locally and on-demand
- Select remittance location
- Bill a third party
- Automatically print special instructions
- Place an invoice on hold so that it is not printed
- Reprint invoices for modified receivables
Invoice generation is discussed in greater detail in the following sections.
Invoice processing can be selected for a specific Billing Code on Billing Profile (BPRO). An invoice Billing Code must then be selected on the receivable document. When a receivable document is entered, a Billing Code can be entered, or it can be inferred from Customer Information (CUST, CUS2). If the Invoice/Statement indicator on Billing Profile (BPRO) is set to Invoice or Both (both invoices and statements), then an invoice is generated for the receivable processed.
The Billing Code also specifies a remittance location. This remittance location is the address to which the customer must send their payments. This address is automatically printed on all invoices. The Pay To fields on Billing Profile (BPRO) specifies who the customer should make their checks payable to.
Original invoices are automatically generated for the receivables selected for invoice processing. When a receivable document is accepted into the system, the open receivable tables are updated. The records stored on these tables are then used to generate invoices. Input parameters are not required for the invoice generation process. An invoice document example follows.
The Invoice Register Report lists receivable document and corresponding customer information for invoices printed and those bypassed because of errors. The original invoice date and the invoice amount are also printed on the report. A sample Invoice Register can be found in the User's Reference.
The system tracks all of the printed invoices in Printed Receivable (PRRE). This window is a list of receivable document IDs and the date when the invoice was printed. This window can be used as a reference to verify whether a specific invoice was issued to the customer. The window also identifies invoice reprints caused by modifications to invoices that were already printed, and tracks and modifies the dunning and collection letter processing.
The user can print invoices on line instead of batch processing. On-Demand Invoice Print (ODIN) is used to initiate the print.
Third parties can be billed for a customer's receivable if third party processing is selected on the receivable document. The customer's Third Party Code from Customer Information (CUST) is used to select the name and address of the party being billed.
If a customer's billing is handled by a third party, a record can be added to Third Party Billing (TPAR) to specify the name and address of that party. To assign a customer's billing to a third party, the Third Party Billing Code must be entered on Customer Information (CUST).
A cross-reference between the Third Party code and the Customer code is provided on Third Party/Customer Reference Inquiry (TPCU).
Shipping and Special Instructions
Special instructions, or other types of messages, can be printed on the customer's invoice. Instruction codes are defined in Special Instruction (SPIS) which stores four thirty character lines for each Instruction code. When the invoice is printed, the message is inferred from this window.
To have special information printed on the invoice, the Instruction code must be entered in the Instruction Code field on the original receivable document. The Instruction Code can also be inferred from Billing Profile (BPRO) as a default. The Instruction Code can be changed on Open Receivable Options (OREO) once the receivable document has been processed.
A customer may request a new copy of the previously issued invoice. The replacement invoice can be requested by setting the Replacement Indicator on Printed Receivables (PRRE) to Y .
Replacement invoices are selected in a process separate from original invoice printing, but are printed together with original invoices. Printed Receivables (PRRE) is searched, and replacement invoices reprinted if the Replacement Indicator on Printed Receivables (PRRE) is equal to Y . The replacement invoice displays the following message:
REPLACEMENT -- LAST PRINT: XX/XX/XX
where XX/XX/XX is the date printed from Printed Receivables (PRRE).
The date printed is updated whenever an invoice, including a replacement, is generated.
Modified or Credit Invoice Generation
Changes must sometimes be made to a receivable document after it has already been sent to the customer. Adjusted invoices are generated whenever the receivable amount is changed with a modify/increase receivable, a Receivable Credit Memo (RM) or non-sufficient funds check charge from an Non-Sufficient Funds Checks (NF) transaction.
When receivable amount adjustments are made using modifying transactions, the Replacement Indicator on Printed Receivables (PRRE) is automatically set to A (adjusted). An adjusted invoice is only sent if the original invoice has already been sent, otherwise, an original invoice is sent which includes the modified information.
The following message is printed on the replacing invoice to inform the customer that an adjustment has been made to the original invoice amount:
ADJUSTMENT -- LAST PRINT: XX/XX/XX
where XX/XX/XX is the Last Print Date from Printed Receivables (PRRE).
If interest or late charges are the adjustment to a receivable, a past due notice is sent instead of an adjusted invoice.
If credit balance is created on a receivable (outstanding balance is less than zero), the credit balance is printed on the invoice to inform the customer of the overpayment. The special instructions should inform the customer how to receive a refund, or apply the credit to other outstanding receivables.
Suppressing Invoice Generation
Invoice generation can be suppressed by not selecting the Generate Billing indicator on Open Receivable Options (OREO) or by setting the Dispute Indicator to Yes . Generate Billing defaults to being selected when a receivable is accepted, unless it is a summary receivable, in which case the default is blank .
The Dispute Indicator should be set to Yes for receivables which are being disputed by customers. When the Dispute Indicator is set to Yes , the Generate Billing indicator and the Accrue Finance Charge indicator on Open Receivable Options (OREO) are set to is blank . The default for the Dispute Indicator is blank .
Invoice generation is automatically suppressed if a receivable has been:
- Marked as a summary receivable
- Placed on a payment schedule
- Flagged for payment intercept
- Marked for collections
- Marked for legal action
- Scheduled for write-off or written off
For more information on past due accounts, see See Past Due Accounts.
Customer statement generation lists all revenue transactions for a particular Customer/ Billing Code combination on one monthly statement.
Statement processing can be selected for a specific Billing Code on Billing Profile (BPRO) by entering Statements or Both (both invoices and statements) in the Invoice/Statement indicator. Any receivable or document referencing the receivable with such a Billing Code is included on a customer statement. This Billing Code can be directly entered on a receivable document, or inferred from Customer Information (CUST, CUS2) when processing a receivable.
During statement processing, a selection process chooses all transactions with statement dates after the last statement processing date. For example, if the last statement was printed on 12/01/99 and today is 12/03/99, statement dates 12/02/99 and 12/03/99 are selected for the current statement generation.
All transactions for a particular Statement Date/Customer Code/Billing Code combination are printed on a single customer statement. Detail information is found on Customer Document Inquiry (CDOC). Transactions processed after the statement date are not selected for the current statement, but are scheduled for the following one.
The customer statement is printed in a format that provides a quick summarization of a customer's activity for a particular period. It contains the following information:
- Customer data
- Remittance address
- Amount due
- Due date
- Transaction date
- Document ID
- Description
- Transaction amount (new charges/payments)
- Interest or late charges
- Aging categories
- Special instructions or dunning messages (if appropriate)
Once a statement has been generated, Statement (STMT) is updated with general statement information. The Current Statement Amount , last Dunning Message Code and last Dunning Message Day field are updated for the current period. Summary aging categories are also updated. A prior statement balance record is added to Customer Document Inquiry (CDOC) to show the beginning balance of a statement period. A sample statement follows.
A statement register is generated when the customer statement process is run. It displays a list and count of customer statements generated successfully. Also, a list of statements that were not generated due to errors is printed.
The user can print statements on-line instead of through batch processing. On-Demand Statement Print (ODST) is used to initiate the print.
Replacement Customer Statement Generation
A customer may request a new copy of a previously issued statement. Replacement statements can be requested by selecting the Replacement Indicator on Statement (STMT).
Replacement statements are selected and printed in a process separate from the original statement printing. "Replacement Statement" is printed on the reissued statement. Once a period is cleared from Customer Document Inquiry (CDOC), replacement statements can no longer be generated.
Suppressing Statement Generation
Customer statement generation can be suppressed for all statements for a customer or for a particular customer account (Customer/Billing Code). To suppress all statements for a customer, the customer's code must be entered on Statement Hold (STHD) with a blank Billing Code . To suppress a particular customer account, both the Customer code and Billing Code must be entered. As long as the record remains on Statement Hold (STHD), statements are not generated.
Renewal notices can be defined and scheduled for a particular customer, and then generated by the MARS Nightly Cycle. Renewal notices are reminders that a license, registration, or subscription is about to expire. Renewal notices do not generate accounting entries.
Establish Renewal Types and Schedules
Renewal notices must be defined on Renewal Type (RNTP), Renewal Notice Text (RTXT) and Renewal Notice Scheduling (RNEW) before the notice can be generated. This defines the type of notice, the text to be printed and the scheduling of the notice. An on demand batch process generates all of the notices scheduled since the last printing.
Renewal Type (RNTP) is used to define a renewal notice type and specify its frequency. This window contains a Renewal Type code, its Frequency (monthly, quarterly, semi-annually, bi-annually, or annually) and brief renewal type Description. Renewal Notice Text (RTXT) is used to specify the text of the notice.
Renewal notice generation for customers is based on a schedule defined on Renewal Notice Scheduling (RNEW). A Generation Date and Expiration Date specify the time period for which the renewal notices are generated. When entered, the Generation Date is the date of the first scheduled notice. The Generation Date is updated during renewal notice processing to show the next date for which the renewal notice is scheduled. This is based on the frequency specified on Renewal Type (RNTP). Notices are generated until the expiration date.
The Renewal Date Lag field on Renewal Notice Scheduling (RNEW) is used to specify a renewal date, which is the date by which customers must process the renewal.
Renewal notice printing is an on-demand process. Renewal Notice Scheduling (RNEW) is read sequentially and any notice which is scheduled for the current month is printed. The printing process uses the letter text from Renewal Notice Text (RTXT) and customer information from Customer Information (CUST, CUS2). The remit to Address from Billing Profile (BPRO) is also printed on the renewal notice. A sample Renewal Notice follows.
Once the notice has been printed, the Generation Date field is updated on Renewal Notice Scheduling (RNEW) based on the frequency specified on Renewal Type (RNTP). If the date of the next renewal notice falls after the Expiration Date on Renewal Notice Scheduling (RNEW), the Renewal Notice Scheduling (RNEW) record is deleted.
A renewal register is generated each time the renewal generation process is run to control the generation process. It contains a list of renewals that were not generated due to errors, a list of renewals generated with warning messages, and totals for each.
MARS provides a variety of functions to improve collections of past due accounts. These include accruing finance charges, sending customers past due notices and processing various types of collection processes. Each one of these capabilities is optional, and has its own controls that allow it to be bypassed as necessary.
Interest and late fee accrual is performed for delinquent accounts receivable based on finance charge parameters defined in system-wide Revenue Options (ROPT) or Revenue Options by Agency/Revenue Source (ROAR). These finance charge parameters and the accrual process are described below.
Interest Charge and Late Fee Specification
The Finance Accumulation Type is defined system-wide on Revenue Options (ROPT), but can be overridden on an agency or agency/revenue source level on Revenue Options by Agency/Revenue Source (ROAR). The Finance Accumulation Type determines if an interest charge, late charge, or neither is applied to the customer's receivables. The Finance Accumulation Type can have the following values:
The Interest Type , Interest Rate Percentage, and Late Charge Amount fields are also defined on Revenue Options (ROPT) and Revenue Options by Agency/Revenue Source (ROAR).
The finance charge accrual is performed in conjunction with dunning message printing. When a dunning message is sent to the customer, finance charges are accrued. The new invoice or statement contains the accrued finance charges. Late fees are applied once, as soon as the receivable is past due. Interest is accrued based on the number of days since the last interest accrual.
Simple interest is calculated using the following formula:
Interest Charge = Daily Rate x Number of Days x (Principal Balance - Current Payments).
Compound interest charges are compounded daily using the following formula:
Interest Charge = Daily Rate x Number of Days x (Principal Balance + Previous Interest Charges - Current Payments).
The number of days for which interest is calculated is equal to Current Date minus the Finance Charge Date. The Finance Charge Date , which is stored on Open Receivable Header Inquiry (OREH), is the last date that interest or late fees were applied to the receivable. The Finance Charge Date defaults to the Receivable Due Date , when the receivable document is originally processed. This field is updated whenever interest is applied to a receivable.
The principal balance is the original outstanding balance of the receivable minus the payments applied. The finance charges are applied using generated modify/increase receivable documents. New lines are added to the receivable for interest charges and late fees. (Interest line numbers begin with I and late fee line numbers begin with L .) The Interest Charge Revenue Source from Revenue Options (ROPT) is used on all interest lines and the Late Charge Revenue Source from Revenue Options (ROPT) is used on all late charge lines. As new charges are accrued, they are added to the existing charge lines through modify/increase receivable documents.
Finance charges can also be added online through modifying receivable documents. When applying interest charges, the RE Type must be set to I (interest line numbers). All the lines on that document are then considered interest and must use the Interest Charge Revenue Source from Revenue Options (ROPT). Late fees are processed similarly. The Finance Accumulation Type must be set to L (late fee), and all of the lines on the document must use the Late Charge Revenue Source from Revenue Options (ROPT).
The following accounting entries are posted in nightly cycle for the accrual of interest and late charges as a result of the application of finance charges.
Suspending Interest/Late Fee Accrual
Finance charge accumulation for a receivable can be suspended by setting the Accrue Finance Charge flag on Open Receivable Options (OREO) to blank . If a receivable is in dispute or has been flagged for intercept, collections, legal action or write-off, finance charge accrual is automatically suspended. The Accrue Finance Charge indicator is automatically set to blank (stop accruing finance charge) whenever the Dispute Indicator is equal to Yes , the Collection Status indicator is set to Collections , Legal Action , or Intercepts , or the Write-Off indicator is Scheduled . This is done to ensure that the amount sent to collections or intercept is not different than the current balance of the receivable. The Accrue Finance Charge indicator is also set to blank for summary receivables and receivables placed on a payment schedule.
If a customer is delinquent in paying their invoice or statement, additional notices are sent to them informing them of the delinquency. Dunning messages are sent on copies of the invoice or statement.
Dunning Message (DUNN) is used to enter dunning messages. Dunning Message (DUNN) is keyed by a user-defined Dunning Message Code.
Dunning message processing is completely automated. The system default order and timing of the printing of the dunning messages is defined on Collection Control (CCTL). The Number of Days Past Due and the Dunning Message Code are defined there. The system default collection cycle on Collection Control (CCTL) can be overridden on Billing Profile Collection Cycle (BPCC) on a billing profile level.
Invoice Generation with Dunning Message
Dunning invoices are generated during the nightly cycle based on the next dunning message and days past due specified on Printed Receivables (PRRE). The next dunning message and days past due are automatically updated based on the definition on Collection Control (CCTL) or Billing Profile Collection Cycle (BPCC). For example, Collection Control (CCTL) or Billing Profile Collection Cycle (BPCC) might contain the following entries for dunning messages:
Dunning Message AA is automatically entered into the next dunning message on Printed Receivables (PRRE) after the initial generation of the invoice. The AA message is printed 1 day after the due date. The next dunning message would then be updated to BB which prints 30 days after the due date and CC follows 60 days after the due date.
Dunning message generation can be suppressed on Open Receivable Options (OREO). The Generate Billing indicator on Open Receivable Options (OREO) can be manually set to blank to suppress the printing of dunning messages for an individual receivable.
Statement Generation with Dunning Messages
Dunning message processing for statements is similar to that of invoices. The messages are generated based on the text defined on Dunning Message (DUNN) and the schedule on Collection Control (CCTL) or Billing Profile Collection Cycle (BPCC). Dunning messages for statements are generated on the age of the oldest receivable past due. If no receivables for a statement (defined by Customer code and Billing Code) are past due, no dunning message is generated. The dunning message printed and the number of days past due are stored on Statement (STMT) for each statement period.
Customized Dunning Message Scheduling
Customized dunning messages can be added to Dunning Message (DUNN). Customized dunning messages must be scheduled for a receivable on Printed Receivables (PRRE). The code of the customized dunning message is entered in the next dunning message on Printed Receivables (PRRE) in place of the normally scheduled one. The customized dunning message is printed during the next printing cycle. The next normally scheduled dunning message is automatically scheduled after the customized dunning message.
Collection letters can be sent to customers whose receivables are significantly past due (as defined on Collection Control (CCTL) or Billing Profile Collection Cycle (BPCC) ). Collection letters are used to inform customers of impending collection proceedings. Letters defined on Collection Letter (COLT) are automatically generated based on the receivable's number of days past due.
Collection letters can only be generated for receivables whose Billing Code specifies invoice processing. For statements, dunning messages are used to inform customers of collection proceedings. If a collection letter is scheduled for a statement, it is bypassed.
Collection letters are entered on Collection Letter (COLT). As with dunning messages, collection letter schedules are defined on Collection Control (CCTL) or on a billing profile level on Billing Profile Collection Cycle (BPCC).
The Next Collection Letter field on Printed Receivables (PRRE) is automatically updated when the last dunning message or a previous collection letter is generated. For example, Collection Control (CCTL) or Billing Profile Collection Cycle (BPCC) might contain the following entries for collection letters:
Collection letter A prints 90 days after the due date. Letter B prints 120 days after the due date.
Collection letter generation can be suppressed for invoices on Open Receivable Options (OREO). The Generate Billing indicator on Open Receivable Options (OREO) can be manually set to blank to suppress the printing of collection letters for an individual receivable.
Each letter is printed in batch on the first processing day after the number of days past due specified for it on Collection Control (CCTL) or Billing Profile Collection Cycle (BPCC). Once a letter has been printed, the next one to be printed is designated in the Next Collection Letter field on Printed Receivables (PRRE). When the last scheduled letter or dunning notice has been printed, the printing process ends.
A Collection Letter Register, like the invoice register, is generated each time the collection letter generation process is run. It stores a list of collection letters that were generated successfully, those that were not generated due to errors, and totals for each.
Customized Collection Letter Scheduling
Customized collection letters can be added to Collection Letter (COLT). Customized letters must be scheduled for a receivable on Printed Receivables (PRRE). The code of the customized letter is entered in the Next Collection Letter field on Printed Receivables (PRRE) in place of the normally scheduled one. The customized letter is printed during the next printing cycle. The next normally scheduled collection letter is automatically scheduled after the customized letter.
Master service agreements can be established with vendors of collection services to assist in collecting on past due accounts. Individual receivables can be assigned to collection agencies, and the agency's performance can be monitored through Master Service Agreement (MSAT) and reports. Master Service Agreement (MSAT) can also serve as a link to an internal collection system.
Establish Collection Agreement
Master service agreements are set up to specify information regarding a contract with a collection agency. The vendor who is providing the collection services is identified on Master Service Agreement (MSAT). The vendor name and address are inferred from Vendor (VEND). Master Service Agreement (MSAT) is also used for online inquiry and reporting on the performance of the collection agencies.
Master Service Agreement (MSAT)
The collection process is initialized when the Collection Status field on Open Receivable Options (OREO) is set to Collection at which time a Collection Agreement Number must also be entered. This number must be valid on Master Service Agreement (MSAT). At this time, finance charge accrual, invoice printing and collection notice printing are stopped. Other collection processes cannot be performed while a receivable is in collection status.
When an agreement is selected, the amount assigned on the Master Service Agreement (MSAT) record for that agreement is updated by the outstanding balance of the receivable sent to collections. The number of collections on Customer Credit History Inquiry (CUSC) is also updated by adding one to the counter. The Last Occurrence Date Collection on Credit History Inquiry (CUSC) is set to the current date.
A receivable can be flagged for legal proceedings to collect past due accounts. A receivable is flagged for legal action by setting the Collection Status on Open Receivable Options (OREO) to Legal Action . When the receivable is flagged in this way, finance charge accrual, invoice printing, and collection notice printing are suspended. Other collection processes cannot be performed while the receivable is in legal action status.
If a customer who is also a vendor is past due on their account, payments to them as vendors can be withheld to repay the debt.
Warrant Intercept (WINT) is used to schedule past due receivables for vendor offset processing. The withholding amount defaults to the receivable outstanding balance, but can be changed to any amount less than that. When a record is entered onto Warrant Intercept (WINT), the Collection Status on Open Receivable Options (OREO) is automatically changed to Intercepts . The Number of Occurrences Intercept Attempts and the Last Occurrence Date Intercept Attempt on Customer Credit History Inquiry (CUSC) are also both updated.
The vendor offset process intercepts payments during the normal automated disbursement process. Before a check is generated for a vendor, receipts are recorded for the past due receivables on Warrant Intercept (WINT). Following is a description of how the intercept amount is determined:
- If the vendor's voucher total is greater than or equal to the withholding amount, a negative voucher line is added to the selected voucher file. This line is used to subtract the withholding amount from the check amount. The withholding amount is added to the closed amount of the receivable through a cash receipt transaction. If the outstanding balance is decreased to zero, the receivable is closed.
- If the vendor's voucher amount is less than the amount of the withholding, a check is created for zero dollars with a stub which lists the vouchers and withholdings. The outstanding balance of the receivable is decreased by the amount of the vendor's vouchers through a cash receipt document.
- Once payment intercept has taken place, a check is printed for the vendor for the remaining amount owed, and the cash receipt document is automatically generated for the amount withheld to repay the receivable. A report containing cash receipt, receivable and customer information is created in this process.
Some customers require flexible repayment plans to repay their receivables. These plans can be entered on Payment Schedule (PSHD) which maintains payment schedules for delinquent accounts. Payment Schedule (PSHD) displays a Receivable Number , scheduled payment Due Date and Amount Due .
If a payment on the schedule is delinquent, additional interest and late fees must be applied manually. Automatic finance charge accrual, invoice generation and collection notification is suspended when a receivable is placed on a payment schedule. Collection proceedings cannot take place if a receivable is on a schedule.
The cash receipts referencing a receivable on Payment Schedule (PSHD) are listed, like other cash receipts, on Payment Detail Inquiry (PDET).
The recurring receivable capability of MARS automatically generates receivable documents using customer agreement data entered in Recurring Receivable (RERE). This table-driven process provides for automatic billing of fixed charges that occur monthly, quarterly and annually.
All information for producing the receivable documents is derived primarily from Recurring Receivable (RERE). An eleven-character recurring receivable number is used to identify a unique recurring receivable. The first nine digits of this are entered online and are not edited by the system. The accounting period in which the receivable is processed is automatically entered into the last two positions of the recurring receivable number. This provides a unique receivable document ID across accounting periods.
Recurring Receivable (RERE) maintains Effective Date and Expiration Date as well as a Billing Frequency indicator controlling how often the agreement is to be selected. The transaction dates and transaction numbers are supplied by the nightly process that generates and loads the receivable documents to the Document Listing (SUSF). Users can access these transactions in correction mode, make changes, if desired, and process them. This capability is useful for receiving events such as rent collection or property tax collection.
New information or modified data is entered in Recurring Receivable (RERE). During data entry, data is validated (codes are validated against the entry start date and fiscal year), however, no validations are made against the budget tables. A comprehensive validation of data entered occurs when the documents are added to the Document Listing (SUSF) and processed by the receivable document processor.
The recurring receivable generation process consists of two steps. The first step produces a Scheduled Billing Report and creates a file of receivable documents to be loaded to the Document Listing (SUSF). The second step loads the file of receivable documents into the Document Listing (SUSF) for overnight processing. If corrections are necessary, the receivable documents may be changed before they are processed by the Nightly Cycle program.
The Billing Frequency field on Recurring Receivable (RERE), in conjunction with the beginning date of the agreement, determines when a receivable document is created. Valid values for the Billing Frequency field are:
- Monthly
- Quarterly (agreements are selected once every quarter)
- End of Quarter (agreements are selected the third month of every quarter)
- Semi-Annually
- Yearly (agreements are selected on the anniversary month of the agreement)
- Bi-Annually
For all billing frequencies, the automatic billing process stops when the current date is greater than the agreement expiration date.
The accounting distribution is determined solely from Recurring Receivable (RERE). Either revenue sources or balance sheet accounts may be billed.
All data entered on Recurring Receivable (RERE) passes through limited edits performed by the Recurring Receivable (RERE) table processor. These edits verify that specified dates are in Calendar Date (CLDT), amounts are numeric, and that Account codes, if entered, are valid. Complete edits (such as revenue budget edits) are performed by the receivable document processor.
To bypass or hold a recurring receivable from a billing run, select the Hold field on Recurring Receivable (RERE) before the transaction generation process is run.