General University Reference Utility
To provide guidance for compliance with Policy FN01.
It is important to comprehend that Policy FN01 recognizes the documentation of a transaction as two separate but related functions:
1. THE UNIVERSITY MUST POSSESS A RECORD OF THE TRANSACTION-
The primary reasons for this requirement are to capture information necessary.....
- for determining what University budget/fund is to receive credit for the revenue
- for use in updating a department's internal customer records and management reports
- for supporting sales tax and similar collections and remittances
- for reconciling to the actual cash count at the conclusion of a business day
- for problem resolution, should a future question occur related to the transaction
- for updating inventory records as appropriate
As long as the documentation of a transaction captures the information indicated in Policy FN01 AND is protected so that it cannot be easily misplaced or modified without possible detection and it is readily retrievable, documentation may be hand-written, printed, or electronically or optically stored. This allows for the use of a wide variety of methods for recording a transaction including, but not limited to, cash registers, prenumbered receipt books, transaction logs, point-of-sale terminals, registration forms, and computer systems.
It should be noted that the documentation used to meet this requirement of the University possessing a record of the transaction does not necessarily have to be the same media as the acknowledgement that is given to the person paying. For example, a Center for the Performing Arts transaction may be recorded on a computer's hard disk, but the person paying receives tickets as the acknowledgement of the transaction.
There are two major risks faced by the University when revenue is accepted and the record of the transaction is not properly recorded, controlled and safeguarded. First, the loss of the information can result in additional work by the department participating in the transaction, and can reflect poorly upon the department and the University. For example, sound business practice dictates that the revenue-on-hand be reconciled to the records of transactions at the conclusion of each business day. If a transaction is not recorded or is lost, a successful reconciliation obviously will not occur and time will be spent trying the resolve the imbalance. If a record of a transaction does not exist, inventory records or a customer's account may not be updated. Second, the recording of a transaction may be purposely avoided or destroyed in an attempt to cover up misappropriation of funds. If an individual removes both the record of a transaction and the revenue pertaining to that transaction, then a reconciliation between the revenue-on-hand and the transactions documentation for the day may balance although funds are missing.
It is in response to these two risks that Policy FN01 calls for the control of transaction documentation. While it may not be cost-effective and possible to totally prevent misappropriation, controls should exist to make lost transaction records less likely, and if they occur, easier to detect. This was the premise behind the use of a prenumbered receipt. Since prenumbered receipts are to be issued in a consecutive manner, a missing receipt would be detectable as a missing number in the numeric series. Cash registers afford a similar control in that transactions are recorded on the control tape. In order to remove a transaction, the transaction would physically have to be cut from the control tape.
It should be noted that Policy FN01 indicates that a record of a transaction "must be generated by the individual initially accepting the revenue on behalf of the University." Once the revenue has been initially accepted by the University, no duplicate records of the transaction should be generated. For example, if a department has an office on one side of the campus that receives revenue and records transactions, then transfers the revenue to its business office at the end of the day for deposit, a University receipt must not also be issued by the business office to indicate acceptance of the revenue. This is merely a transfer of revenue within the University that should be documented by an Accountability Transfer Form or other suitable transfer log or document. There should be only one official receipt/record per transaction and the total of the recorded amounts of the transactions must reconcile to the associated revenue collected and the related Report of Cash Receipts.
Credit card transaction slips may be a suitable record of transaction if they meet the criteria delineated in Policy FN01. In operations where a cash register or other means of recording transactions are considered the primary means, credit card transaction slips become supporting documentation, and therefore are not in conflict with the "one record per transaction" rule. Each area should clearly establish what documentation will be considered the "record of transaction" and what will be deemed support.
Each area's Financial Officer has the responsibility for determining the adequacy of documentation and local procedures.
2. THE PERSON (OR ORGANIZATION) PAYING MUST RECEIVE AN ACKNOWLEDGEMENT THAT THE REVENUE WAS RECEIVED BY THE UNIVERSITY:
The primary reasons for this requirement are:
- to provide the person paying with feedback that the University recognizes that the payment was made,
- as a courtesy to provide the person paying with a convenient proof of payment should the transaction need follow-up (e.g., the payment not properly being credited to person's account, the goods or services needing an adjustment or a refund, etc.). Refund Policy FN08 requires evidence of the original transaction, and
- returns of merchandise.
This requirement applies regardless of the form of payment. A cancelled check by itself does not constitute a sufficient acknowledgement since it does not provide the required information specified by Policy FN01, Also, money orders and traveler's checks do not get returned to the person paying, once they are cancelled.
The concept of an acknowledgement is broader than the definition of a receipt. In fact, a receipt is defined as "the written acknowledgement of payment received." Payments made in person will most commonly result in a cash register receipt or a prenumbered receipt being issued to the person paying. Acknowledgements to persons paying by mail may seem less obvious. For example, registration by mail for a University seminar should result in an enrollment confirmation being sent to the person paying. A mail order for something offered from the Alumni Association should result in a packing list/statement being sent along with the goods to the person paying; and payments to a student's account should be reflected in the next account statement. Therefore, documentation which may not normally be termed a "receipt" may nonetheless qualify as an acknowledgement.
The processing of revenue is comprised of three main functions: collection/recording of the revenue; depositing the money; and reporting/reconciliation of revenue with the record of the transactions. Ideally, each function should be performed by a different individual. If at all possible, employees responsible for these functions should be rotated periodically without prior announcement. If staff is limited to two individuals to perform the processing functions, the individual collecting the revenue and recording the transactions should also deposit the revenue. The second individual should perform the reporting/reconciliation of revenue with the record of the transactions and process the Report of Cash Receipts (ROCR) . At no time may one individual have control over the entire process.
For questions, additional detail, or to request changes to this policy, please contact the Office of the Corporate Controller.
Effective Date: September 19, 1994 (Reviewed 07-26-16, with no changes)
Date Approved: September 19, 1994
Date Published: September 19, 1994 (Reviewed 07-26-16, with no changes)
Most Recent Changes:
Revision History (and effective dates):