University Of Science & Technology Chattogram (USTC)

Faculty of Business Administration (FBA)

ACCOUNTING INFORMATION SYSTEMS

Course Code: 04168

M. Sadeque Ahmed
Head, Training & Awareness Dept.
Chittagong Stock Exchange PLC (CSE), and
Adjunct Lector, USTC
1
Documentation Techniques and Database Design
Today’s Learning Objectives

This discussion will help you gain an understanding of the following concepts:

List and discuss the purpose and use of systems flowcharts, document flowcharts, program
flowcharts, and hardware flowcharts;
Explain the basic parts of and design considerations common to all types of flowcharts;
Discuss ways flowcharts impact the design, implementation, and evaluation of AIS;
Create and interpret systems flowcharts.
Compare & contrast flowcharts and DFDs with regard to purpose, content, structure, and use in
accounting information systems.
Discuss the ways in which DFDs are used in AIS work.
Compare and contrast view-driven and event-driven accounting information systems.
Use REA modeling to represent an event-driven AIS.
2
Flowchart Types & Conventions
A good flowchart is like a snapshot of an information system. It can tell you, at a glance, where
information originates, who handles the information, and how it is summarized for decision making.
Basically, a flowchart is a graphical representation of some part of an information system. The
information system might be focused on accounting, production, human resources, or marketing; it
might be related to a particular business process (such as the sales/collection process) or project (such
as hiring new employees).
Flowcharts have been used by information technology professionals for years to document computer
programs; they also can be used to depict the hardware associated with a computer information system.
Flowcharts often are classified by their overall purpose and function:
 Systems flowcharts give the user a “big picture” look at an information system. Consider, for
example, the process you use to register for classes each term. You use certain documents and
types of information technology to select and register for classes; a systems flowchart would
combine all of those resources with their related business processes. The partial Barnes and
Noble flowchart in the following Figure is a systems flowchart:

3
Figure: Barnes & Noble online
book sales process prepared by
A. Student
4
 Program flowcharts show the logic associated with a computer program. As an
accountant, you probably won’t have much to do with program flowcharts.

 Document flowcharts, as you might expect, show the various documents involved in a
system; they also portray the procedures performed on those documents. So, for example,
a document flowchart might show your federal income tax return from the time you
receive a blank form through its eventual disposition with the Internal Revenue Service.

 Hardware flowcharts will probably be a minor concern in your accounting career as

well. They show the computers, printers, monitors, input devices, and other hardware
elements associated with an information system.

5
Although two different people can look at the same business process and draw flowcharts
that are significantly different, they should generally observe some very common
conventions (habits) associated with good flowcharting:
1. Flowcharts should generally be read from top to bottom and left to right—the same
way you read a page in a book.
2. Flowcharts should have plenty of “white space.” In other words, they shouldn’t be
too crowded on the page.
3. Flowcharts should have a title.
4. Flowcharts should be organized in columns that depict areas of responsibility.
5. Documents involved in a business process should have a clear origin and a clear
termination.
6. Rough drafts of flowcharts should be discussed by people involved in the process.

6
Flowcharting tools and symbols
Flowcharts can be designed using a variety of tools,
both high-tech and low-tech. On the low-tech end, you
can draw a flowchart with paper & pencil. You also
can use a flowcharting template, which includes many
common flowcharting symbols. While manual
methods are useful for “quick and dirty” starts at a
flowchart, they can become tedious & messy over
time.
Because flowcharts represent a kind of “universal
language” in information systems design,
implementation, and evaluation, they have some
common symbols with specific meanings. According
to the American National Standards Institute (ANSI),
flowchart symbols can be divided into four groups:
data, process, line, and special. Consider the symbols Figure: Selecting Flowcharting Symbols
shown in the Figure, which are just a small subset of
the many symbols associated with flowcharting.
7
Flowchart Design Steps
As you might suspect, there’s no “one right way” to design a flowchart. When we prepare a flowchart, we
normally follow this seven-step process:
1. Establish the system boundary.
2. Determine column headings
3. List actions performed within each column.
4. Select appropriate symbols.
5. Prepare a first draft.
6. Discuss the flowchart with others.
7. Revise as needed.

Create and interpret systems flowcharts

