Chapter 10

The REA Approach to Business

Process Modeling

Accounting Information Systems, 5th edition

James A. Hall
 Objectives for Chapter 10
• Limitations of traditional database systems
• Benefits of an REA approach to information
systems
• Implications of REA for the accounting
• Steps in preparing an REA model of a business
process
• Importance of identifying the attributes of
entity relations in relational database design
• Differences between REA model
representations and ER diagram
representations
 Traditional Approaches:
User-View Orientation
• When data-modeling and IS design is too
oriented toward the user’s views, problems
arise:
– multiple information systems
– duplication of data
– restricted user-view leads to poor decision-
making
– inability to support change
 Traditional Approaches:
Financial Accounting Orientation
• Dominance of traditional accounting as the primary
information provider leads to problems:
– single view of business entity using the
accounting/balance sheet model:

Assets
Assets == Liabilities
Liabilities ++ Owners’
Owners’ Equity
Equity
– double-entry, debits and credits
– high level of aggregation
– ignoring non-financial data
– inability to serve diverse enterprise-wide needs
 Resources, Events, and Agents
Model
• Developed in the ‘70's by Dr. McCarthy (Michigan State)
• The definition of events is broad enough to encompass both
operational and accounting transactions.
– Expands the scope and usefulness of AIS by making it capable of
providing both financial and nonfinancial information.
• Data for each event is stored in disaggregated form.
– Outputs are subsequently produced by assembling the required data
from the various records.
• Many firms have not adopted the REA model since it is a
major change from the traditional double-entry approach.
– The REA or events perspective is increasingly seen as necessary to
meet changing information needs.
 Resources, Events, and Agents
Model
• An approach to database design meant to overcome problems with
traditional approaches:
– formalized data modeling and design of IS
– use of centralized database
– use of relational database structure
– collects detailed financial and non-financial data
– supports accounting and non-accounting analysis
– supports multiple user views
– supports enterprise-wide planning
 Resources, Events, and Agents
Model
• The REA model is an alternative accounting
framework for modeling an organization’s
– economic resources
– economic events
– economic agents, and
– their interrelationships
• A variation of entity-relationship diagramming
(ERD) is used to model these relationships.
 Resources in the REA Model
• Economic resources are the assets of the
company.
– able to generate revenue
– objects that are scarce and under the control of the
organization
– can be tangible or intangible
• Does not include some traditional accounting
assets:
– for example, Accounts Receivables
– artifacts that can be generated from other primary data
 Events in the REA Model
• Economic events are phenomena that effect
changes in resources.
– a source of detailed data in the REA approach to
databases
• Three classes of events:
– operating events--what happens
– information events--what is recorded
– decision/management events--what is done as a
result
• Only operating events are included in the REA
model.
 Agents in the REA Model
• Can be individuals or departments
• Can participate in events
• Can affect resources
– have discretionary power to use or dispose of
resources
• Can be inside or outside the organization
– clerks
– production workers
– customers
– suppliers, vendors
– departments, teams
 Resources, Events, and Agents
Model
• A variation of the entity-relationship
diagramming (ERD) is used in REA modeling.
• Basic ERD symbols:

entity relationship attribute

(optional) (optional)
 Advantages of the REA Model
• Using REA can lead to more efficient operations
– helps managers identify non-value added activities that
can be eliminated
• increased productivity via elimination of non-value added activities
generates excess capacity
– storing both financial and nonfinancial data in the same
central database reduces multiple data collection, data
storage, and maintenance
– detailed financial and nonfinancial business data
supports a wider range of management decisions
• increased competitive advantage by providing more relevant, timely,
and accurate information to managers
 Value Chain Analysis
• 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.
 Porter’s Value Chain
Revenue
Costs
Support Activities

Firm Infrastructure
Human resource management
Technology development

Margin
Procurement

Inbound Output Marketing

Operations Service
Logistics Logistics & Sales

Primary Activities
 Database Applications
Phase 1 Phase 2 Phase 3
Flat Files Event-Driven REA-Model
Database Database

Limitations Limitations: Limitations:

