INTRODUCTION TO TRANSACTION PROCESSING:THE AUDIT TRAIL

THE AUDIT TRAIL

The accounting records described previously provide an audit trail for tracing transactions from source documents to the financial statements. Of the many purposes of the audit trail, most important to accountants is the year-end audit. Although the study of financial auditing falls outside the scope of this text, the following thumbnail sketch of the audit process will demonstrate the importance of the audit trail.

The external auditor periodically evaluates the financial statements of publicly held business organizations on behalf of its stockholders and other interested parties. The auditor’s responsibility involves, in part, the review of selected accounts and transactions to determine their validity, accuracy, and complete- ness. Let’s assume an auditor wishes to verify the accuracy of a client’s AR as published in its annual financial statements. The auditor can trace the AR figure on the balance sheet to the general ledger AR control account. This balance can then be reconciled with the total for the accounts receivable subsidiary ledger. Rather than examining every transaction that affected the AR account, the auditor will use a sam- pling technique to examine a representative subset of transactions. Following this approach, the auditor can select a number of accounts from the AR subsidiary ledger and trace these back to the sales journal. From the sales journal, the auditor can identify the specific source documents that initiated the transactions and pull them from the files to verify their validity and accuracy.

The audit of AR often includes a procedure called confirmation. This involves contacting selected customers to determine if the transactions recorded in the accounts actually took place and that customers agree with the recorded balance. Information contained in source documents and subsidiary accounts enables the auditor to identify and locate customers chosen for confirmation. The results from

reconciling the AR subsidiary ledger with the control account and from confirming customers’ accounts help the auditor form an opinion about the accuracy of accounts receivable as reported on the balance sheet. The auditor performs similar tests on all of the client firm’s major accounts and transactions to arrive at an overall opinion about the fair presentation of the financial statement. The audit trail plays an important role in this process.

COMPUTER-BASED SYSTEMS

Types of Files

Audit trails in computer-based systems are less observable than in traditional manual systems, but they still exist. Accounting records in computer-based systems are represented by four different types of magnetic files: master files, transaction files, reference files, and archive files. Figure 2-11 illustrates the relationship of these files in forming an audit trail.

MASTER FILE. A master file generally contains account data. The general ledger and subsidiary ledgers are examples of master files. Data values in master files are updated from transactions.

TRANSACTION FILE. A transaction file is a temporary file of transaction records used to change or update data in a master file. Sales orders, inventory receipts, and cash receipts are examples of transaction files.

REFERENCE FILE. A reference file stores data that are used as standards for processing transactions. For example, the payroll program may refer to a tax table to calculate the proper amount of withholding taxes for payroll transactions. Other reference files include price lists used for preparing customer in- voices, lists of authorized suppliers, employee rosters, and customer credit files for approving credit sales. The reference file in Figure 2-11 is a credit file.

ARCHIVE FILE. An archive file contains records of past transactions that are retained for future reference. These transactions form an important part of the audit trail. Archive files include journals, prior- period payroll information, lists of former employees, records of accounts written off, and prior-period ledgers.

The Digital Audit Trail

Let’s walk through the system represented in Figure 2-11 to illustrate how computer files provide an audit trail. We begin with the capture of the economic event. In this example, sales are recorded manually on source documents, just as in the manual system. The next step in this process is to convert the source documents to digital form. This is done in the data-input stage, when the transactions are edited and a transaction file of sales orders is produced. Some computer systems do not use physical source documents. Instead, transactions are captured directly on digital media.

The next step is to update the various master file subsidiary and control accounts that the transaction affects. During the update procedure, additional editing of transactions takes place. Some transactions may prove to be in error or invalid for such reasons as incorrect account numbers, insufficient quantities on hand, or customer credit problems. In this example, the system determines the available credit for each customer from the credit file before processing the sale. Any records that are rejected for credit problems are transferred to the error file. The remaining good records are used to update the master files. Only these transactions are added to the archive file that serves as the sales journal. By copying the valid transactions to the journal, the original transaction file is not needed for audit trail purposes. This file can now be erased (scratched) in preparation for the next batch of sales orders.