Three key ideas are important in creating flowcharts:
I. strive to achieve a clear representation of the system, not a deterministic response to a
particular problem or case situation;
II. practice will increase your skill in flowcharting; and
III.seldom will your first creation be your final one—flowcharts can almost always be improved
via dialogue and consultation with other professionals.
8
Flowcharting and Accounting Information Systems
AIS professionals use flowcharts in many different ways, including confirming how a system is
currently operating, suggesting improvements to an accounting information system, evaluating
internal control deficiencies, and designing procedures manuals.
A flowchart can be a useful way to conceptualize the big picture of a system. You’d probably want to
look over any existing procedures manuals and talk with employees familiar with the system already.
Then, you can try designing a flowchart to model a business process.
If you’re looking at a previously constructed flowchart, whether you’ve created it or not, you can try
to spot opportunities for improvement. Critically analyzing a flowchart is a tough job—there are no
hard-and-fast rules for doing it.
Flowcharts also can be used to spot internal control deficiencies in an accounting information system.
A flowchart can enhance a risk analysis by providing a concrete picture of an AIS.
Finally, flowcharts can be a starting point for the development of procedures manuals. A procedures
manual is simply an “instruction book” that explains how everyday tasks in an organization are
accomplished.
9
Data Flow Diagramming (DFD)
Earlier we learned about the first of the three documentation techniques often used in accounting
information systems: flowcharting. Now, we consider the second of the three: data flow
diagramming. The third technique, REA modeling, is discussed afterwards. In terms of the two broad
purposes of systems documentation in AIS, data flow diagrams help us achieve both. But, they are
less detailed than flowcharts when describing a business process; they are also a bit more
cumbersome than a REA model for understanding the database.

The concepts and ideas of data flow diagramming originated in the broader field of systems analysis
and design. Data flow diagrams (DFDs) incorporate fewer symbols and different “rules” than
flowcharts, but they do share many similarities.

DFD Symbols and Design Considerations

Unlike flowcharts, which incorporate a plethora of symbols, data flow diagrams incorporate only four
(DeMarco, 1979), which are shown in the following Figure:

10
A process is any set of procedures an
organization uses to gather data, change the data
into information, or report the information to
system users. Every process in a data flow
diagram has two identifying characteristics: a
number and a name.
An external entity is any person or organization
outside the boundary of an information system.
Establishing a clear, appropriate system boundary
is essential to the construction of a good data flow
diagram.
A data store is a place for collecting data; you
might think of it as a “file,” whether paper-based
or electronic. Data stores are labeled with noun
phrases such as customer data, vendor data, or
inventory data. Figure: Data Flow Diagram Symbols
Finally, a data flow is represented by a
directional line in a data flow diagram. Data
flows should have only one arrow on one end to
conform to DFD design conventions. 11
Compare & contrast DFDs and Flowcharts

12
Figure: Issue Purchase Order Process Level Zero DFD
13
Figure: Components of a Leveled Set of DFDs

14
The ways DFDs are used in AIS work:

DFDs can be used in at least four ways in accounting information systems design,
development, and implementation. They can:
I. ensure an adequate understanding of an accounting information system,

II. help accountants make process improvements to the system,

III.help others understand the flows of data and information, and

IV.assist in designing relational database tables that capture data and report information.

15
REA Modeling
Now, on systems documentation, we’ll look at a technique designed primarily to help users design and/or
understand the relational database that underlies the AIS; the technique is called REA modeling. REA is
an acronym referring to the resources, events, and agents in an event-driven accounting information
system. Most AIS designers and auditors find it best to start a REA model by identifying its relevant
events. In general, “events” come in three broad categories, as mentioned below:
Operating events focus on activities involved with providing goods and services to customers.
Examples include purchasing and selling inventory, paying employees, and converting raw
material into finished goods.

Information events deal with recording and maintaining data, as well as reporting information.
Think of information events as preparing financial statements or updating accounting records.

