COM-FSM > SIS Documentation > Guides > Accounts Receivable

Accounts Receivable

Page last modified 01:22, 4 May 2009 by kgirrard


    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.

    The following example illustrates how tuition remission can be configured:

    depend.pngFor 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.


    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 to balance with a cash box or perform other verification of the entries made. Adjustments to closed sessions can only be made using the Adjustment form, and are made as offsetting account entries.
    • Cleared - Sessions that have been verified or balances should 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 session's 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 provides a report of all 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 receipts and thier corresponding account entries, and a listing of all 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 necessary or reasonable to close and clear them daily. Conversely, 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 sessions is maintained and accessible on the Session Review form. It provides the same information and reports for cleared sessions as that which is show on the Open Sessions form.

    MIP Interface

    An interface between accounts receivable and an external accounting system, MIP Fund Accounting, allows exporting summary data based on account entries as journal vouchers that can be imported into the general ledger. The interface provides a mapping of Transaction codes to MIP account, a process to generate data files that can be imported into MIP, and a report to examine the receivables entries that generated each export.


    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.


    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.


    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.

    Powered by MindTouch Core