Like the paper trail, this digital audit trail allows transaction tracing. Again, an auditor attempting to evaluate the accuracy of the AR figure published in the balance sheet could do so via the following steps, which are identified in Figure 2-11.

1. Compare the accounts receivable balance in the balance sheet with the master file AR control account balance.

2. Reconcile the AR control figure with the AR subsidiary account total.

3. Select a sample of update entries made to accounts in the AR subsidiary ledger and trace these to transactions in the sales journal (archive file).

4. From these journal entries, identify specific source documents that can be pulled from their files and verified. If necessary, the auditor can confirm the accuracy and propriety of these source documents by contacting the customers in question.

Documentation Techniques

The old saying that a picture is worth a thousand words is very applicable when it comes to documenting systems. A written description of a system can be wordy and difficult to follow. Experience has shown that a visual image can convey vital system information more effectively and efficiently than words. Accountants use system documentation routinely, as both systems designers and auditors, The ability to document systems in graphic form is thus an important skill for accountants to master. Five basic docu- mentation techniques are introduced in this section: data flow diagrams, entity relationship diagrams, sys- tem flowcharts, program flowcharts, and record layout diagrams.

DATA FLOW DIAGRAMS AND ENTITY RELATIONSHIP DIAGRAMS

Two commonly used systems design and documentation techniques are the entity relationship diagram and the data flow diagram. This section introduces the principal features of these techniques, illustrates their use, and shows how they are related.

Data Flow Diagrams

The data flow diagram (DFD) uses symbols to represent the entities, processes, data flows, and data stores that pertain to a system. Figure 2-12 presents the symbol set most commonly used. DFDs are used to represent systems at different levels of detail from very general to highly detailed. In Chapter 14, we will study the construction of multilevel DFDs. At this point, a single-level DFD is sufficient to demonstrate its use as a documentation tool. We see an example of this in Figure 2-13.

Entities in a DFD are external objects at the boundary of the system being modeled. They represent sources of and destinations for data. Entities may be other interacting systems or functions, or they may

be external to the organization. Entities should always be labeled as nouns on a DFD, such as customer or supplier. Data stores represent the accounting records used in each process, and labeled arrows represent the data flows between processes, data stores, and entities.

Processes in the DFD should be labeled with a descriptive verb such as Ship Goods, Update Records, or Receive Customer Order. Process objects should not be represented as nouns like Warehouse, AR Dept., or Sales Dept. The labeled arrows connecting the process objects represent flows of data such as Sales Order, Invoice, or Shipping Notice. Each data flow label should be unique—the same label should not be attached to two different flow lines in the same DFD. When data flow into a process and out again (to another process), they have, in some way, been changed. This is true even if the data have not been physically altered. For example, consider the Approve Sales process in Figure 2-13, where Sales Order is examined for completeness before being processed further. It flows into the process as Sales Order and out of it as Approved Sales Order.

Systems analysts use DFDs extensively to represent the logical elements of the system. This technique does not, however, depict the physical system. In other words, DFDs show what logical tasks are being done, but not how they are done or who (or what) is performing them. For example, the DFD does not show whether the sales approval process is separated physically from the billing process in compliance with internal control objectives.

Entity Relationship Diagrams

An entity relationship (ER) diagram is a documentation technique used to represent the relationship between entities. Entities are physical resources (automobiles, cash, or inventory), events (ordering

inventory, receiving cash, shipping goods), and agents (salesperson, customer, or vendor) about which the organization wishes to capture data. One common use for ER diagrams is to model an organization’s database, which we examine in detail in Chapter 9.

Figure 2-14 shows the symbol set used in an ER diagram. The square symbol represents entities in the system. The labeled connecting line represents the nature of the relationship between two entities. The degree of the relationship, called cardinality, is the numeric mapping between entity instances. A relationship can be one-to-one (1:1), one-to-many (1:M), or many-to-many (M:M).2 If we think of entities in the ER diagram as files of records, cardinality is the maximum number of records in one file that are related to a single record in the other file and vice versa.

