Accounts Receivable

Page last modified 00:59, 4 Oct 2008 by Admin

    Version as of 05:16, 9 Mar 2021

    to this version.

    Return to Version archive.

    View current version


    Accounts exist for anyone with a Name and ID. Accounts are maintained as register-style lists of entries, a design intended to simplify data entry and maximize clarity for students when reviewing their account details.

    Designed for integration with student information, entries on accounts are organized by term in the same fashion that most student-related data is term-based. Similarly, all account entries also include campus, typically based on the campus where a student is enrolled.

    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.


    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.


    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.

    Fee Assessment

    Most account activity is related to students, such as their tuition and fees related to attending college. Those costs are determined by information such as what type of student they are and how many classes they're taking. Fee assessment combines the variety of information available in the student database with a definition of tuition, fees, and other charges to determine what each student owes each term.

    Information is collected from the Course Catalog (course fees), Student records (what rate the student should be charged at, whether they are staying in the dorms, what meal plan they have selected), and Registration (what courses they have enrolled in, and for how many credits).

    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.

    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.


    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.


    Credit balances on student accounts can be refunded as cash, or as a refund check. Refund check requests can come from multiple sources, but all are processed through the Check Batch form.

    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).


    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.


    As users create entries on accounts those entries are organized in groups, or "sessions." A session represents a set of entries made over some period of time by a specific user (referred to as the cashier), and facilitates verification, adjustment, and control over the movement of data to an external accounting system.

    Cashiering sessions move predictably between the following states:

    • Open - Each cashier has exactly one open session. All account entries by the same cashier are added to their current, open session. If a cashier doesn't have an open session, one is automatically created when needed.
    • Closed - Sessions are marked closed to prevent new entries from being added. This fixes the session contents to allow the cashier needs to balance a cash box, or perform some other verification of the entries made. Adjustments to closed sessions can be entered using the Adjustment form.
    • Cleared - Sessions that have been verified or balance can then be cleared. This makes the session eligible for export to an external accounting system, and also triggers the application of payments process for the sessions account entries.
    • Released - The session can be exported to an external accounting system only when it has been released. This allows for control over which sessions are combined into journal vouchers produced by the exporting process.

    Changes to session status are permanent. It is not possible to re-open or un-clear a cashiering session.

    The status of each session is managed on the Open Sessions form, which includes a report of transactions that are part of a session. The report can display all transactions, by account, if Show account detail is checked. The report always includes a summary of transactions by campus, a list of entries with a receipt number, and any refund checks that are part of a session.

    The schedule used to manage cashiering sessions should be based on operational needs. For sessions not handling  cash, it may not be reasonable to close and clear them daily. Quickly closing large sessions resulting from specific tasks such as fee assessment may allow for more transparent reconcilation with external accounting systems.

    The Open Sessions form lists all sessions that have not been cleared, but a permanent record of all session is maintained. It's accessible on the Session Review form, which provides the same information and reports for cleared sessions.

    MIP Interface


    Powered by MindTouch Core