Accounts Receivable

Transaction Codes

Each account entry includes a Transaction code that identifies that nature of a debit or credit, such as tuition, course fees, a financial aid award, or a cash payment. Each transaction code is defined with attributes such as whether it typically represents a debit or credit, or if it represents financial aid. The relationship between transaction codes and an external accounting structure is also defined, conveniently isolating those details from account entries.

Transaction codes can be created as needed to represent various types of account entries. Decisions on how specific each code needs to be should seek a balance between the varying needs of business office staff (too many codes are difficult to remember), the value of distinguishing specific types of debits or credits (for reporting or analysis), and the external accounts associated with transactions (whether codes share the same external account structure). If revenue from all course fees is collected in a single external account, for example, having multiple transaction codes for each course probably isn't necessary. Campus-specific codes are not required; all account entries are recorded with campus, and the external accounting interface combines transaction code and campus to identify a specific account.

Accounts

Two forms are available for managing accounts. The Account form shows all entries on an account, while the Account by Term form displays entries for a specific term and is useful when reviewing only current term activity. Account by Term also has support for requesting a refund of a credit balance, or printing of the most recently assigned receipt number. Both forms show entries in the order they were posted to the account (by sequence number, shown in the first column of data), and can produce printable account summaries, showing all entries or a single term's entries just as each form does.

Entires are made by specifying a transaction code, campus, description (which defaults to a description of the transaction code but may be changed as needed), a debit or credit, and an optional effective date. The remainder of the information is generated automatically when the entry is submitted. Effective Date will default to the current date if not specified. Once submitted, account entries cannot be altered.

Balances shown at the bottom of each form are separated into FA (financial aid) and Other. The FA balance includes all transcations that are financial aid sources (credits representing financial aid posted to the account) or financial aid eligible debits. The Other balance represents all other entries. This distinction is made because of limits on what types of debits financial aid can apply to; the student may have a balance that cannot be covered by their financial aid award.

Receipts

All account entries made with a transaction code representing a non-financial aid credit are assigned a receipt number. They are numbered sequentially by campus, and are displayed on all printed account summaries and on cashier detail reports.

If multiple entries on an account are made on the same day, by the same cashier, and using the same transaction code, they will be combined on a single receipt.

Term Fees

The college's fee structure is defined each term, describing each possible Fee and Rate in terms of:

• Amount
• How charged (per-credit, per-course, flat rate)
• Transaction code
• How or if refunded

For charges that have various rates, such as tuition, the Rate used is determined by either the Student record (which indicates if they are a regular student, or receive staff or other waiver), Registration Status (audit, for example, is charged at a different rate), or the Section rate.

Refunding can be controlled for each Fee, and supports non-refundable fees, refunds based on how much of the term has passed (percentages that change at specified intervals based on a Refund Schedule), or fixed daily amounts.

The Term Fees form is used to maintain this information each term. Significant changes to how fees are assessed are rare, so the form allows copying information from a prior term to save having to re-create similar information each term.

Assessment

Two methods of assessing and posting of student fees are available. The Fee Assessment form allows individual student's to have their assessment calculated, reviewed, and posted. A Batch Assess process is also available; it calculates and optionally posts fee assessments for all students, for a specified term and campus.

The form and batch process both calculate an assessment based on current information in each student's record, and a summary of current charges on each student's account. The difference between the assessment and current charges is displayed as the "change" in assessment. The form can create new entries on an account based on these changes (allowing them to be reviewed before they are posted), while the batch process can either report the changes or apply them to accounts automatically, based on how the report is run.

Both methods use the exact same method for calculating fees, but which one is more appropriate depends on needs. The Batch Assess process is useful, for example, to locate accounts that need re-assessed due to a change in registration. The Fee Assessment form is more useful when dealing with the needs of specific students, or exceptions that need managed by hand.

Financial Aid

Any posting of financial aid to a student account will generate a request for a refund check, regardless of the balance on the student's account. When awards are posted using the Award Batch form, all of the refund requests are made when the batch is released (at the same time the awards are posted to student accounts).

Accounts

The Account by Term form contains a button (labeled "Refund") that can be used to request a refund. When clicked, if the account has a credit balance, a refund request will be generated, creating or modifying a check batch.

Check Batches

Refund check requests are organized into batches based on the user requesting a refund. A check batch that is waiting to be printed will have additional requests added to it if the same user makes additional requests. Note that the refunds in a batch are term-specific, so it's possible to have multiple requests for the same account in the same batch.

If an account with a pending refund check doesn't have a credit balance, no check will be generated. Specific refund requests can be deleted from batches before they are printed, or new requests can be added. Each request must have an ID, term, and campus.

Batches are marked "complete" when all of the listed accounts have either had a check printed, or don't have a credit balance. When the batch is "complete" can you generate a check register; this report lists each check with a signature line to record who collected it, organized by campus.