Chapter 1 The Information System: An Accountant’s Perspective

Internal Information Flows

• Horizonal flows of information used
primarily at the operations level to capture
transaction and operations data.
• Vertical flows of information
o Downward flows – instructions, quotas, and
budgets
o Upward flows – aggregated transaction
and operations data
Information Requirements
• Each user group has unique information
requirements.
• The higher the level of the organization, the greater the need for more
aggregated information and less need for detail.
Information in Business
• Information is a business resource that:
o Needs to be appropriately managed
o Is vital to the survival of contemporary businesses.
What is a System?
• A group of interrelated multiple components or subsystems that serve a
common purpose
• System or Subsystem?
o A system is called a subsystem when it is viewed as a component of a
larger system.
o A subsystem is considered a system when it is the focus of attention.
System Decomposition versus System Interdependency
• System Decomposition
o The process ofdividing the system into smaller subsystem parts
• System Interdependency
o Distinct part are not self-contained
o They are reliant upon the funtioning of the other parts of the system
o All distinct parts must be functioning or the system will fail
What is an Information System?
• An information system is the set of formal procedures by which data are
collected, processed into information, and distributed to users.
Transactions
• A transaction is a business event.
• Financial Transactions
 o Economic events that affect the assets and equities of the organization
o e.g., purchase of an airline ticket
• Nonfinancial Transactions
o All other events processed by the organizations information system
o e.g., an airline reservation – no commitment by the customer
What is an Accounting Information System?
• Accountingis an information system.
o It identifies, collects,
processes, and
communicates economic
information about a firm using
a wide variety of
technologies.
o It captures and records the
financial effects of the firms
transactions.
o It distributes transactions information to operations personnels to
coordinate many key tasks.
AIS versus MIS
• Accounting Information Systems (AIS) process
o Financial transactions; e.g., sale of goods
o Nonfinancial transactions that directly affect the processiong of financial
transactions; e.g., addition of newly approved vendors
• Management Information Systems (MIS) process
o Nonfinancial transactions that are not normally processed by traditional
AIS; e.g., tracking customer complaints
AIS Subsystems
• Transaction processing system (TPS)
o Supports daily business operations
• General Ledger/Financial Reporting
System (GL/FRS)
o Produces financial statements and reports
• Management Reporting System (MRS)
o Produces special-purpose reports for
internal use

Data Sources
• Data sources are financial transactions that enter the information system from
internal and external sources.
 o External financial transactions are the most common sources of data
for most organizations
o E.g., sale of goods and services, purchase of inventory, receipt of cash,
and disbursement of cash (including payroll)
o Internal financial transactions involve the exchange of movements of
resources within organization.
o E.g., movement of raw materials into work-in-process (WIP), application
of labor and overhead to WIP, tranfer of WIP into finished goods
inventory, and depreciation of equipment.
Transforming the Data into Information
• Functions for transforming data into information according to the general AIS
model:
1. Data Collection
o Capturing transaction data
o Recording data on forms
o Validating and editing the data

2. Data Processing
o Classifying
o Transcribing
o Sorting
o Batching
o Merging
o Calculating
o Summarizing
o Comparing

3. Data Management
o Storing
o Retrieving
o Deleting

4. Information Generation
o Compiling
o Arranging
o Formatting
o Presenting
Characteristics of Useful Information
• Regardless of physical form or technology, useful information has the following
characteristics:
o Relevance: serves a purpose
o Timeliness: no older than the time period of the action it supports
o Accuracy: free from material errors
 o Completeness: all information
essential to a decision or task is
present
o Summarization: aggregated in
accordance with the user’s needs
Information System Objectives in a Business
Context
• The goal of an information system is to
support
o The stewardship function of management
o Management decision
making
o The firm’s day-to-day
operations
Organization Structure
• The structure of an organization
helps to allocate
o Responsibility
o Authority
o Accountability
• Segmenting by business function is a very common method of organizing.
Function Areas
• Inventory/Materials Management
o Purchasing, receiving, and stores
• Production
o Production planning, quality control and maintenance
• Marketing
• Distribution
• Personnel
• Finance
• Accounting
• Computer Services
Accounting Independence
• Information reliability requires accounting independence
o Accounting activities must be separate and independent of the functional
areas maintaining resources .
o Accounting supprots these functions with information but does not actively
participate.
o Decisions makers in these functions requires that such vital information be
supplied by an idependent source
Potential Advantages of DDP
• Cost reductions in hardware and data
entry tasks
• Improved cost control responsibility
• Improved user satisfaction since control is
closer to the user level
• Backup of data can be improved
through the use of multiple data storage
sites
Potential Disadvantages of DDP
• Loss of control
• Mismanagement of company resources
• Hardware and software incompatibilities
• Redundant tasks and data
• Consolidating tasks usually segregated
• Difficulty attracting qualified personnel
• Lack of standard
Manual Process Model
• Transaction processing, information
processing and accounting are
physically performed by people, usually
using paper documents.
• Useful to study because:
o Helps link AIS courses to the other accounting courses
o Often easier to understand business processes when not surrounded in
technology
o Facilitates understanding internal controls
Data Redundancy Problems
• Data Storage – excessive storage cost pf
paper documents and/ or magnetic form
• Data Updating – changes or additions
must be performed multiple times
• Currency of Information – potential
problem of failing to update all affected
files
• Task-Data Dependency – user’s inability to obtain additional information as
needs change
 • Data Integration – separate files are difficult to integrate across multiple users.

REA Model
• The REA model is an accounting
framework for modeling an organization’s
o Economic resources; e.g., assets
o economic events; i.e., affect
changes in resources
o economic agents; i.e., individuals
and departments that participate in
an economic event
o interrelationship among resources,
events and agents
• Entity-relationship diagrams (ERD) are
often used to model these relationship.
Accounting as Information Systems User
• Accountants must be able to clearly
convey their needs to the systems professionals who design the system.
• The accountant should actively participate in systems development projects to
ensure appropriate systems design.
Accountants as System Designer
• The accounting function is responsible for the conceptual system, while the
computer functions is responsible for the physical system.
• The conceptual system determines the nature of the information requires, its
sources, its destination, and the accounting rules that must be applied.
Accountants as System Auditors
• External Auditors
o Attest to fairness of financial statements
o Assurance service: broader in scope than traditional attestation audit
• IT Auditors
o Evaluate IT, often as part of external audit
• Internal Auditors
o In-house IS and IT appraisal services
CHAPTER 2 INTRODUCTION TO TRANSACTION PROCESSING
A Financial Transaction is...
• an economic event that affects the assets and equities of the firm, is reflected in
its accounts, and is measured in monetary terms.
• similar types of transactions are grouped together into three transaction cycles:
o the expenditure cycle
o the conversion cycle
 o the revenue cycle
Each Cycle has Two Primary Subsystems
• Expenditure Cycle: time lag between the two due to credit relations with
suppliers:
o physical component (acquisition of goods)
o financial component (cash disbursements to the supplier)
• Conversion Cycle :
o the production system (planning, scheduling, and control of the physical
product through the manufacturing process)
o the cost accounting system (monitors the flow of cost information related
to production)
• Revenue Cycle: time lag between the two due to credit relations with
customers :
o physical component (sales order processing)
o financial component (cash receipts)
Manual System Accounting Records
• Source Documents - used to capture and formalize transaction data needed for
transaction processing
• Product Documents - the result of transaction processing
• Turnaround Documents - a product document of one system that becomes a
source document for another system
• Journals - a record of chronological entry
o special journals - specific classes of transactions that occur in high
frequency
o general journal - nonrecurring, infrequent, and dissimilar transactions
• Ledger - a book of financial accounts
o general ledger - shows activity for each account listed on the chart of
accounts
o subsidiary ledger - shows activity by detail for each account type
Computer-Based Systems
• The audit trail is less observable in
computerbased systems than traditional
manual systems.
• The data entry and computer programs
are the physical trail.
• The data are stored in magnetic files.