Cardinality reflects normal business rules as well as organizational policy. For instance, the 1:1 cardinality in the first example in Figure 2-14 suggests that each salesperson in the organization is assigned one automobile. If instead the organization’s policy were to assign a single automobile to one or more salespersons who share it, this policy would be reflected by a 1:M relationship. Similarly, the M:M

relationship between vendor and inventory in Figure 2-14 implies that the organization buys the same type of products from one or more vendors. A company policy to buy particular items from a single vendor would be reflected by a 1:M cardinality.

System designers identify entities and prepare a model of them, similar to the one presented in Figure 2-15. This data model is the blueprint for what ultimately will become the physical database. The data model presented in our example is not, however, sufficiently refined to be the plan for a workable data- base. Constructing a realistic data model is an advanced topic that involves understanding and applying techniques and rules that are beyond the scope of this chapter. We revisit this topic in Chapter 9, where it will be treated in sufficient detail to model and design a practical database.

Relationship between ER Diagrams and Data Flow Diagrams

DFDs and ER diagrams depict different aspects of the same system, but they are related and can be reconciled. A DFD is a model of system processes, and the ER diagram models the data used in or affected by

the system. The two diagrams are related through data; each data store in the DFD represents a corresponding data entity in the ER diagram. Figure 2-15 presents the ER diagram for the DFD in Figure 2-13.

SYSTEM FLOWCHARTS

A system flowchart is the graphical representation of the physical relationships among key elements of a system. These elements may include organizational departments, manual activities, computer programs, hard-copy accounting records (documents, journals, ledgers, and files), and digital records (reference files, transaction files, archive files, and master files).3 System flowcharts also describe the type of computer media being employed in the system, such as magnetic tape, magnetic disks, and terminals.

The flowcharting examples in the following sections illustrate techniques for representing both manual and computer-based accounting processes. We begin by documenting manual procedures. We will add computer elements to the system later.

Flowcharting Manual Activities

To demonstrate the flowcharting of manual activities, let’s assume that an auditor needs to flowchart a sales order system to evaluate its internal controls and procedures. The auditor will begin by interviewing individuals involved in the sales order process to determine what they do. This information will be cap- tured in a set of written facts similar to those below. Keep in mind that the purpose here is to demonstrate flowcharting. Thus, for clarity, the system facts are intentionally simplistic.

1. A clerk in the sales department receives a hard-copy customer order by mail and manually prepares four hard copies of a sales order.

2. The clerk sends Copy 1 of the sales order to the credit department for approval. The other three cop- ies and the original customer order are filed temporarily, pending credit approval.

3. The credit department clerk validates the customer’s order against hard-copy credit records kept in the credit department. The clerk signs Copy 1 to signify approval and returns it to the sales clerk.

4. When the sales clerk receives credit approval, he or she files Copy 1 and the customer order in the department. The clerk sends Copy 2 to the warehouse and Copies 3 and 4 to the shipping department.

5. The warehouse clerk picks the products from the shelves, records the transfer in the hard-copy stock records, and sends the products and Copy 2 to the shipping department.

6. The shipping department receives Copy 2 and the goods from the warehouse, attaches Copy 2 as a packing slip, and ships the goods to the customer. Finally, the clerk files Copies 3 and 4 in the ship- ping department.

Based on these facts, the auditor can create a flowchart of this partial system. It is important to note that flowcharting is as much an art form as it is a technical skill, giving the flowchart author a great deal of license. Nevertheless, the primary objective should be to provide an unambiguous description of the system. With this in mind, certain rules and conventions need to be observed:

1. The flowchart should be labeled to clearly identify the system that it represents.

2. The correct symbols should be used to represent the various entities in the system.

3. All symbols on the flowchart should be labeled.

4. Lines should have arrowheads to clearly show the process flow and sequence of events.

