Accounts Receivable

Introduction

The Accounts Receivable/Cash Receipts system is designed to manage a wide variety of customers, charges, and payments. Powerful features allow classification of customers, classification of charges, streamlined cashiering, and easy access to payment status or history.

The fundamental purpose of the Accounts Receivable (AR) system is to track and monitor revenues, cash receipts, and funds incoming from sources other than City, State and Federal funds. Each charge and payment is maintained in the system as a separate transaction and retained in the system for a user-specified period of time. Each transaction is associated with a variety of information, including the customer number and name, the transaction amount, the transaction date, transaction description, and the GL and JL account number.

Features

Information Entry

• Access, amend, or add customer information freely

• Transactional information may include units, quantity, product code, discount pricing, sales and use tax (where applicable), and other charges

• Custom interfaces allow entries from other systems either in set mode or interactively

• Complete audit trail is available on all entries

• Choose between manual or system-generated reference and invoice numbers

• Predefine and create calculations for charges such as finance charges, transfers, interest, and late fees

• Predefine and apply payment plans to customer accounts as appropriate

Cashiering

• Use a receipt printer and optional cash drawer

• Interactive posting to Accounts Receivable

• Apply received amounts to specific outstanding invoices or oldest invoices first

• Enter Cash Receipts for new revenues, i.e., there is no outstanding invoice

• Print receipts as Cash Receipts are entered. The form of the cash receipt is user-defined

• Determine bank account for deposit by user or by the account number in the transaction

Invoicing and Billing

• Control billing periods

• Different billing periods may be used for different classes of customers

• Determine the amount of online history to be maintained

• Selectively print invoices, invoice summaries, and statements for a customer or group of customers

• Accommodate multiple invoice and statement forms

• Customizable late notices and public/private communications

• Send duplicate bills to several entities using third-party billing

Module Integration

• Post to the General Ledger (GL) in summary and/or detail. GL account validation occurs at data entry time, as does budget checking.

• Accounts Payable (AP) entries may be derived from Accounts Receivable transactions for activities such as travel advances.

Concept Topics

Account ID

"Account ID" is another name used to describe the PE (Person/Entity) ID or Employee ID. The life of an Account ID begins as a record in either the Person/Entity (PE) Information (PEUPPE) page or the Human Resource (HR) Employee Master (HREMEN) page. After defining a PE or HR record, the Accounts Receivable subsystem will inherit the same PE ID (or Employee ID).

The Account ID may be manually added to the AR subsystem by creating a record within the AR Account Information (ARUPAC) page or the PEID will automatically become an AR Account ID after completion of the first AR transaction. After establishing a record within the AR Account Information page, customize particulars for an account, such as setting a credit limit, preferred billing address, and other setup specific to that customer. After establishing the PEID within the AR subsystem, the PEID and Account ID are one in the same. The PEID is a global code that will be used for referencing not only accounts receivable, but also is used throughout BusinessPlus for linking transactions to the specific customer or employee.

The Account ID is a cornerstone for tracking account balances within the Accounts Receivable and Accounts Payable subsystems. Account IDs tie various transactions together and serve multiple purposes, such as generating month-end statements that detail purchases and account balances. Therefore, a unique Account ID is a vital reference number that must correctly identify the person or entity who is incurring the charge, or who has made the payment within the AR subsystem.

Division Codes

In the General Ledger, multiple AR "control" accounts often exist to maintain an AR balance in a subsidiary ledger for selected types of charges per an Account ID. The ability to view detailed information is formally modeled in the AR system as a Division Code. Division codes categorize transactions for the purposes of reporting, balance forward utility (ARUTBF), and determining posting preferences. There is almost always a one-to-one relationship between the number of AR control accounts and the number of division codes. Some sample division codes are STAR-Student Accounts Receivable, TADV-Travel Advance, RECR-Recreation, and UTIL-Utilities. Division codes for Accounts Receivable are normally defined during system installation. Division Codes are defined in the AR Code Definitions (ARUPCD) page.

Finance Codes

