Wiley Practitioner's Guide to GAAS 2020. Joanne M. Flood

communication and understanding. In conducting your group discussion, you will bring together people in the company who may not interact on a regular basis, and you will engage them in a discussion about operating procedures and controls. By participating in this process, employees will gain a greater understanding of their responsibilities and how these fit into the larger picture. This improved understanding among employees will allow your project to provide value to the company that goes beyond mere compliance.

      To conduct a group discussion, follow these five steps:

      1 Review the documentation of the processing stream and determine who should be invited to participate. Groups of five to ten people usually work best—everyone can make a meaningful contribution to the conversation without things getting out of hand. Try to make sure that someone is present who has experience with every process, control, document, or electronic file described in your documentation of the processing stream.

      2 Prepare a flowchart of the process on a large sheet of paper. Use sticky notes to document processes and control points. Your group discussion will be highly interactive, and the participants will have the opportunity to change your original flowchart to provide a more accurate description of what really happens in the process. Therefore, you should prepare your flowchart in a way that allows the group to work with it easily. Low-tech, high-touch works best.

      3 Assemble the group and explain:The purpose of the discussion, as described previously.The process, in which you will facilitate a discussion of how the process really works and the participants will be free to describe what happens by modifying the flowchart.How long the discussion will take. Usually, one to two hours is the longest that group discussion of this nature can remain productive. If you need more time, it is better to have more sessions rather than have longer sessions.

      4 Post the flowchart on the wall, and walk the participants through your understanding of the process.

      5 Facilitate a discussion among the participants. Be sure to:Reach an understanding about what should happen.Identify those instances in which exceptions exist (what really happens).

      Throughout the discussion, encourage the participants to change the flowchart as necessary so that it reflects what they have said.

      Tests of Transactions

      Some control procedures allow you to select a sample of transactions that were recorded during the period and:

       Examine the documentation indicating that the control procedure was performed.

       Reperform the procedure to determine that the control was performed properly. For example, the process for recording inventory purchases may require physically matching a paper-based warehouse receiving report with an approved purchase order.

       Determine that the purchase order was properly approved, as indicated by a signature.

       Determine that the vendor is an approved vendor.

       Observe evidence (e.g., checkmarks, initials) that warehouse personnel counted the goods received.

      To test the effectiveness of this control procedure, you could:

       Examine documentation that the control was performed, including:Documents were matched.Purchase order was signed.Receiving report was marked.

       Determine that the control was performed properly, including:Purchase order and receiving report are for the same transaction.Vendor is an approved vendor.Signer of the purchase order has the authority to approve the transaction.

      Computer application controls also may lend themselves to similar testing techniques. For example, suppose that purchased goods are accompanied by a bar code that identifies the goods received and their quantities. The bar code is scanned, and the information is matched electronically to purchase order files and approved vendor master files. Unmatched transactions are placed in a suspense file for subsequent follow-up. (As indicated previously, the computer application control consists of both the programmed elements of the control and the manual follow-up of identified errors.) To test the effectiveness of this control, you could:

       Prepare a file of test transactions and run through the system to determine that all errors are identified.

       Review the resolution of the suspense account items performed throughout the period to determine that they were resolved properly.

      When performing tests of transactions, you will have to address issues related to the extent of testing: how many items to test. Suggestions for considering the extent of tests were provided earlier in this chapter.

      Before performing your tests of transactions, you also should define what you will consider a control procedure error. In instances in which the evidence of performing the procedure is documented (e.g., an initial or a signature), the lack of documentation (a missing signature) should be considered an error in the operation of the control. That is, in order for a documented control to be considered properly performed, both these points must be true:

       The documentation indicates that the control procedure was performed.

       Your reperformance of the procedure indicates it was performed properly.

      Reconciliations

      Reconciliations are a common control procedure; examples are bank reconciliations or the reconciliation of the general ledger account total to a subsidiary ledger. In some instances, a well- designed reconciliation can provide an effective control over most of a processing stream. Testing the effectiveness of a reconciliation is similar to tests of transactions.

       Review documentation that the test was performed on a timely basis throughout the period.

       Reperform the test to determine that all reconciling items were identified properly.

       Investigate the resolution of significant reconciling items.

      Observation

      You may be able to observe the application of some control procedures, such as computer input controls like edit checks. A physical inventory count also lends itself to observation as a means of assessing effectiveness. For a control performed only occasionally, such as a physical count, it may be possible to observe the control each time it is performed. For controls that are performed continuously for large volumes of transactions, you will need to supplement your observations with other tests, such as:

       Inquiry

       Test of entity-level controls

Evaluating Test Results

      The results of your tests of activity-level controls should support your conclusion about their operating effectiveness. If your tests revealed no deviations or exceptions in the performance of control procedures, then you should be able to conclude that the control is operating effectively (assuming that the scope of your test work, as discussed earlier in this chapter, was sufficient).

      When your tests of operating effectiveness uncover exceptions to the company’s prescribed control procedures, you should determine whether additional tests are required to assess operating effectiveness. A control testing exception is not necessarily a control deficiency. You may determine that the exception was an isolated instance of noncompliance with the established control procedure. However, if you do conclude that a testing exception is not a control deficiency, then you should perform and document additional test work to support your conclusion. In most instances, control testing exceptions usually are not considered to be isolated instances of noncompliance.

      For example, when your test work reveals deficiencies in either the design or the operating effectiveness of a control procedure, you will need to exercise your judgment in order to reach a conclusion about