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 8.

Figure 6.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 numerical 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 6.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 6.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 6.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 database. 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 8, 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 6.15 presents the ER diagram for the DFD in Figure 6.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). 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 captured 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 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.

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 shipping
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 physical system, which is
represented as vertical columns of events and actions separated by lines of demarcation. Generally, each
of these areas of activity is a separate column with a heading. From these 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 6.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
6.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 6.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 6.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
system used, the file symbol will usually contain an “N” for numeric (invoice number), “C” for
chronological (date), or “A” for alphabetical 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 shipping department.

The completed flowchart is presented in Figure 6.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
flowchart. 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 are
derived by making transaction batches as 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.
 Flowch
arting 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
6.17 and Figure 6.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 customer’s credit by referencing a credit
history 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
warehouse 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 6.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 6.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
example. 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 6.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 6.23 how this computer
activity is represented. The warehouse PC is a standalone 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
6.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 6.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 6.24.

Every program represented in a system flowchart should have a supporting program flowchart that
describes its logic. Figure 6.25 presents the logic of the edit program shown in Figure 6.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 7.

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
compare 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 IT
audits, which we examine in Chapter 7.

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 6.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.