Computer Files
• Master File - generally contains account
data (e.g., general ledger and subsidiary
file)
 • Transaction File - a temporary file containing transactions since the last update
• Reference File - contains relatively constant information used in processing (e.g.,
tax tables, customer addresses)
• Archive File - contains past transactions for reference purposes.

Documentation Techniques
• Documentation in a CB environment is necessary for many reasons.
• Five common documentation techniques:
o Entity Relationship Diagram
o Data Flow Diagrams
o Document Flowcharts
o System Flowcharts
o Program Flowcharts

Entity Relationship Diagram (ERD)

• A documentation technique to represent the relationship between entities in a
system.
• The REA model version of ERD is widely used in AIS. REA uses 3 types of entities:
o resources (cash, raw materials)
o events (release of raw materials into the production process)
o agents (inventory control clerk, vendor, production worker)
Cardinalities
• Represent the numerical mapping between entities:
o one-to-one
o one-to-many
o many-to-many
Data Flow Diagrams (DFD)…
• use symbols to represent the processes,
data sources, data flows, and entities in a
system
• represent the logical elements of the
system
 • do not represent the physical system
System Flowcharts…

• illustrate the relationship among processes

and the documents that flow between them
• contain more details than data flow diagrams
• clearly depict the separation of functions in a system

System Flowcharts…
• are used to represent the relationship between the key elements--input sources,
programs, and output products--of computer systems
• depict the type of media being used (paper, magnetic tape, magnetic disks,
and terminals)
• in practice, not much difference between document and system flowcharts
Modern Systems versus Legacy Systems
• Modern systems characteristics:
o client-server based and process transactions in real time
o use relational database tables
o have high degree of process integration and data sharing
o some are mainframe based and use batch processing
• Some firms employ legacy systems for certain aspects of their data processing.
o Accountants need to understand legacy systems.
• Legacy systems characteristics:
o mainframe-based applications
o batch oriented
o early legacy systems use flat files for data storage
o later legacy systems use hierarchical and network databases
o data storage systems promote a single-user environment that
discourages information integration

Computer-Based Accounting Systems

• Two broad classes of systems:
o batch systems
o real-time systems
Batch Processing
• A batch is a group of similar transactions that are accumulated over time and
then processed together.
• The transactions must be independent of one another during the time period over
which the transactions are accumulated in order for batch processing to be
appropriate.
• A time lag exists between the event and the processing.

Steps in Batch Processing/Sequential File

• Keystroke - source documents are transcribed by clerks to magnetic tape for
processing later
• Edit Run - identifies clerical errors in the batch and places them into an error file
• Sort Run - places the transaction file in the same order as the master file using a
primary key
• Update Run - changes the value of appropriate fields in the master file to reflect
the transaction
• Backup Procedure - the original master continues to exist and a new master file is
created.
Advantages of Batch Processing
• Organizations can increase efficiency by grouping large numbers of transactions
into batches rather than processing each event separately.
• Batch processing provides control over the transaction process via control
figures.
Real-Time Systems…
• process transactions individually at the moment the economic event occurs
• have no time lag between the economic event and the processing
• generally require greater resources than batch processing since they require
dedicated processing capacity; however, these cost differentials are
decreasing
 • oftentimes have longer systems development time

Why Do So Many AIS Use Batch Processing?

• AIS processing is characterized by high-volume, independent transactions, such
are recording cash receipts checks received in the mail.
• The processing of such high-volume checks can be done during an off-peak
computer time.
• This is one reason why batch processing maybe done using real-time data
collection.
Uses of Coding in AIS
• Concisely represent large amounts of complex information that would otherwise
be unmanageable
• Provide a means of accountability over the completeness of the transactions
processed
• Identify unique transactions and accounts within a file
• Support the audit function by providing an effective audit trail
Sequential Codes
• Represent items in sequential order
• Used to prenumber source documents
• Track each transaction processed
• Identify any out-of-sequence documents
• Disadvantages:
o arbitrary information
o hard to make changes and insertions
Block Codes
• Represent whole classes by assigning each class a specific range within the
coding scheme
• Used for chart of accounts
o The basis of the general ledger
• Allows for the easy insertion of new codes within a block
o Don’t have to reorganize the coding structure
 • Disadvantage:
o arbitrary information

Alphabetic Codes
• Used for many of the same purposes as numeric codes
• Can be assigned sequentially or used in block and group coding techniques
• May be used to represent large numbers of items

The REA Approach to Business Process Modeling

❖Traditional approach:
User-view orientation
- When data-modeling and IS design is too oriented toward the
user’s views, problem arise:
o Multiple information systems
o Duplication of data
o Restricted user-view leads to poor decision-making
o Inability to support change
❖Resource, Events, and Agents Model
- It is an approach to database design meant to overcome
problems with traditional approach
o Formalized data modeling and design of IS
o Use of centralized database
o Use of relational database structure
o Collects detailed financial and non-financial data
o Supports accounting and non-accounting analysis
o Support multiple user view
 o Supports enterprise-wide planning
- It consists of three types and the associations linking them
o Resource
o Events
o Agents
❖Resource in the REA model
o The ‘assets’ of the company
▪ Things of economic value
▪ Objects of economic exchanges able to generate revenue
▪ Objects that are scarce and under the control of the
organization
▪ Can be tangible or intangible
o Does not include some traditional accounting assets
▪ Artifacts that can be generated from other primary data
▪ Example, accounts receivable
❖Events in the REA model
o Events are phenomena that effect changes in resources
▪ A source of detailed data in the REA approach to database
o Events fall into 2 groups
▪ Economic – increases or decreases resources
▪ Support – control, planning, and other management
activities; but do not directly affect resources
❖Agents in the REA model
o They can be individuals or departments
o Participate in events
o Affect resources
▪ Have discretionary power to use dispose of resources
o Can be inside or outside the organization
▪ Clerks
▪ Production workers
 ▪ Customers
▪ Suppliers, vendors
▪ Departments, teams

❖Resource, Events, and Agents Model