5. If complex processes need additional explanation for clarity, a text description should be included on the flowchart or in an attached document referenced by the flowchart.

LAY OUT THE PHYSICAL AREAS OF ACTIVITY. Remember that a flowchart reflects the physi- cal system, which is represented as vertical columns of events and actions separated by lines of demarca- tion. Generally, each of these areas of activity is a separate column with a heading. From the written system facts, we see that there are four distinct areas of activity: sales department, credit department, warehouse, and shipping department. The first step in preparing the flowchart is to lay out these areas of activity and label each of them. This step is illustrated in Figure 2-16.

TRANSCRIBE THE WRITTEN FACTS INTO VISUAL FORMAT. At this point we are ready to start visually representing the system facts. The symbols used for this purpose will be selected from the set presented in Figure 2-17. We begin with the first stated fact:

1. A clerk in the sales department receives a hard-copy customer order by mail and manually prepares four hard copies of a sales order.

Figure 2-18 illustrates how this fact could be represented. The customer is the source of the order, but is not part of the system. The oval object is typically used to convey a data source or destination that is separate from the system being flowcharted. The document symbol entering the sales department signifies

the hard-copy customer order and is labeled accordingly. The bucket-shaped symbol represents a manual process. In this case, the clerk in the sales department prepares four copies of the sales order. Notice that the clerk’s task, not the clerk, is depicted. The arrows between the objects show the direction of flow and the sequence of events.

By transcribing each fact in this way, we systematically construct a flowchart. See how the second and third facts restated below add to the flowchart in Figure 2-19.

2. The clerk sends Copy 1 of the sales order to the credit department for approval. The other three copies and the original customer order are filed temporarily, pending credit approval.

3. The credit department clerk validates the customer’s order against hard-copy credit records kept in the credit department. The clerk signs Copy 1 to signify approval and returns it to the sales clerk.

Two new symbols are introduced in this figure. First, the upside-down triangle symbol represents the temporary file mentioned in Fact 2. This is a physical file of paper documents such as a drawer in a filing cabinet or desk. Such files are typically arranged according to a specified order. To signify the filing sys- tem used, the file symbol will usually contain an ‘‘N’’ for numeric (invoice number), ‘‘C’’ for chronologi- cal (date), or ‘‘A’’ for alphabetic order (customer name). Secondly, the parallelogram shape represents the credit records mentioned in Fact 3. This symbol is used to depict many types of hard-copy accounting records, such as journals, subsidiary ledgers, general ledgers, and shipping logs.

Having laid these foundations, let’s now complete the flowchart by depicting the remaining facts.

4. When the sales clerk receives credit approval, he or she files Copy 1 and the customer order in the department. The clerk sends Copy 2 to the warehouse and Copies 3 and 4 to the shipping department.

5. The warehouse clerk picks the products from the shelves, records the transfer in the hard-copy stock records, and sends the products and Copy 2 to the shipping department.

6. The shipping department receives Copy 2 and the goods from the warehouse, attaches Copy 2 as a packing slip, and ships the goods to the customer. Finally, the clerk files Copies 3 and 4 in the ship- ping department.

The completed flowchart is presented in Figure 2-20. Notice the circular symbol labeled ‘‘A.’’ This is an on-page connector used to replace flow lines that otherwise would cause excessive clutter on the page. In this instance, the connector replaces the lines that signify the movement of Copies 3 and 4 from the sales department to the shipping department. Lines should be used whenever possible to promote clarity. Restricted use of connectors, however, can improve the readability of the flowchart.

Notice also that the physical products or goods mentioned in Facts 4 and 5 are not shown on the flow- chart. The document (Copy 2) that accompanies and controls the goods, however, is shown. Typically, a system flowchart shows only the flow of documents, not physical assets.

Finally, for visual clarity, system flowcharts show the processing of a single transaction only. You should keep in mind, however, that transactions usually pass through manual procedures in batches (groups). Before exploring documentation techniques further, we need to examine some important issues related to batch processing.