: Loss of non- Not widely used;
Redundant economic Requires detailed
data; information analysis
Anomalies
Database Sales Order Entry/Cash Receipts System
Database Purchases/Cash Disbursement System
 Limitations of Transaction-
Based Systems
• Event: a single business activity within a business
process which involves resources and agents
• Traditional event-based database systems tend to
focus exclusively on economic events.
– loss of non-economic/non-financial information
• REA is event-oriented versus event-based.
– includes non-economic and economic event
information
 Developing an REA Model:
Overview
• Before developing the REA model, identify
events and classify as:
Operating events--activities that produce goods
and services
Information events--activities associated with
recording, maintaining, and reporting information
Decision/Management events--activities that
lead to decisions being taken
• REA model uses only operating events.
 REA Example: Horizon Books
Horizon Books is a bookstore in downtown Philadelphia. It
carries an inventory of approximately 5,000 books.
Customers come in and browse the shelves, select their
books, and take them to one of three cashiers positioned
in different parts of the store. One of the cashiers is
situated at an information desk where customers can
discover whether a particular book is in stock, place orders
for books not currently available in the bookstore, and
collect and pay for books previously ordered. The cashier
at the information desk has a book database that is
consulted for every query. There are no credit sales. All
customers pay for their purchases at the time of purchase.
 Developing an REA Model:
Step 1
• Identify the operating events that are
to be included in the model
• These are the events that support the
strategic objectives of the
organization and about which we
need to gather information.
 REA Example: Horizon Books
Answer
Query Make
Sale

Receive
Payment

Step 1: Identify operating events in Horizon Books’ sales model

 Developing an REA Model:
Step 2
• Organize the operating events identified in
sequence of occurrence
• Show each event is shown as verb-object
– This facilitates arranging them in order of
occurrence.
• Note that the verb/event is represented
from the perspective of the organization,
not the customer.
REA Example: Horizon Books

Step 2: Place operating events in sequence

 Developing an REA Model:
Step 3
• Identify the resources and agents involved
in each operating event
• This is most easily done by answering
who, what, and where questions about
each event.
– Who was involved?
– What was involved?
– Where did it take place?
REA Example: Horizon Books

Step 3: Identify resources and agents associated with events

 Developing an REA Model:
Step 4
• Identify the links between the resources,
events, and agents
• Start from each event and connect it to the
resources and agents that are involved in
the event
• Draw a line connecting events that are
logically related
 REA Example: Horizon Books

Step 4: Establish Horizon Books’ sales process relationships.

 Developing an REA Model:
Step 5
• Assign the record associations or
cardinalities of all the entity relationships
• Five forms of associations (minimum-
maximum cardinalities) are used when
constructing the REA model:
– zero-to-one (0,1)
– zero-to-many (0,M)
– one-to-one (1,1)
– one-to-many (1,M)
– many-to-many (M,M)—rare
 REA Example: Horizon Books

Step 5: Completed REA model of sales process with cardinalities.

 Developing an REA Model:
Attributes and User-Views
• The final step is to define the attributes
associated with the entities in the model.
• These are used to populate the database.
• Also used to create the various physical
user-views needed in daily operations:
– reports, documents, computer interfaces
 Developing an REA Model:
Attributes
Using the customer as an example, these data include:
Financial Nonfinancial
Customer name Customer credit rating
Customer address Damaged goods
Customer telephone record
number On-time payment
Amount owed by record
customer Customer volume
Value of total sales to record
date EDI access
Terms of trade offered Internet access
Developing an REA Model:
User-Views

User-View #1 User-View #2

Sales Report
Past Due Accounts
Name Amount
James $500.00 REA Database
Henry $100.00
… …
 REA Model v. ERD
• The two methods have a lot in common, but there
are differences:
– ERDs are more commonly found with traditional event-
based systems.
– REA-modeling is used with event-oriented systems.
– ERDs often use diamonds to show events, while REA
model always classifies events as a type of entity.
– REA includes only operating events, while ERDs can
capture all three types of event.
– REA facilitates placement of internal controls.
– REA is more focused on business needs and, as a
result, often simpler.
ERD of Manufacturing
REA Model of Manufacturing, 1
REA Model of Manufacturing, 2