o Another key feature of the REA model is economic duality
▪ Events occur in pairs
▪ Represent the give event and receive event of an
economic exchange
❖ER Diagrams (ERD’s) vs REA Diagrams (READ’s)
- ERD: entity relationship diagram
o Classes of entities
▪ ERD’s – one class
▪ READ’s – three classes (resource, events, and agents
o Arrangement of entities
▪ ERD’s - determined by cardinality and readability
▪ READ’s – organized into constellations by class
o Sequencing of events
▪ ERD’s - static
▪ READ’s – chronological sequence of business processes
o Naming conventions
▪ ERD’s – all nouns
▪ READ’s – nouns (R’s and A’s) and verbs (E’s)
❖View modeling: creating an individual REA diagram
o View modeling is a multistep process for creating an individual
REA model
▪ The result is a single view of the entire database
o The four steps involved are:
▪ Identify the event entities to be modeled
▪ Identify the resource entities changed by events
▪ Identify the agent entities participating in events
▪ Determine associations and cardinalities between entities
1. Identify the events entities
a. Identify the events that are to be included in the model
i. Include at least two economic events (duality)
ii. May include support events
iii. Arrange events in chronological sequence
b. Focus on value chain events
c. Do not include invalid events such as:
 i. Bookkeeping tasks
ii. Accounting artifacts, e.g., accounts receivable

2. Identify the resource entities

a. Identify the resources impacted by event identified in step 1
b. Each event must be linked to at least one resource
i. Economic events directly affect resources
ii. Support events indirectly affect them
3. Identify the agent entities
a. Each economic event entity in a REA diagram is associated
with at least two agent entities
i. One normal agent
ii. One external agent
b. It is possible to have only an internal agent when no exchange
occurs, as with certain ‘internal’ manufacturing processes
4. Determine associations and cardinalities between entities
a. Association – reflects the nature of the relationship between
two entities
i. Represented by the labeled line connecting the entities
b. Cardinality – the degree of association between the entities
i. Describes the number of possible occurrences in one
entity that are associated with a single occurrence in a
related entity
c. Cardinality reflects the business rules that are in play for a
particular organization
i. Sometimes the rules are obvious and are the same for all
organizations
ii. Sometimes the rules differ, e.g., whether inventory items
are tracked individually or as quantity on hand
❖Many-to-many association
o Many-to-many (M:M) associations cannot be directly
implemented into relational database
o They require the creation of a new linking table
▪ This process splits the M:M associations into two 1:M
associations
▪ The linking table requires a ‘composite primary key’
❖View integration: creating an enterprise-wide REA model
o View integration – combining several individual REA diagrams
into a single enterprise-wide model
o The three steps involved in view integration are:
▪ Consolidate the individual models
▪ Define primary keys, foreign keys, and attributes
▪ Construct physical database and produce user views
1. Consolidate the individual models
a. Merging multiple REA models requires first a thorough
understanding of the business processes and entities involved
in the models
b. Individual models are consolidated or linked together based
on shared entities
i. For examples, procurement (expenditures) and sales
(revenue) both use inventory and cash resource entities
 2. Define primary keys foreign keys, and attributes
a. Implementation into a working relational database requires
primary keys, foreign keys and attributes in tables
i. Primary key – uniquely identifies an instance of an entity,
e.g., each row in the table
ii. Foreign key – the primary key embedded in the related
table so that the two tables can be linked
iii. Attribute – a characteristics of the entity to be recorded
in the table
❖Rules for foreign keys
o Primary key -> foreign key: relations are formed by an
attribute that is common to both tables in the relation
o Assignment for foreign keys:
▪ If 1 to 1 (1:1) association, either of the table’s primary key
may be the foreign key
▪ If 1 to many (1:m) association, the primary key of one of
the sides is embedded as the foreign key on the other
side
▪ If many to many (m:m) association, create a separate
linking table with a composite primary key
Attributes
Using the customer as an example, these data include
3. Constrict physical database and produce user views
a. The database designer is now ready to create the physical
relational tables using software
b. Once the tables have been constructed, some of them
must be populated with data
i. Resource and agent tables
c. Event tables must wait for business transactions to occur
before data can be entered
d. The resulting database should support the information
need of all users
i. SQL is used to generate reports, computer screens,
and documents for users

❖Value chain analysis

o Competitive advantages from the REA approach can be
see via value chain analysis
▪ Value chain analysis – distinguishes between
primary activities (create value) and support
activities (assist performing primary activities)
 ▪ REA provides a model for identifying and
differentiating between these activities
▪ Prioritizing strategy: focus on primary activities;
eliminate or outsource support activities
❖Competitive advantages of the REA model
o Using REA can lead to more efficient operations
▪ Helps managers identify non-value-added activities
that can be eliminated
• Increasing productivity via elimination of non-
value activities generated excess capacity
▪ Storing both financial and non-financial data in the
same central database reduce multiple data
collection, data storage, and maintenance
▪ Detailed financial and nonfinancial business data
supports a wider range of managements decisions
• Supporting multiple user views (e.g., different
perspective on a problem)
▪ Provides managers with more relevant, timely, and
accurate information
• Leading to better customer service, higher-
quality products, and flexible production
processes

Enterprise Resource Planning Systems

❖Problems with Non-ERP Systems
o In-house design limits connectivity outside the company
o Tendency toward separate IS’s within firm
▪ Lack of integration limits communication within the
company
 o Strategic decision-making not supported
o Long-term maintenance costs high
o Limits ability to engage in process reengineering
❖Traditional IS model: Closed Database Architecture
o Similar in concept to flat-file approach
▪ Data remains the property of the application
▪ Fragmentation limits communications
o Existence of numerous distinct and independent
database
▪ Redundancy and anomaly problems
o Paper-based
▪ Requires multiple entry of data
▪ Status of information unknown at key points
❖What is an ERP System?
o Multi-module application software that helps a company
manage the important parts of its business in an
integrated fashion
❖Key features include:
o Smooth and seamless flow of information across
organizational boundaries
o Standardized environment with shared database
independent of applications and integrated applications

❖Two Main ERP Applications

o Core applications
▪ A.k.a. On-line Transaction Processing (OLTP)
▪ Transaction processing systems
 ▪ Support the day-to-day operational activities of the
business
▪ Support mission-critical tasks through simple
queries of operational databases
▪ Include sales and distribution, business planning,
production planning, shop floor control, and logistic
modules
o Business analysis applications
▪ A.k.a. On-line Analytical Processing (OLAP)
▪ Decision support tool for management-critical tasks
through analytical investigation of complex data
associations
▪ Supplies management with “real-time” information
and facilitates timely decisions to improve
performance and achieve competitive advantage
▪ Includes decision support, modeling, information
retrieval, ad-hoc reporting/analysis, and what-if
analysis
❖OLAP
o Supports management-critical tasks through analytical
investigation of complex data associations captured in
data warehouses:
▪ Consolidation: the aggregation or roll-up of data
▪ Drill-down: allows the user to see data in selectively
increasing level of details
▪ Slicing and dicing: enables the user to examine data
from different viewpoints to uncover trends and
patterns
❖ERP System Configurations: Client-Server Network Topology
o Two-tier
 ▪ Common server handles both application and
database duties
▪ Used especially in LANs

❖ERP System Configurations: Client-Server Network Topology

o Three-tier
▪ Clients links to the application server which then
initiates a second connection to the database server
▪ Used especially in WANs
❖ERP System Configurations: Database and Bolt-Ons
o Database configuration
▪ Selection of database tables in the thousands
▪ Setting the switches in the system
o Bolt-on Software
▪ Third-party vendors provide specialized functionality
software
▪ Supply Chain Management (SCM) links vendors,
carriers, logistics companies, and IS providers
❖What is Data Warehouse?
o A multi-dimensional database often using hundreds of
gigabytes or even terabytes of memory
▪ Data are extracted periodically from operational
databases or from public information services
o A database constructed for quick searching, retrieval, ad-
hoc queries, and ease of use
o ERP systems can exist without data warehouses
 ▪ However, most large ERP implementations include
separate operational and data warehouse databases
▪ Otherwise, management data analysis may result in
pulling system resources away from operational use
▪ Also, there are many sophisticated data-mining tools
❖Data Warehouse Process
o The five stages of the data warehousing process:
▪ Modeling data for the data warehouse
▪ Extracting data from operational databases
▪ Cleansing extracted data
▪ Transforming data into the warehouse model
▪ Loading data into the data warehouse database

❖Data Warehouse Process: stage 1

o Modeling data for the data warehouse
▪ Because of the vast size of a data warehouse, the
warehouse database consists of de-normalized data
• Relational theory does not apply to a data
warehousing system
• Normalized tables pertaining to selected events
may be consolidated into de-normalized tables
❖Data warehouse process: stage 2
o Extracting data from operational databases
▪ The process of collecting data from operational
databases, flat-files, archives, and external data
sources
▪ Snapshots vs. stabilized data
• A key feature of a data warehouse is that the
data contained in it are in a non-volatile (stable)
state
❖Data warehouse process: stage 3
o Cleansing extracted data
▪ Involves filtering out or repairing invalid data prior
to being stored in the warehouse
• Operational data are “dirty” for many reasons:
clerical, data entry, computer program errors,
misspelled names and black fields
▪ Also involves transforming data into standard
business terms with standard data values
❖Data warehouse process: stage 4
o Transforming data into the warehouse model
▪ To improve efficiency, data are transformed into
summary views before being locked
▪ Unlike operational views, which are virtual in nature
with underlying base tables, data warehouse views
are physical tables
• OLAP permits users to construct virtual views
❖Data warehouse process: stage 5
o Loading data into the data warehouse database
▪ Data warehouses must be created & maintained
separately from the operational database
• Internal efficiency
• Integration of legacy systems
• Consolidation of global data
❖Application of data mining
o Business field: Banking and Investments
o Application
▪ Detect patterns of fraudulent credit card use
▪ Identify loyal customers and predict those likely to
change their credit card affiliation
▪ Examine historical market data to determine
investor’s stock trading rules
▪ Predict credit card spending of key customer groups
▪ Identify correlations between financial indicators
o Business field: Health Care and Medical Insurance
o Application
▪ Predict office visits from historical analysis of
historical patient behavior
▪ Identify successful and economic medical therapies
for different illnesses
 ▪ Identify which medical procedures tend to be
claimed together
▪ Predict which customers will buy new policies
▪ Identify behavior patterns associated with high-
risked customers
▪ Identify indications of fraudulent behavior
o Business field: marketing
o Application
▪ Identify buying patterns based on historical customer
data
▪ Identify relationships among customer demographic
data
▪ Predict response to various forms of marketing and
promotion campaigns
❖Risks Associated with ERP Implementation
o Pace of Implementation
▪ ‘Big Bang’: switch operations from legacy systems to
ERP in a single event
▪ ‘Phased-in’: independent ERP units installed over
time, assimilated, and integrated
o Opposition to change
▪ User reluctance and inertia
▪ Need of upper management support
o Choosing the wrong ERP
▪ Goodness of fit: no one ERP product is best for all
industries
▪ Scalability: system’s ability to grow
o Choosing the wrong consultant
▪ Common to use a third-party (the Big Four)
▪ Thoroughly interview potential consultants
 ▪ Establish explicit expectations
o High cost and cost overruns
▪ Common areas with high costs:
• training
• testing and integration
• database conversion
▪ Disruptions to operations
• ERP implementations usually involve business
process reengineering (BPR)
o Expect major changes in business processes
❖Implications for internal control and auditing
o Transaction authorization
▪ Controls are needed to validate transactions before
they are accepted by other modules
▪ ERPs are more dependent on programmed controls
that on human intervention

o Segregation of duties
▪ Manual processes that normally require segregation
of duties are often eliminated
▪ User role: predefined user roles limit a user’s access
to certain functions and data
o Supervision
▪ Supervisors need to acquire a technical and
operational understanding of the new system
▪ Employee-empowered philosophy should not
eliminate supervision
o Accounting records
 ▪ Corrupted data may be passed from external sources
and from legacy systems
▪ Loss of paper audit trail
o Access control
▪ Critical concern with confidentiality of information
▪ Who should have access to what?
o Access to data warehouse
▪ Data warehouse often involve sharing information
with suppliers and customers
o Contingency planning
▪ Keeping a business going in case of disaster
▪ Key role of servers requires backup plans: redundant
servers or shared servers
o Independent verification
▪ Traditional verifications are meaningless
▪ Need to shift from transaction level to overall
performance level
CHAPTER 13: MANAGING THE SYSTEMS DEVELOPMENT LIFE CYCLE
❖ THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
o A logical sequence of activities used to:
▪ Identify new systems needs
▪ Develop new systems to support those needs
o A model for reducing risk through planning, execution, control,
and documentation
o The SDLC model may be shown in five stages
OVERVIEW OF PHASE 1 AND 2
❖ Phase 1 – Systems Strategy
o Understand the strategic needs of the organization
o Examine the organization’s mission statement
o Analyze competitive pressures on the firm
o Examine current and anticipated market conditions
 o Consider the information system’s implications pertaining to
legacy systems
o Consider concerns registered through user feedback
o Produce a strategic plan for meeting these various and complex
needs
o Produce a timetable for implementation
❖ Phase 2 – Project Initiation
o Assess systems proposals for consistency with the strategic
systems plan
o Evaluate feasibility and cost-benefit characteristics of proposals
o Consider alternative conceptual designs
o Select a design to enter the construct phase of the SDLC
o Examine whether the proposal will require in-house
development, a commercial package, or both
❖ Systems Development Participants
o Systems Professionals – analyze problems in current systems
and formulate solutions
▪ Systems analysis
▪ Systems designers
▪ Programmers
o End Users – primary users of the system
▪ Addressing their needs is critical to success
o Stakeholders – individuals who have an interest in the system
but are not end users
❖ Systems Steering Committee
o Usually includes the CEO, CFO, CIO, senior management from
user areas, and computer services, and internal auditors
o Typical responsibilities
▪ Provide guidance
▪ Resolve conflicts
▪ Review projects and assigning priorities
▪ Budget and allocate funds
▪ Review the status of projects
▪ Determine whether projects should be continued
PHASE 1 – SYSTEMS STRATEGY
❖ Assessing Strategic Information Needs
 o Strategic systems planning involves the allocation of resources
at the macro level
▪ Usually a time frame of three to five years
o Key inputs in developing a sounds systems strategy include:
▪ Strategic business needs of the organization
▪ Situations involving legacy systems
▪ End user feedback
❖ Strategic Business Needs
o Vision and Mission
▪ System strategy requires an understanding of top
management’s vision, which has shaped the organization’s
business strategy
o Industry and Competency Analysis
▪ Industry analysis: the driving forces that affect the industry
and their organization’s performance, such as important
trends, significant risks, and potential opportunities
▪ Competency analysis: a complete picture of the
organization’s effectiveness as seen via four strategic
filters: resource, infrastructure, products/services, and
customers
Legacy Systems – use legacy components to help develop an architecture
description
➢ Business Benefits from Architecture Description
o Efficient IT operation
▪ Lower software development, support, and maintenance
costs
▪ Increased portability of applications
▪ Improved interoperability and easier systems and network
management
o Ability to address critical enterprise-wide issues
▪ Easier upgrade and exchange of system components
▪ Better return on existing investment, reduced risk for
future investment
▪ Reduced complexity in IT infrastructure
▪ Maximum return on investment in existing IT infrastructure
 ▪ The flexibility to make, buy, or outsource IT solutions
▪ Reduced risk overall in new investment and the costs of IT
ownership
o Improved procurement
▪ Buying decisions are simpler, because the information
governing procurement is readily available in a coherent
plan
▪ The procurement process is faster, maximizing
procurement speed and flexibility without sacrificing
architectural coherence
END USER FEEDBACK
▪ Identifying user needs is fundamental to everything else
▪ During phase 1, pertains to substantial perceived problems rather
than minor systems modifications
▪ Has five key phases at this point in the SDLC:
o Recognize problems
o Define problems
o Specify systems objectives
o Determine feasibility and contributions of projects
▪ May entail prioritizing individual projects
o Preparing a formal project proposal
END USER FEEDBACK: RECOGNIZING THE PROBLEM
▪ The need for a new, improved information system is manifested
through various symptoms
o Symptoms may seem vague and innocuous or go unrecognized
initially
▪ The point at which the problem is recognized is often a function of
management’s philosophy
o Reactive management: responds to problems only when they
reach a crisis state
o Proactive management: alert to subtle signs of problems and
aggressively looks for ways to improve
END USER FEEDBACK: DEFINING THE PROBLEM
 ▪ Managers and end users should
o Avoid leaping to a single definition of a problem
o Keep an open mind and gather facts before deciding
o Learn to intelligently interact with systems professionals
▪ An interactive process between managers/end users and systems
professionals is necessary to arrive at an accurate problem definition
o The next three stages of the end user feedback process involve
this interactive process
END USER FEEDBACK: SPECIFYING SYSTEM OBJECTIVES
▪ The strategic objective of the firm and the operational objectives of
the information systems must be compatible
▪ At this point, the objectives only need to be defined in general terms
END USER FEEDBACK: PRELIMINARY PROJECT FEASIBILITY – TELOS
▪ Technical feasibility: is the technology necessary available
▪ Economic feasibility: are the funds available and appropriate for the
systems
▪ Legal feasibility: does the system fall within legal boundaries?
▪ Operational feasibility: can procedural changes be made to make
the system work?
▪ Schedule feasibility: can the project be completed by an acceptable
time period?
END USER FEEDBACK: PREPARING A FORMAL PROJECT PROPOSAL
▪ A systems project proposal provides management with a basis for
deciding whether or not to proceed with the project
▪ It summarizes the findings of the study and makes a general
recommendation
▪ It outlines the linkage between the objectives of the proposed
system and business objectives of the firm
❖ Strategic Systems Plan
o After collecting input, the steering committee and systems
professionals evaluate the pros and cons of each proposal
o Assessing each potential project’s:
▪ Benefits
 ▪ Costs
▪ Strategic impact
o Development will proceed on proposals with the greatest
potential for supporting the organization’s business objectives
at the lowest cost

❖ Create an Action Plan: The Balanced Scorecard

o The next step is to translate strategy into action
o Many companies have found the balanced scorecard (BSC) a
useful tool for this step
o The BSC recommends viewing an organization using four
perspectives:
▪ Learning and growth
▪ Internal business process
▪ Customer
▪ Financial
THE BALANCED SCORECARD
▪ Primary objective: capture information on orthogonal dimensions
that are important to every organization
▪ Second objective: prevent the proliferation of reports and
information. Concentrate only on critical success factors to which
everyone in the organization will pay attention

PHASE 2: PROJECT INITATION

❖ Project Initiation
o The second phase in SDLC involves
▪ Understanding user’s needs and problems
▪ Proposing multiple alternative solutions
▪ Assessing alternatives in terms of feasibility and cost-
benefit characteristics
▪ Selecting the best option and proceeding to the construct
phase
▪ Examining whether the selected option will require in-
house development, a commercial package, or both
❖ Systems Analysis
o A business problem must be fully understood before a solution
can be formulated
 ▪ A defective analysis will lead to a defective solution
o System analysis is a two-step process
▪ Survey of current systems
▪ Analysis of users’ needs
❖ Survey of current systems
o Advantages
▪ Identifies aspects of the old system which should be
retained in the new system
▪ Aids in planning the implementation of the new system
▪ May allow conclusive determination of the cause of the
reported problems
o Disadvantages
▪ The current physical tar pit
▪ Can stifle new ideas
❖ The survey steps
o Fact-gathering techniques include observing, participating,
interviewing, and reviewing documents
o Facts must be gathered regarding:
▪ Data sourcing and data stores
▪ Users
▪ Processes
▪ Data flows
▪ Controls, especially audit trails
▪ Transaction volumes
▪ Error rates
▪ Resource costs
▪ Bottlenecks and redundant operations
❖ The analysis steps
o Systems analysis is an intellectual process that is commingled
with fact gathering
o A formal systems analysis report, prepared and presented to
the steering committee, contains
▪ Reasons for system analysis
▪ Scope of study
▪ Problem identified with current system
▪ Statement of user requirements
 ▪ Resource implications
▪ Recommendations
THE CONCEPTUALIZATION PHASE
▪ Purpose: produce alternative conceptual solutions that satisfy the
requirements identified during systems analysis
▪ How much detail?
o Enough to highlight the differences between critical features of
competing systems rather than their similarities
ALTERNATIVE CONCEPTUAL DESIGNS FOR A PURCHASING SYSTEM

SELECTION EVALUATION AND SELECTION

▪ A critical juncture in the SDLC
o A formal mechanism for selecting the one system from the set
of alternative conceptual designs that will go forward for
construction
o An optimization process that seeks to identify the best system
o A structured decision-making process that reduces uncertainty
and risk
THE ROLE OF ACCOUNTANTS
▪ Accountants ensure that the following are considered during
evaluation and selection’
 o Only escapable (relevant) costs are used in calculations of cost
savings benefits
o Reasonable interest rates are used in measuring present values
of cash flows
o One-time and recurring costs are completely and accurately
reported
o Realistic useful lives are used in comparing competing projects
o Intangible benefits are assigned reasonable financial values
DETAILED FEASIBILITY STUDY
▪ Similar to the preliminary project feasibility analysis (TELOS), but
now more detailed and oriented to deciding on a specific system
design. Examine:
o Technical feasibility
o Economic feasibility
o Legal feasibility
o Operational feasibility
o Schedule feasibility
COST-BENEFIT ANALYSIS: IDENTIFY COST
▪ One-time and Recurring Costs
o One-time cash
▪ Hardware acquisition
▪ Site preparation
▪ Software acquisition
▪ Systems design
▪ Programming and testing
▪ Data conversion from old system to new system
▪ Training personnel
o Recurring cash
▪ Hardware maintenance
▪ Software maintenance contracts
▪ Insurance
▪ Supplies
▪ Personnel
COST-BENEFIT ANALYSIS: IDENTIFY BENEFITS
 ▪ Tangible benefits
o Increased revenues
▪ Increased sales within existing markets
▪ Expansion into other markets
o Cost reduction
▪ Labor reduction
▪ Operating cost reduction (such as supplies and overhead
▪ Reduced inventories
▪ Less expensive equipment
▪ Reduced equipment maintenance
▪ Intangible benefits
o Increased customer satisfaction
o Improved employee satisfaction
o More current information
o Improved decision making
o Faster response to competitor actions
o More efficient operations
o Better internal and external communications
o Improved planning
o Operational flexibility
o Improved control environment
COMPARING COSTS AND BENEFITS
▪ Two methods commonly used for evaluating the costs and benefits
of information systems:
o Net present value method: deduct the present value of costs
from the present value of benefits over the life of the project
▪ The optimal choice is the project with the greatest net
present value
o Payback method: do break-even analysis of total costs & one-
time costs plus present value of recurring costs) and total
benefits (present value of benefits) after the break-even point,
the system earns future profits
▪ The optimal choice is the project with the greatest future
profits
HOW SHOULD WE GET THE SYSTEM?
▪ Once the optimal system is selected, decide how to acquire it:
o Develop the system in-house: best for systems that need to
meet unique and proprietary business needs
o Purchase commercial software: best for systems that are
expected to support “best industry practices”
o A mix of the first two approaches: make in-house
modifications, to varying degrees, of a commercial system to
meet the organization’s unique needs
ANNOUNCING THE NEW SYSTEM PROJECT
▪ Can be the most delicate aspect of the SDLC
▪ End user support is critical to success
▪ All end users need to be made to understand the objectives of the
new system
▪ End users and managers who view the new system as a potential
benefit to their jobs, rather than a threat, are more likely to
cooperate with the project
WHY ARE ACCOUNTANCTS INVOLVED WITH SDLC?
▪ The creation of an information system consumes significant
resources and has financial resource implications
▪ The quality of accounting information systems and their output rests
directly on the SDLC activities that produce them

HOW ARE ACCOUNTANTS INVOLVED WITH SDLC?

▪ As end users who must provide a clear picture of their problems and
needs
▪ As members of the development team
▪ As auditors who must ensure that the system is designed with
appropriate internal controls and computer audit techniques
THE ACCOUNTANT’S ROLE IN SYSTEMS STRATEGY
▪ Auditors should routinely review the organization’s system strategy
 ▪ Careful systems planning is a cost-effective way to reduce the risk of
creating unneeded, unwanted, inefficient, and ineffective systems
▪ Both internal and external auditors have vested interests in this
outcome
THE ACCOUNTANT’S ROLE IN CONCEPTUAL DESIGN
▪ Accountants should be responsible for the conceptual system
o And the systems professionals for the physical system
▪ If important accounting considerations are not conceptualized at this
point, they may be overlooked, exposing the organization to
potential financial loss
▪ The auditability of a system depends in part on its design
characteristics
THE ACCOUNTANT’S ROLE IN SYSTEMS SELECTION
▪ Economic feasibility is a primary concern to accountants.
Accountants should ensure that:
o Use only escapable costs in calculations of cost-savings benefits
o Use reasonable interest rates in measuring present values of
cash flows
o One-time v. recurring costs are accurately reported
o Use realistic useful lives in comparing competing projects
o Intangible benefits are assigned reasonable financial values
CHAPTER 14: CONSTRUCT, DELIVER, AND MAINTAIN SYSTEMS PROJECTS
OVERVIEW OF PHASES 3,4,5
❖ Phase 3: In-house Development
o Appropriate when organizations have unique information needs
o Steps include:
▪ Analyzing user needs
▪ Designing processes and databases
▪ Creating user views
▪ Programming the applications
▪ Testing and implementing the completed system
❖ Phase 4: Commercial Packages
 o When acceptable, most organizations will seek a pre-coded
commercial software package
▪ Advantages
• Lower initial cost
• Shorter implementation time
• Better controls
• Rigorous testing by the vendor
▪ Risks
• Must adequately meet end user’s needs
• Computable with existing systems
❖ Phase 5: Maintenance and Support
o Acquiring and implementing the latest software versions of
commercial packages
o Making in-house modifications to existing systems to
accommodate changing user needs
o May be relatively trivial, such as modifying an application to
produce a new report, or more extensive, such as programming
new functionality into a system

❖ PHASE 3: SYSTEMS STRATEGY

Why Up to 25% of All Systems Projects Fail
▪ Poorly specified systems requirements
▪ communication problems
▪ time pressures
▪ Ineffective development techniques
▪ paper, pencils, templates, erasers instead of software tools,
such as CASE
▪ Lack of user involvement in systems development
Prototyping
▪ A technique for providing a preliminary working version of the
system
 ▪ Built quickly and relatively inexpensively with the intention it will be
modified
▪ End users work with the prototype and make suggestions for
changes.
▪ A better understanding of the true requirements of the system
is achieved.
Prototyping Techniques

Computer-Aided Software Engineering (CASE)

▪ CASE technology involves the use of computer systems to build
computer systems.
▪ CASE tools are commercial software products consisting of highly
integrated applications that support a wide range of SDLC activities.
Uses of CASE Tools
▪ Define user requirements
▪ Create physical databases from conceptual user views
▪ Produce system design specifications
▪ Automatically generate program code
▪ Facilitate the maintenance of programs created by both CASE and
non-CASE techniques
CASE Spectrum of Support Tools for the SDLC
PERT Chart for In-House Development Project
- PERT charts show the relationship among key activities that constitute
the construct and delivery process.

Gantt Chart
Structured Design Approach
▪ A disciplined way of designing systems from the top down
▪ Starts with the “big picture” of the proposed system and gradually
decomposes it into greater detail so that it may be fully understood
▪ Utilizes data flow diagrams (DFDs) and structure diagrams
Object-Oriented Design Approach
▪ It builds information systems from reusable standard components or
objects.
▪ Once created, standard modules can be used in other systems with
similar needs.
▪ A library of modules can be created for future use.
Elements of the Object-Oriented Approach
▪ Objects: equivalent to nouns
▪ vendors, customers, inventory, etc.
▪ Attributes: equivalent to adjectives
 ▪ part number, quantity on hand, etc.
▪ Operations: equivalent to verbs
▪ review quantity on hand, reorder item
Characteristics of an Inventory Object

Classes and Instances

▪ An object class is a logical grouping of individual objects that share
the same attributes and operations.
▪ An object instance is a single occurrence of an object within a class.

Inheritance
 ▪ Inheritance means that each object instance inherits the attributes
and operations of the class to which it belongs.
▪ Object classes may also inherit from other object classes.
Systems Design
▪ Follows a logical sequence of events:
▪ model the business process and design conceptual views
▪ design normalized database tables
▪ design physical user views (output and input views)
▪ develop process modules
▪ specify system controls
▪ perform system walkthroughs
Data Modeling
▪ Formalizes the data requirements of the business process as a
conceptual model
▪ Entity-relationship diagram (ERD)
▪ the primary tool for data modeling
▪ used to depict the entities or data objects in the system
▪ Each entity in an ERD is a candidate for a conceptual user view that
must be supported by the database.
Normalization
▪ User views in the data model must be supported by normalized
database tables.
▪ Normalization of database tables:
▪ A process of organizing tables so that entities are represented
unambiguously
▪ Eliminates data redundancies and associated anomalies
▪ Depends on the extent to which the data requirements of all
users have been properly specified in the data model
 ▪ REA modeling facilitates normalization by identifying entities at
their most fundamental levels
▪ The resulting databases will support multiple user views
Physical User Views:
Output Views
▪ Output is the information produced by the system to support user
tasks and decisions.
▪ Output attributes:
-relevance
-summarization
-exception orientation
Output Reporting Techniques
▪ Different users prefer different styles of output…
▪ tables, matrices, charts, and graphs
▪ …and modes of output.
▪ hard copy vs. display screen.
▪ Systems designers must identify these styles and provide output in
the desired style.
Physical User Views:
Input Views
▪ Input views are used to capture the relevant facts in business
processes and transactions (e.g., via REA model):
▪ Resources
▪ Events
▪ Agents
▪ Input may be either hard copy input documents or electronic input.
Designing Hard Copy Input
▪ Items to Consider:
 ▪ How will the document be handled?
▪ How long will the form be stored and in what type of
environment?
▪ How many copies are required?
▪ What size form is necessary?
Non-standard form can cause printing and storage problems.
Designing Electronic Input
Input may be from either hardcopy or electronic

Data Entry Devices

▪ Point-of-sale terminals
▪ Touch screens
▪ Mouse
▪ Magnetic ink character recognition devices
▪ Optical character recognition devices
▪ Voice and touch-tone recognition devices
Designing Process Modules
 ▪ Begins with the DFDs produced in the general design phase
▪ First, decompose the existing DFDs to a degree of detail that will
serve as the basis for creating structure diagrams
▪ Structure diagrams provide the blueprints for writing the actual
program modules
Data Flow Diagrams (DFDs)
▪ Used to represent multiple levels of detail.
▪ Can represent system physically or logically
▪ Context-level DFDs represent an overview of the business activities
and the primary transactions processed by the system.
▪ Do not include detailed definitions of data files and specific
procedures.
▪ Decompose high-level DFDs into more detailed lower-level DFDs.
DFD for Purchases and Cash Disbursements System

Lower Level DFD for AP Process I.4

The Modular Approach
▪ Each module performs a single task.
▪ Correctly designed modules possess two attributes:
▪ loosely coupled - low amounts of exchange of data between
modules
▪ strongly cohesive - small number of tasks performed in each
module
Designing System Controls
▪ The last step in the detailed design phase
▪ Need to consider:
▪ computer processing controls
▪ data base controls
▪ manual controls over input to and output from the system
▪ operational environment controls
▪ Allows the design team to review, modify, and evaluate controls with
a system-wide perspective that did not exist when each module was
being designed independently
Systems Walkthrough
▪ Usually performed by the development team
▪ Ensure that design is free from conceptual errors that could
become programmed into the final system
▪ Some firms use a quality assurance (QA) group to perform this task.
▪ An independent group of programmers, analysts, users, and
internal auditors
Program Application Software
▪ If the organization intends to develop software in-house, then a
programming language must be selected:
▪ procedural languages or 3GLs
COBOL
▪ event-driven languages
Visual Basic
▪ object-oriented languages
Java
The Modular Approach to Programming
▪ Promotes programming efficiency
▪ modules can be both programmed and tested independently
▪ Promotes maintenance efficiency
▪ small modules are easier to analyze and change
▪ Promotes greater control
▪ modules are less likely to contain material errors of fraudulent
logic
Deliver the System:
Testing
▪ Programs must be thoroughly tested before being implemented.
▪ All logic procedures should be tested.
 ▪ Test individual modules with test data containing both “good” and
“bad” data.
▪ After testing individual modules, the entire system should be tested
as a whole.
Deliver the System:
Documenting
▪ Describes how the system works
▪ Documentation should be provided for:
▪ designers and programmers - comment lines in programs,
system flowcharts, and program flowcharts
▪ operator documentation - run manuals
▪ user documentation - instructions on how to use the system,
tutorials, and help features
▪ accountants and auditors - all of the above as well as document
flowcharts
Deliver the System:
Converting the Databases
▪ The transfer of data from its current form to the format or medium
required by the new system
▪ Control risks with the following procedures:
▪ validation – inspect old database before conversion
▪ reconciliation – reconcile the new converted database against
the original
▪ backup - keep copies of the original files against discrepancies
in the converted data

Deliver the System:

Converting the Databases
Three data conversion cutover approaches:
 ▪ Cold turkey - switch to the new system all at once and
simultaneously terminate the old system.
▪ riskiest approach
▪ Phased - modules are implemented in a piecemeal fashion.
▪ reduces risk of a devastating failure
▪ Parallel operation - the old system and new system are run
simultaneously for a while.
▪ safest, yet costliest, approach
Deliver the System:
Post-Implementation Review
▪ Objective: measure the success of the new system.
▪ do after initial problems have been addressed
▪ Assess:
▪ system design adequacy
▪ accuracy of time, cost, and benefit estimates
▪ Provides feedback to improve future systems development projects,
including changes to the current system
Deliver the System:
The Role of Accountants
▪ Most system failures are due to poor design and improper
implementation.
▪ Accountants should provide their expertise to help avoid inadequate
systems by:
▪ providing technical expertise for financial reporting
requirements
▪ specifying documentation standards for auditing purposes
▪ verifying control adequacy in accordance with SAS 78
 PHASE 4: COMMERICAL PACKAGES
The Purchase of Commercial Systems Packages
▪ Four factors have stimulated the growth of commercial software:
▪ relatively low cost
▪ prevalence of industry-specific vendors
▪ growing demand by small businesses
▪ trend toward downsizing and distributed data processing
Trends in Commercial Packages
▪ Turnkey systems - completely finished and tested systems ready for
implementation
▪ Backbone systems - provide a basic system structure on which to
build.
▪ Vendor-supported systems - customized and maintained by a
vendor for a customer
▪ ERP systems - difficult to classify since they have characteristic of all
of the above.
Pros and Cons of Commercial Packages
▪ Advantages:
▪ decreased implementation time
▪ decreased cost
▪ reduced probability of program errors
▪ Disadvantages:
▪ dependent on the vendor for maintenance
▪ less flexibility in system
▪ greater difficulty in modifying the system as needs change over
time
Four Steps in Choosing a Commercial Package
 1. Analyze needs and develop detailed specifications of the system
requirements.
2. Send out the request for proposals to all prospective vendors to
serve as a comparative basis for initial screening.
3. Gather the facts about each vendor’s system using multiple sources
and techniques.
4. Analyze the findings and make a final selection.
PHASE 5: MAINTENANCE AND SUPPORT
Maintenance and Support
▪ Approximately 80% of the life and costs of SDLC
▪ Can be outsourced or done in-house resources
▪ End user support is a critical aspect of maintenance that can be
facilitated by:
▪ knowledge management - method for gathering, organizing,
refining, and disseminating user input
▪ group memory - method for collecting user input for
maintenance and support
The Iceberg Effect
CHAPTER 15: IT ONTROLS PART 1 – SARBANES – OXLEY AND IT
GOVERNANCE

➢ Sarbanes-Oxley Act
o The 2002 Sarbanes-Oxley (SOX) Act established new corporate
governance rules
▪ Created company accounting oversight board
▪ Increased accountability for company officers and board of
directors
▪ Increased white collar crime penalties
▪ Prohibits a company’s external audit firms from designing and
implementing financial information systems
➢ SOX Section 302
o Section 302—in quarterly and annual financial statements,
management must:
▪ certify the internal controls (IC) over financial reporting
▪ state responsibility for IC design
▪ provide reasonable assurance as to the reliability of the
financial reporting process
▪ disclose any recent material changes in IC
➢ SOX Section 404
o Section 404 – in the annual report on IC effectiveness, management
must:
▪ state responsibility for establishing and maintaining adequate
financial reporting IC
▪ assess IC effectiveness
▪ reference the external auditors’ attestation report on
management’s IC assessment
▪ provide explicit conclusions on the effectiveness of financial
reporting IC
▪ identify the framework management used to conduct their IC
assessment, e.g., COBIT
➢ IT Controls & Financial Reporting
o Modern financial reporting is driven by information technology (IT)
o IT initiates, authorizes, records, and reports the effects of financial
transactions.
▪ Financial reporting IC are inextricably integrated to IT.
o COSO identifies two groups of IT controls:
▪ application controls – apply to specific applications and
programs, and ensure data validity, completeness and
accuracy
 ▪ general controls – apply to all systems and address IT
governance and infrastructure, security of operating systems
and databases, and application and program acquisition and
development

➢ SOX Audit Implications

o Pre-SOX, audits did not require IC tests.
▪ Only required to be familiar with client’s IC
▪ Audit consisted primarily of substantive tests
o SOX – radically expanded scope of audit
▪ Issue new audit opinion on management’s IC assessment
▪ Required to test IC affecting financial information, especially IC
to prevent fraud
▪ Collect documentation of management’s IC tests and
interview management on IC changes
➢ Types of Audit Tests
o Tests of controls – tests to determine if appropriate IC are in place
and functioning effectively
o Substantive testing – detailed examination of account balances and
transactions
➢ Organizational Structure IC
o Audit objective – verify that individuals in incompatible areas are
segregated to minimize risk while promoting operational efficiency
o IC, especially segregation of duties, affected by which of two
organizational structures applies:
▪ Centralized model
▪ Distributed model
➢ Segregation of Duties
o Transaction authorization is separate from transaction processing.
o Asset custody is separate from record-keeping responsibilities.
o The tasks needed to process the transactions are subdivided so that
fraud requires collusion.

➢ Centralized IT Structure
o Critical to segregate:
▪ systems development from computer operations
▪ database administrator (DBA) from other computer service
functions
• DBA’s authorizing and systems development’s processing
• DBA authorizes access
▪ maintenance from new systems development
▪ data library from operations
➢ Distributed IT Structure
o Despite its many advantages, important IC implications are present:
▪ incompatible software among the various work centers
▪ data redundancy may result
▪ consolidation of incompatible tasks
▪ difficulty hiring qualified professionals
▪ lack of standards
➢ Organizational Structure IC
o A corporate IT function alleviates potential problems associated with
distributed IT organizations by providing:
▪ central testing of commercial hardware and software
▪ a user services staff
▪ a standard-setting body
▪ reviewing technical credentials of prospective systems
professionals
➢ Audit Procedures
o Review the corporate policy on computer security
▪ Verify that the security policy is communicated to employees
o Review documentation to determine if individuals or groups are
performing incompatible functions
o Review systems documentation and maintenance records
▪ Verify that maintenance programmers are not also design
programmers
o Observe if segregation policies are followed in practice.
▪ E.g., check operations room access logs to determine if
programmers enter for reasons other than system failures
o Review user rights and privileges
▪ Verify that programmers have access privileges consistent with
their job descriptions
➢ Computer Center IC
o Audit objectives:
▪ physical security IC protects the computer center from physical
exposures
▪ insurance coverage compensates the organization for
damage to the computer center
▪ operator documentation addresses routine operations as well
as system failures
o Considerations:
▪ man-made threats and natural hazards
▪ underground utility and communications lines
▪ air conditioning and air filtration systems
▪ access limited to operators and computer center workers;
others required to sign in and out
▪ fire suppression systems installed
▪ fault tolerance
• redundant disks and other system components
• backup power supplies
➢ Audit Procedures
o Review insurance coverage on hardware, software, and physical
facility
 o Review operator documentation, run manuals, for completeness
and accuracy
o Verify that operational details of a system’s internal logic are not in
the operator’s documentation
➢ Disaster Recovery Planning
o Disaster recovery plans (DRP) identify:
▪ actions before, during, and after the disaster
▪ disaster recovery team
▪ priorities for restoring critical applications
o Audit objective – verify that DRP is adequate and feasible for
dealing with disasters
o Major IC concerns:
▪ second-site backups
▪ critical applications and databases
• including supplies and documentation
▪ back-up and off-site storage procedures
▪ disaster recovery team
▪ testing the DRP regularly
➢ Second-Site Backups
o Empty shell - involves two or more user organizations that buy or
lease a building and remodel it into a computer site, but without
computer equipment
o Recovery operations center - a completely equipped site; very costly
and typically shared among many companies
o Internally provided backup - companies with multiple data
processing centers may create internal excess capacity
➢ DRP Audit Procedures
o Evaluate adequacy of second-site backup arrangements
o Review list of critical applications for completeness and currency
o Verify that procedures are in place for storing off-site copies of
applications and data
▪ Check currency back-ups and copies
o Verify that documentation, supplies, etc., are stored off-site
o Verify that the disaster recovery team knows its responsibilities
▪ Check frequency of testing the DRP
➢ Benefits of IT Outsourcing
o Improved core business processes
o Improved IT performance
o Reduced IT costs
➢ Risks of IT Outsourcing
o Failure to perform
o Vendor exploitation
o Costs exceed benefits
o Reduced security
 o Loss of strategic advantage
➢ Audit Implications of IT Outsourcing
o Management retains SOX responsibilities
o SAS No. 70 report or audit of vendor will be required

FROM APPENDIX – AUDIT BACKGROUND MATERIAL

➢ Attestation versus Assurance

o Attestation:
▪ practitioner is engaged to issue a written communication that
expresses a conclusion about the reliability of a written
assertion that is the responsibility of another party.
o Assurance:
▪ professional services that are designed to improve the quality
of information, both financial and non-financial, used by
decision-makers
▪ includes, but is not limited to attestation

➢ What is an External Financial Audit?

o An independent attestation by a professional (CPA) regarding the
faithful representation of the financial statements
o Three phases of a financial audit:
▪ familiarization with client firm
▪ evaluation and testing of internal controls
▪ assessment of reliability of financial data
Auditing
Management’s Assertions
➢ External versus Internal Auditing
o External auditors – represent the interests of third party stakeholders
o Internal auditors – serve an independent appraisal function within
the organization
▪ Often perform tasks which can reduce external audit fees and
help to achieve audit efficiency
➢ What is an IT Audit?
o IT audits:
▪ focus on the computer-based aspects of an organization’s
information system
▪ assess the proper implementation, operation, and control of
computer resources
➢ Elements of an IT Audit
o Systematic procedures are used
o Evidence is obtained
▪ tests of internal controls
▪ substantive tests
o Determination of materiality for weaknesses found
o Prepare audit report & audit opinion
➢ Phases of an IT Audit

➢ Audit Risk is...

o the probability the auditor will issue an unqualified (clean) opinion
when in fact the financial statements are materially misstated.
➢ Three Components of Audit Risk
o Inherent risk – associated with the unique characteristics of the
business or industry of the client
o Control risk – the likelihood that the control structure is flawed
because controls are either absent or inadequate to prevent or
detect errors in the accounts
o Detection risk – the risk that errors not detected or prevented by the
control structure will also not be detected by the auditor
➢ Computer Fraud Schemes
o Theft, misuse, or misappropriation of assets by altering computer-
readable records and files
o Theft, misuse, or misappropriation of assets by altering logic of
computer software
o Theft or illegal use of computer-readable information
o Theft, corruption, illegal copying or intentional destruction of
software
o Theft, misuse, or misappropriation of computer hardware
➢ Using the general IS model, explain how fraud can occur at the different
stages of information processing?

➢ Data Collection Fraud

o This aspect of the system is the most vulnerable because it is
relatively easy to change data as it is being entered into the system.
o Also, the GIGO (garbage in, garbage out) principle reminds us that if
the input data is inaccurate, processing will result in inaccurate
output.
➢ Data Processing Fraud
o Program Frauds
▪ altering programs to allow illegal access to and/or
manipulation of data files
▪ destroying programs with a virus
o Operations Frauds
 ▪ misuse of company computer resources, such as using the
computer for personal business
➢ Database Management Fraud
o Altering, deleting, corrupting, destroying, or stealing an
organization’s data
o Oftentimes conducted by disgruntled or ex-employee
➢ Information Generation Fraud
o Stealing, misdirecting, or misusing computer output
o Scavenging
▪ searching through the trash cans on the computer center for
discarded output (the output should be shredded, but
frequently is not)