Batch Processing

Batch processing permits the efficient management of a large volume of transactions. A batch is a group of similar transactions (such as sales orders) that are accumulated over time and then processed together. Batch processing offers two general advantages. First, organizations improve operational efficiency by grouping together large numbers of transactions into batches and processing them as a unit of work rather than processing each event separately.

Second, batch processing provides control over the transaction process. The accuracy of the process is established by periodically reconciling the batch against the control figure. For example, assume that the total value of a batch of sales orders is $100,000. This number is recorded when the batch is first assembled and then recalculated at various points during its processing. If an error occurs during processing (for example, a sales order is lost), then the recalculated batch total will not equal the original batch total and the problem will be detected.

Both of these advantages have implications for designing batch systems. The first is that economies arederived by making transaction batches large as possible. The average transaction cost is thus reduced when the processing fixed cost associated with the batch is allocated across a large number of transactions.

The second implication is that finding an error in a very large batch may prove difficult. When a batch is small, error identification is much easier. In designing a batch system, the accountant should seek a balance between the economic advantage of large batches and the troubleshooting advantage of small batches. There is no magic number for the size of a batch. This decision is based on a number of operational, business, and economic factors. Among these are the volume of transactions, the competitiveness of the industry, the normal frequency of errors, the financial implications of an undetected error, and the costs of processing. Depending on these factors, a system might be designed to process many small batches throughout the day or an entire day’s activity as a single batch.

Flowcharting Computer Processes

We now examine flowcharting techniques to represent a system that employs both manual and computer processes. The symbol set used to construct this system flowchart will come from both Figure 2-17 and Figure 2-21. Again, our example is based on a sales order system with the following facts:

1. A clerk in the sales department receives a customer order by mail and enters the information into a computer terminal that is networked to a centralized computer program in the computer operations department. The original customer order is filed in the sales department.

Facts 2, 3, and 4 relate to activities that occur in the computer operations department.

2. A computer program edits the transactions, checks the customers’ credit by referencing a credit his- tory file, and produces a transaction file of sales orders.

3. The sales order transaction file is then processed by an update program that posts the transactions to corresponding records in AR and inventory files.

4. Finally, the update program produces three hard copies of the sales order. Copy 1 is sent to the warehouse, and Copies 2 and 3 are sent to the shipping department.

5. On receipt of Copy 1, the warehouse clerk picks the products from the shelves. Using Copy 1 and the ware- house personal computer (PC), the clerk records the inventory transfer in the digital stock records that are kept on the PC. Next, the clerk sends the physical inventory and Copy 1 to the shipping department.

6. The shipping department receives Copy 1 and the goods from the warehouse. The clerk reconciles the goods with Copies 1, 2, and 3 and attaches Copy 1 as a packing slip. Next, the clerk ships the goods (with Copy 1 attached) to the customer. Finally, the clerk records the shipment in the hard- copy shipping log and files Copies 2 and 3 in the shipping department.

LAY OUT THE PHYSICAL AREAS OF ACTIVITY. The flowcharting process begins by creating a template that depicts the areas of activity similar to the one shown in Figure 2-16. The only differences in this case are that this system has a computer operations department but does not have a credit department.

TRANSCRIBE THE WRITTEN FACTS INTO VISUAL FORMAT. As with the manual system example, the next step is to systematically transcribe the written facts into visual objects. Figure 2-22 illustrates how Facts 1, 2, and 3 translate visually.

The customer, customer order, and file symbols in this flowchart are the same as in the previous exam- ple. The sales clerk’s activity, however, is now automated, and the manual process symbol has been replaced with a computer terminal symbol. Also, because this is a data-input operation, the arrowhead on the flowchart line points in the direction of the edit and credit check program. If the terminal was also used to receive output (the facts do not specify such an operation), arrowheads would be on both ends of the line.

Recall that the emphasis in flowcharting is on the physical system. For example, the terminal used by the sales clerk to enter customer orders is physically located in the sales department, but the programs that process the transactions and the files that it uses and updates are stored in a separate computer operations department.