Decision/management events are concerned with human decision making. They can range from
simple things, such as which software and hardware to buy, to more complex decisions such as
changing compensation packages.
16
REA models capture data on strategically significant operating events; they do not incorporate information events
or decision/management events. Once strategically significant operating events have been identified, the rest of the
details (resources and agents) can be filled in around them.
[

Agents are the people involved in the information system. Internal agents include employees in all departments;
external agents refer to customers, vendors, and other stakeholders “outside” the business. Resources are the things
agents need to complete the events: cash, inventory, equipment, supplies, and other assets.

REA models are organized in columns, with the events appearing in the middle, resources to the left, and agents
to the right. The REA model presented in the following Figure has one event: rent car. It includes one resource,
automobile, and it incorporates two agents: client (an external agent) and a rental agent (an internal agent). That
REA model describes the process of renting a car to a client.

Hollander, Denna, and Cherrington (2000) recommend a six-step process to develop an REA model:
1. Understand the organization’s environment and objectives.
2. Review the business process and identify the strategically significant operating events.
3. Analyze each strategically significant operating event to identify the relevant event resources & agents.
4. Identify the relevant behaviors, characteristics, and attributes of the REA model elements.
5. Identify and document the direct relationships among elements of the REA model.
6. Validate the REA model with businesspeople.
17
Figure: REA Model Illustration (left side) REA Model with Cardinalities Explanation (right side)
18
The first column shows two resources, while the middle column shows two events. The rightmost column
shows to agents. Notice the order: Resources, Events, and Agents. Hence, the figure is called an REA
model. The parenthetical notations, such as (1, 1), are cardinalities; they show the relationship between
various elements of the REA model, and also provide guidance for database design.
As we read earlier, systems documentation has two main purposes: understanding business processes and
understanding the database. REA modeling is designed primarily for the latter; it depicts only enough of the
business process to design, understand, and/or evaluate the database.
Database-focused accounting information systems are sometimes referred to as event-driven systems.
McCarthy (1982) is considered by many to be the pioneer in the development of event-driven accounting
systems. Event-driven systems capture a broader range of data than view-driven systems; relational
database technology underlies most event-driven systems. Enterprise resource planning (ERP) systems are a
sophisticated version of event-driven AIS
Compare and contrast view-driven and event-driven accounting information systems.
Both types of systems are designed to collect data and process it into information; both typically involve
various forms of information technology. View-driven systems are designed to present that information in
one principal way: the general-purpose financial statements. Event-driven systems are built on relational
database technology; they capture more data and offer greater flexibility in terms of reporting via queries
and reports. 19
Cardinalities

Cardinalities tell an accounting professional about the relationships between elements of a REA
model. A well-constructed set of cardinalities is a huge help in using a REA model to create a
relational database. Ask yourself four questions when establishing cardinalities for a REA model:

1. For each x, what is the minimum number of y involved? Consider, for example, the
relationship between “rent car” and “employee” in the above Figure. If “rent car” is x and
“employee” is y, you’re asking: for each “rent car” transaction, what is the minimum
number of employees involved? In this case, the answer is one.

2. For each x , what is the maximum number of y involved? Extending that illustration, this
question becomes: for each “rent car” transaction, what is the maximum number of
employees involved? Assuming that each transaction is handled by only one employee, the
answer here is also one. Setting the maximum number of employees to “one” promotes
strong internal control; if two or more employees were involved in a transaction, collusion
between them could lead to errors and/or fraud.

Once you’ve answered the first two questions, record the cardinalities on the y side of the
relationship. So, the (1,1) notation next to the “employee” box in Figure 8.1 explains how many
employees are involved in each “rent car” transaction. 20
 3. For each y, what is the minimum number of x involved? In our example, this question is
asking about the minimum number of rental transactions an employee could complete. To
answer this question, consider that a rental car agency has many types of employees; only
some of them have the responsibility for renting cars. Other employees may be in charge of
cleaning the office, washing the cars, or other tasks. So, the minimum number of rental
transactions for a given employee is zero.

4. For each y , what is the maximum number of x involved? On the other hand, envision an
employee responsible for renting cars who works tirelessly—who handles each rental
transaction effectively and efficiently. Would you limit the number of transactions that
employee could complete? Probably not. When there’s no upper limit on a relationship
between two elements of an REA model, we refer to the maximum as many, and symbolize it
with an asterisk ( * ).

After answering questions 3 and 4, note the cardinalities on the x side of the relationship. So, the (0, * )
notation next to “rent car” tells us that each employee can complete from zero to many car rental
transactions. Consider the above Figure (right one) of slide no. 18 , which shows the same REA
model as Figure (left one) but includes the interpretations of the cardinalities for your reference.

21
Use REA modeling to represent an event-driven AIS.
REA modeling begins by understanding an organization’s environment and business processes. Then,
for each process, it identifies the resources, events and agents needed to capture the essential nature
of transactions. System designers use cardinalities to explain the relationships between the elements
of an REA model.

Use a REA model to design a relational database for an event-driven AIS.

Once the REA model has been established and validated, it can be translated into a series of relational
database tables. In most cases, each element of a REA model requires at least one table in a relational
database. Where the maximum cardinalities between elements of the model are many to many,
system designers create a junction table to denote the relationship.

The relational database technology that forms the basis for REA modeling is also the basis for
enterprise resource planning systems. So, a solid understanding of this area of AIS will give you an
appreciation for that important technology, as well as help you “speak the same language” as the IT
professionals with whom you’ll be working.

22