Finance codes are used in interface processes to determine some of the values to put on the records being created. For example, ARSPCL, SIOEFL, APOHBTDS processes all interface and create records in AR/CR sets for further processing.  So, if someone runs ARSPCL (coded calc process) (which will create a set of transactions), the software will get the Finance Code from the coded calc code (ARUPCD Calculation) to determine what GL account number, etc. to put on the record it creates.

GL Account Number

Each transaction also has the GL account number to indicate which GL Account to credit. For charges, the GL account is usually an income or revenue account; for payments, the GL account credited is often the appropriate control account. System installation begins with these standard strategies for automatic postings. Posting strategies will then automatically create the offsetting entries. Accountants may also make changes to or add strategies.

Posting strategies are extremely flexible and will happen exactly the way users design them to function. High-level users define these postings in the system so there is no need to create manual journal entries to post to accounts such as Cash in Bank or Accounts Receivable. The system will make these entries automatically each time transactions are processed with the help of posting codes.

Posting Codes

To provide for the accounting requirements of a double-entry system, the appropriate debit entry must be made to either the AR Control Account (for charges) or to Cash (for payments). BusinessPlus supports the generation of these debit entries automatically with the concept of a posting code. The posting code references a table where complementary entries are defined for each code. The complementary entries can occur at the detail level or at a summary level (e.g., for Post Code 01). Post AR transactions to the individual account indicated on the transaction (on the credit side) and the total of all AR transactions to Account "XXXX YYYY" (post the debit to the AR Control Account). Transaction amounts are normally entered as positive dollar figures; charges are entered with a transaction type of AR; and payments are entered with a transaction type of CR. To reverse a charge or a payment, simply enter a transaction with a negative dollar amount (e.g., -5.00).

The page that allows definition of the subsystem interfaces is the GL Subsystem Interface (GLUTSPSI) page. Also refer to common codes with a Code Category of GLxx.

Dates

Four dates can be associated with each transaction. For charges, the reference date is the date the charge was incurred; the due date is the date the charge is due; the post date is the date the transaction was posted (distributed) to the GL; and the bill date is the date the transactions appeared on a statement or invoice.

Payments also have a reference date and post date, which normally indicates the date the payment was received. This additional information is sometimes helpful if a billing occurred between the time the payment was received and the time it was entered into the system.

Some organizations need only record the date of the transaction.

A further date period assignment is needed. A term code is assigned to each transaction and represents a user-defined date range. In an academic environment, often the term code represents a date period defined by the registrar (e.g., FA88-Fall 1988, SP89-Spring 1989, FY92-Fiscal Year 92, etc.). A major benefit gained by the term code is the ability to find transactions for a particular term regardless of the date the charge occurred, or payment was made.

Account Categories

The AR system also maintains information that pertains to each account ID and not to any one transaction. There may be up to six individual account categories. For example, one category might be titled TYPE with possible values of Student, Faculty, or Staff. Another example might be a category titled PAYP for a payment plan with possible values of 10 Month, 3 Month, NONE, etc. The six account categories and their respective values may be changed, but allow for only one value per account ID.

In addition, there are six account term categories that pertain to an account ID for a given term code. The categories may be used for attaching values to account IDs that change from term to term. For example, CLAS might be an account term category with possible values of FRES or SOPH that would pertain to an account ID and may or may not change each term. Defaults can be assigned for each account term category, based on the value from the prior term or from defaults defined for the term. The account term category codes are helpful when defining late charges and/or deferred charges. The codes allow specific plans or charges to be assigned to large groups of PE IDs.

Common Codes

Additional customizations to the AR system are controlled by common codes and default rules. AR controls the settings as discussed earlier, including a Finance Code, Payment Types and Account Status, within the ARUPCD page. Additional codes will be found within the Nucleus (NU) Common Codes (NUUPCD) page. One more source of control is the NU Default Rules (NUUPDF) page. XML and VBScript commands can be written here that will facilitate commands and the auto-population of desired fields.

AR Cheat Sheet