Notice how the flow line points from the credit history file to the edit program. This indicates that the file is read (referenced) but not changed (updated) by the program. In contrast, the interactions between the update program and the AR and inventory files are in the opposite direction. The relevant records in these files have been changed to reflect the transactions. The logic of a file update is explained later in the chapter.

Let’s now translate the remaining facts into visual symbols. Fact 4 states that the update program produces three hard-copy documents in the computer operations department, which are then distributed to the warehouse and shipping departments. The translation of this fact is illustrated in Figure 2-23.

Fact 5 states that the warehouse clerk updates the stock records on the department PC and then sends the physical inventory and Copy 1 to the shipping department. Notice on Figure 2-23 how this computer activity is represented. The warehouse PC is a stand-alone computer system that is not networked into the computer operations department like the terminal in the sales department. The PC, the stock record update program, and the stock records themselves are all physically located in the warehouse. As with manual procedures, when documenting computer operations the flowchart author must accurately represent the physical arrangement of the system components. As we will see in later chapters, the physical arrangement of system components (both manual and computer) often plays an important role in the auditor’s assessment of internal control.

Finally, Fact 6 describes how the shipping department clerk reconciles the goods with the supporting documents, sends the goods and the packing slip to the customer, updates the shipping log, and files two copies of the sales order. This is entirely a manual operation, as evidenced by the symbols in Figure 2-23. Note that the shipping log uses the same symbol that is used for representing journals and ledgers.

PROGRAM FLOWCHARTS

The system flowchart in Figure 2-23 shows the relationship between computer programs, the files they use, and the outputs they produce. This high level of documentation, however, does not provide the operational details that are sometimes needed. For example, an auditor wishing to assess the correctness of the edit program’s logic cannot do so from the system flowchart. This requires a program flowchart. The symbol set used for program flowcharts is presented in Figure 2-24.

Every program represented in a system flowchart should have a supporting program flowchart that describes its logic. Figure 2-25 presents the logic of the edit program shown in Figure 2-26. A separate

symbol represents each step of the program’s logic, and each symbol represents one or more lines of computer program code. The connector lines between the symbols establish the logical order of execution. Tracing the flowchart downward from the start symbol, we see that the program performs the following logical steps in the order listed:

1. The program retrieves a single record from the unedited transaction file and stores it in memory.

2. The first logical test is to see if the program has reached the end-of-file (EOF) condition for the transaction file. Most file structures use a special record or marker to indicate an EOF condition. When EOF is reached, the edit program will terminate and the next program in the system (in this case, the update program) will be executed. As long as there is a record in the unedited transaction file, the result of the EOF test will be ‘‘no’’ and process control is passed to the next logical step in the edit program.

3. Processing involves a series of tests to identify certain clerical and logical errors. Each test, represented by a decision symbol, evaluates the presence or absence of a condition. For example, an edit test could be to detect the presence of alphabetic data in a field that should contain only numeric data. We examine specific edit and validation tests in Chapter 17.

4. Error-free records are sent to the edited transaction file.

5. Records containing errors are sent to the error file.

6. The program loops back to Step 1, and the process is repeated until the EOF condition is reached.

Accountants sometimes use program flowcharts to verify the correctness of program logic. They com- pare flowcharts to the actual program code to determine whether the program is actually doing what the documentation describes. Program flowcharts provide essential details for conducting information technology audits, which we examine in Chapters 15, 16, and 17.

RECORD LAYOUT DIAGRAMS

Record layout diagrams are used to reveal the internal structure of the records that constitute a file or database table. The layout diagram usually shows the name, data type, and length of each attribute (or field) in the record. Detailed data structure information is needed for such tasks as identifying certain types of system failures, analyzing error reports, and designing tests of computer logic for debugging and auditing purposes. A simpler form of record layout, shown in Figure 2-27, suits our purposes best. This type of layout shows the content of a record. Each data attribute and key field is shown in terms of its name and relative location.