2.0 Approach to Monthly Review


2. Approach to Monthly Review

The approach to monthly review aims to use MIT staff time most effectively, by allowing lower risk transactions to be monitored by SAP electronic controls and MIT central offices (thus eliminating some duplication of effort) and by reducing the need for retaining paper documentation.

Who performs the Review?

As part of its overall system of internal controls, MIT requires that a person familiar with activity on an MIT cost object review the monthly transactions on that cost object. The transaction review helps to ensure that cost object expenses and revenues are accurate, timely, complete, and properly documented.

Some DLCs are highly centralized, and reviews take place in a central group. Most DLCs are more decentralized, and reviews are done both in the headquarters area and by the administrative staff supporting a faculty member or a research group. In either case, numerous individuals may participate in the monthly review.

When should the Review take place?

The review should be completed within 30 days of the end of the month under review. Federal regulations limit the time allowed for transfers from one cost object to another, and errors caught promptly are generally much easier to correct. Therefore, a timely review is strongly recommended.

Monthly Review Basics

The approach to monthly review is risk based. Matching to independent supporting documentation is advisable in some cases, but not needed in others. Some examples of when (and when not) to match are described below.

For more detailed guidelines by transaction type, including an assessment of level of risk, see section 3 "Specific Guidelines by Transaction Type".

The guidelines recommend that, for some transaction types, transactions be matched to supporting documentation " on a test basis". This means that reviewers perform the most detailed review where the risk of error or loss is greatest, and a reduced level of review when the risk of error or loss is less.

The monthly review procedures require the retention of paper backup, encourage the use of electronic tools, and describe the signoff form.

Some examples of when (and when not) to "match" to supporting documentation

In some cases the best way to verify that a transaction is correct is to review the supporting documentation for the transaction. Supporting documentation should be reviewed in the following situations:

  • When the reviewer has questions about a transaction.
  • When more information is needed to determine that the charge is accurate and correctly coded.
  • Whenever the charge, on its surface, appears unusual or inappropriate in any way.

In many cases, however, matching to supporting documentation is not a necessary part of the month-end review process. For example, matching is not required in the following four cases:

  1. When the "matching" of transactions has already been done before the monthly statement and DTR are completed, and there are system controls in place to minimize amount and cost object/G/L account distribution errors. Examples include regular payroll transactions and non-blanket POs over $3,000.
  2. When full documentation is available as part of the transaction itself (as in the case of a journal voucher) and may be reviewed on-line or in the printed statement
  3. When the transaction is small in dollars and processed in a well-controlled manner (for example, bar coded mail, or phone calls from telephones not in public areas, where telephone policies are disseminated and well understood by staff).
  4. When the transaction results from a well-controlled system, such as the SAP Purchasing system, and the charge appears reasonable and recognizable.

What is "on a Test Basis?"

When the controls are strong, and the reviewer's experience shows that vendor billings are accurate and packing slips are consistently maintained and filed, these guidelines recommend that matching to supporting documentation be done "on a test basis". The reviewer should consider a number of factors in deciding how many transactions to test.

A selection of one in ten transactions is a reasonable place to start. If there are ten or fewer of a particular transaction type, one or two should still be selected for review. If problems are found, more transactions should be selected for testing. If no problems are found, fewer transactions can be selected.

If the reviewer is aware of problems with a particular vendor, or a particular area of the organization, or if the reviewer does not have experience with the spending on the cost object, more transactions should be matched to supporting documentation.

Reviewers will often focus on large dollar amount transactions, as errors in these will have the greatest impact on the cost object; but some small dollar transactions should be selected as well.

What Documents to Retain?

The DLC is the "office of record" for certain documents, and must retain them. Original documents that DLCs should retain include packing slips, credit card receipts, signed DACCAs, and original signed time cards (as needed to meet legacy system verification plus copies of any eDACCAs that support certification by proxy in SAP).

The time frames for document retention are the current FY plus four additional FYs (for packing slips, credit card receipts, and signed DACCAs) and current FY plus one additional FY (for original signed time cards). For more details by transaction type, see Section 3 - "Specific Guidelines by Transaction Type".

For other documents, an MIT central office is the "office of record". In that case, the DLC is not required to retain document copies, although it can, if it is useful to do so.

Pending Folders

Some DLCs elect to keep a "pending folder", to hold copies of invoices, travel vouchers, and RFPs submitted to the VPF for payment. This folder may also include other non-SAP documents, such as packing slips. The purpose of keeping a pending folder should be to verify that a transaction has been processed (at the authorized amount and to the correct cost object and GL account).

The FRC guidelines do not require use of a pending folder. DLCs that elect to use one should review items in the pending folder monthly and file or dispose of documentation on posted items according to DLC business practice.

Monthly Review Signoff Form

When the monthly review is complete, the reviewer should signoff on the review process. The form of documentation can vary, but must include, at minimum, a list of the cost objects reviewed, the transaction types (if not all were reviewed by the same person), the month being reviewed, and the date completed.

The purpose is to document that a monthly review was performed in accordance with the guidelines.

Two examples of signoff forms ( paper form; BrioQuery template, look for Signoff Form) are provided as Appendix C. The signoff form should be signed and retained on paper. The form should be kept for the current fiscal year plus the four additional fiscal years.

Unresolved Problems

Documentation of unresolved problems should be kept on or with the signoff form. Contacts for resolving problems for each transaction type can be found in Part 3, "Specific Guidelines by Transaction Type".

Reporting Significant Problems and Issues

The risk-based guidelines are based on the effectiveness of internal controls provided by MIT central offices and electronic systems (in particular SAP). Significant or recurring problems or issues should be documented and communicated to the appropriate office.

For information on whom to contact by transaction type, see section 3 on " Specific Guidelines by Transaction Type". Other systemic problems and errors relating to central areas should be reported to the Office of the Controller.

Responsibility for Review

The Administrative Officer, in association with the head of the DLC, is ultimately responsible for making sure that all active cost objects are reviewed in accordance with these guidelines.

Updated 5/22/12