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 become 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 may not be necessary. Use of campus-specific should be avoided; 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 created receipt. 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.

Entries are made by specifying a transaction code, campus, description (which defaults to a description of the transaction code but can be changed as needed), a debit or credit amount, 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 and posted, 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 drawn 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 awards.

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 to describe each possible Fee and Rate in terms of:

• Amount
• How charged (per-credit, per-course, flat rate)
• Transaction code used to record the charge on accounts
• How or if refunded

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

The following example illustrates how tuition remission can be configured:

For a student with a rate of DEPEND, the standard $95.00 per credit tuition would be assessed (no TUITION row with the DEPEND rate exists, so the default row with no specified rate code is used). A tuition remission would also be calculated to credit $95.00 per credit hour, with a limit of <$570.00>.

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 rarely occur, so the form allows copying fees from a prior term to avoid having to re-create similar information each term.

Assessment

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

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 calculated 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. Which method is more appropriate depends on the task needing performed. 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.

It's important to note that changes in information that affect a student's fee assessment are not automatically recorded on the student's account. One of the methods described above must be used to review and apply changes to the account.

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. The Check Batch form allows specific refund requests to be deleted from batches before they are printed, or new requests to 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, by campus, details for each check and a signature line to record who collected it.

Check Reconciliation

The check printing processes on the Check Batch form maintain a register of checks for reconciliation with bank statements. Checks that are printed are added to the register, while voiding checks marks the original check as cleared and records the void itself.

The Check Reconcile form can be used to mark checks as cleared. A report of outstanding checks is available from this form, and can be used to print a range of checks by check number or date, or all outstanding checks.

Distribution

The mapping of Transaction codes to MIP COA segments is managed on the Distribution form. Each transaction code must have an asset and revenue account specified (as a combination of the MIP COA segments Fund, Campus, Division, GL, and Performance codes) for each Campus used in the database. (Note that the MIP COA Campus is not the same as student Campus.) Any missing distribution information will prevent feeds from being generated.

When producing a feed, an exported account debits the asset account and credits the revenue account, based on the Transaction and Campus codes in the account entry. Payments (the internal records that balance debit and credit entries on each account) connect two separate account entries; the debit and credit use the asset accounts accounts if the transaction represents a debit, and revenue accounts when transactions represent a credit.

A single journal voucher will never be based on a mix of account entries and payments. This improves the ability to refer back to individual transactions or payments when needed.

Document Numbers

Each export (or "feed") is assigned a unique SessionID with the format "SISYYYMMDD-nn" where YYYYMMDD is the year, month, and date of the export, and nn is a sequence (beginning at 01) identifying individuals feeds made on the same day.

Within each SessionID, journal vouchers are created based on account entries or payments. Journal vouchers are labeled "JVYY-nn" with a two-digit year and a sequence number nn.

Exporting

The exports are created as CSV files for direct import into MIP. The MIP Feed form is used to generate the exports.

All cleared cashiering sessions that need released to MIP are listed in the Unreleased or Unfed Sessions block. To create a new feed, cashiering sessions for the feed must first be released by setting their Release indicator and submitting that change. With the Session ID field empty, clicking on Generate will produce a feed for all released and unfed cashiering sessions. These steps can be repeated as necessary to produce multiple feeds. Released and fed sessions will remain listed on the form until it is reset, but they will only be included in a single feed.

Although a single feed can include transactions from a large number of cashiering sessions, combining too many can make reconciliation more difficult, and it may be desirable to feed some sessions (such as those used to perform fee assessment) separately, not combining them with other sessions.

If an export needs re-created, it's Session ID can be entered in the Session ID field and Generate clicked. The export file will be generated again.

All export files are produced with the same name, SIStrans.CSV, to prevent the MIP import definition file from needing modified repeatedly.

Review

The Feed Review report can be used to review, in detail, the transactions that were used to produce a feed, or a specific document within a feed. It uses SessionID and JV document number, and displays each transaction (with ID, name, transaction, campus, and description) used to create each document.