Based on:

2003 Prentice Hall Business Publishing,

Accounting Information Systems, 9/e, Romney/Steinbart

The REA Data Model
The REA data model is a
conceptual modeling tool
specifically designed to provide
structure for designing AIS data
bases.
The REA Data Model
The REA data model provides
structure in two ways:
By identifying what entities should be
included in the AIS database
By prescribing how to structure
relationships among the entities in
the AIS database
Business Activities

Business transactions are exchanges.
Who gets what and who gives what in return are
separate transactions.
The exchange occurs between the business entity
and usually an outside agent.
The business gives something and then gets
something in return.
Resources, Events, and
Agents
Every business transaction is made up of three
components:
Resources are the things of economic value
exchanged.
Events are the actual giving and getting of the
resources.
Agents are the people who actually make the
exchange.
Steps and Documents in the Acquisition/Payment Process
(as used in the SUA)
Steps and Documents in the Sales/Collection Process
(as used in the SUA)

Assets = Claims
Assets = Liabilities + Owners Equity

Asset: economic resources owned by
the business.
Liability: obligations of the business to
creditors.
Equity: owners claims to the assets.

The Accounting Equation
Four Basic Financial
Statements
Balance Sheet
Assets = Liabilities + Equity
Income Statement
Revenues - Expenses = Net income
Statement of Retained Earnings
Beginning RE + Net income - Dividends = Ending RE
Cash Flow Statement
Cash inflow - Cash outflow = Net cash flow
Traditional Approaches: User-View Orientation
When data-modeling and IS design is too oriented
toward the users 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:


double-entry, debits and credits
high level of aggregation
ignoring non-financial data
inability to serve diverse enterprise-wide needs
Assets = Liabilities + Owners Equity



The REA Approach to
Business Modeling

Resources, Events, and Agents (REA) Model
Developed in the 70's by Dr. Bill McCarthy of Michigan
State University
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.
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 (REA) Model
The REA model is an alternative accounting
framework for modeling an organizations
economic resources
economic events
economic agents, and
their interrelationships

A variation of entity-relationship diagramming
(ERD) is used to model these relationships.
Resources, Events, and Agents (REA) Model
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
A variation of the entity-relationship diagramming
(ERD) is used in REA modeling.
Basic ERD symbols:
entity
relationship
(optional)
attribute
(optional)
Resources, Events, and Agents (REA) Model
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.
Phase 1
Flat Files
Phase 2
Event-Driven
Database
Phase 3
REA-Model
Database
Limitations:
Redundant
data;
Anomalies
Limitations:
Loss of non-
economic
information
Limitations:
Not widely used;
Requires detailed
analysis
Database Applications
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.
The REA Data Model
Resources Events Agents
Give-To- Get
Duality
The REA Data Model
Resources Events Agents
Resources:
Those things
that have
economic value
to the firm.
The REA Data Model
Resources Events Agents
Events:
Various
Business
Activities
The REA Data Model
Resources Events Agents
Agents:
People and
Organizations
that participate
in events.
Developing an REA
Diagram
Step 1: Identify the
Economic Exchange
Events
Identify the pair of events that
reflect the basic economic
exchange (give-to-get duality
relationship) in that cycle.
Identify the PAIR of events
One GET
One GIVE
Step 2: Identify
Resources and Agents
Identify the Resources affected by
each event and the agents who
participate in those events.
Identify . . .
RESOURCES affected by each event.
AGENTS who participate in the events.
Step 3: Include
commitment Events
Analyze each economic exchange
event to determine whether it
should be decomposed into a
combination of one or more
commitment events and an
economic exchange event.
Include commitment events.
Determine the cardinalities of each
relationship.
Step 4: Determine
Cardinalities of
Relationships
Determine cardinalities of relationships.
Sales Customer
How many sales transactions can be
linked to each individual customer?
How many customers can be linked to
each individual sales transaction?
Cardinalities
(1,N)
Minimum
Maximum
The first number is the minimum cardinality. It
indicates whether a row in this table must be
linked to at least one row in the table on the
opposite side of that relationship.
Minimum Cardinality
The minimum cardinality of a relationship
indicates whether each row in that entity
MUST be linked to a row in the entity on
the other side of the relationship.
Minimum cardinalities can be either 0 or 1.
Minimum Cardinalities
A minimum cardinality of zero means
that a new row can be added to that
table without being linked to any rows in
the other table.
A minimum cardinality of one means
that each row in that table MUST be
linked to at least one row in the other
table
Cardinalities
Sales Made to Customer
(0, N)
The minimum cardinality of zero in the (0,
N) cardinality pair to the left of the
customer entity in the customer-sales
relationship . . .
. . . indicates that a new customer may be
added to the database without being linked
to any sales events.
Cardinalities
The minimum cardinality of 1 in the (1,1)
cardinality pair to the right of the sales
entity in the customer-sales relationship . .
.
. . . indicates that a new sales transaction
CAN ONLY be added if it is linked to a
customer.
Sales Made to Customer
(0, N)
(1,1)
The second number is the maximum cardinality.
It indicates whether one row in that table can be
linked to more than one row in the other table.
Maximum Cardinalities
The maximum cardinality of a relationship
indicates whether each row in that entity
CAN be linked to more than one row in the
entity on the other side of the relationship.
Maximum cardinalities can be either 1 or N.
Maximum Cardinalities
A maximum cardinality of 1 means that
each row in that table can be linked to
at most only 1 row in the other table.
A maximum cardinality of N means that
each row in that table MAY be linked to
more than one row in the other table.
Cardinalities
Sales Made to Customer
(0, N)
The maximum cardinality of N in the (0,N)
cardinality pair to the left of the customer
entity in the customer-sales relationship . . .
. . . indicates that a given customer MAY be
linked to many sales events.
Cardinalities
The maximum cardinality of 1 in the (1,1)
cardinality pair to the right of the sales
entity in the customer-sales relationship . . .
. . . indicates that a given sales transaction
can only be linked to one customer.
Sales Made to Customer
(0, N)
(1,1)
Determine Cardinalities
Cardinalities are not arbitrarily chosen
by the database designer.
They reflect facts about the organization
being modeled and its business
practices obtained during the
requirements analysis stage of the
database design process.
Cardinalities: Types of
Relationships
Three basic types - depending on the
maximum cardinality associated with
each entity.
A one-to-one relationship (1:1)
A one-to-many relationship (1:N)
A many-to-many relationship (M:N)
Types of Relationships
Panel A: One-to-One (1:1) Relationship
Sales
Cash
Receipts
(0,1) (1,1)
Types of Relationships
Panel B: One-to-Many (1:N) Relationship
Sales
Cash
Receipts
(0,N) (1,1)
Types of Relationships
Panel C: One-to-Many (1:N) Relationship
Sales
Cash
Receipts
(0,1) (1,N)
Types of Relationships
Panel D: Many-to-Many (M:N) Relationship
Sales
Cash
Receipts
(0,N) (1,N)
Build a Set of Tables to
Implement an REA
Model of an AIS in a
Relational Database
Implementing an REA
Diagram in a Relational
Database
An REA diagram can be used to design
a well-structured relational database.
A well-structured relational database is
one that is not subject to update, insert,
and delete anomaly problems.
Three Step Process
Create a table for each distinct entity and
for each many-to many relationship
Assign attributes to appropriate tables
Use foreign keys to implement one-to-one
and one-to-many relationships
Implementing an REA Diagram
Implementing an REA
model
Inventory
Purchases-
Cash
Disbursements
Buyer
(Purchasing Agent)
Purchases
Cash
Disbursement
Cash Cashier
Vendor
(1,N) (0,N)
(0,N)
(1,N)
(1,1) (0,N) (1,1) (0,N)
(1,1)
(1,1)
(0,N) (1,1)
Stockflow
Inventory-
Purchases
Participant
Participant
Participant
Participant
(0,N)
(0,N)
Create Tables
1. Inventory
2. Purchases
3. Employees
4. Vendors
5. Cashier
6. Cash disbursements
7. Cash
8. Purchases-inventory
9. Purchases-cash
disbursements
From the previously discussed REA diagram, nine
tables would be created: one for each of the
seven entities and one for each of the many-to-
many relationships.

Assign Attributes
for Each Table
Primary keys: Usually, the primary key
of a table representing an entity is a
single attribute.
Other Attributes: Additional attributes
are included in each table to satisfy
transaction processing requirements.
Implementing an REA Diagram
Implementing an REA Diagram
Documentation of
Business Practices
REA diagrams are especially useful for
documenting an advanced AIS built
using databases.
REA diagrams provide information
about the organizations business
practices
Documentation of
Business Practices
The zero minimum for the sales event
indicates that credit sales are made
The N maximum for the sales event
means that customers may make
installment payments
Cash
Receipts
Sales-
Cash Receipts
Sales
(1, N) (0, N)
Documentation of
Business Practices
The one minimum for the cash receipts
event indicates that cash is not received
prior to delivering the merchandise
The N maximum for the cash receipts
event means that customers may pay for
several sales with one check
Cash
Receipts
Sales-
Cash Receipts
Sales
(1, N) (0, N)
Extracting Information
From the AIS
A complete REA diagram serves as a
useful guide for querying an AIS
database.
Queries can be used to generate
journals and ledgers from a relational
database built on the REA model.
Extracting Information
From the AIS
Each sales transaction is paid in full by a
cash collection event.
Each customer payment may be for more
than one sale.
What is the query logic?
Total accounts receivable is the sum of all
sales for which there is no remittance
number.
Cash
collections
Sales
(0, 1) (1, N)
Extracting Information
From the AIS
Each sales transaction can be paid in
installments.
Each customer payment is for just one sale.
What is the query logic?
(1) sum all sales; (2) sum cash collections;
then A/R = (1)-(2)
Cash
collections
Sales
(0, N) (1, 1)
Extracting Information
From the AIS
Each sales transaction is paid in full by a
cash collection event.
Each customer payment is for one sale.
What is the query logic?
Total accounts receivable is the sum of all
sales for which there is no remittance
number.
Cash
collections
Sales
(0, 1) (1, 1)
Extracting Information
From the AIS
Each sales transaction may be paid for in
installments.
Each customer payment may be for more
than one sale.
What is the query logic?
(1) Sum all sales; (2) Sum all cash
collections; Then A/R = (1)-(2)
Cash
collections
Sales
(0, N) (1, N)
Lets Review with a Little
Help From My Friends .

William E. McCarthy*
Michigan State University

(These slides may be copied as long as original source is cited)
*http://www.msu.edu/user/mccarth4/

Cookie-Monster (the customer) and Elmo (the
entrepreneur) meet in the (real or virtual)
marketplace, thus setting the stage for an
Economic Exchange
Economic
Event
Economic
Agent
Economic
Resource
duality

Source:
W. E. McCarthy The REA Accounting Model: A Generalized Framework for Accounting
Systems in a Shared Data Environment, The Accounting Review, July 1982, pp 554-78.
W.E. McCarthy The REA Modeling Approach to Teaching Accounting Information Systems,
Issues in Accounting Education, November 2003, pp. 427-41. (source of following slides)
Cookie-Monster (the customer) and
Elmo (the entrepreneur) engage in a
SHIPMENT (transfer of Cookie Inventory)
Give
Take
Economic Resource
inside
participation
outside
participation
outside
participation
inside
participation
stock-flow
stock-flow
Economic Event
Economic Agent
Economic Agent
Economic Agent
Economic Agent
Economic Resource
duality
Economic Event
REA model of cookie sale from
entrepreneurs (ELMO) perspective
Cookie-Monster (the customer) and
Elmo (the entrepreneur) engage in a
PAYMENT (transfer of Cash)
Give
Tak
e
Economic Resource
inside
participation
outside
participation
outside
participation
inside
participation
stock-flow
stock-flow
Economic Event
Economic Agent
Economic Agent
Economic Agent
Economic Agent
Economic Resource
duality
Economic Event
REA model of cookie sale from
entrepreneurs (ELMO) perspective
Give
Take
Economic Resource
inside
participation
outside
participation
outside
participation
inside
participation
stock-flow
stock-flow
Economic Event
Cash
Receipt
Economic Agent
Salespers
on
Economic Agent
Customer
Economic Agent
Customer
Economic Agent
Cashier
Cash
Economic Resource
Cookies
duality
Economic Event
Sale
more general exchange model from the entrepreneurs
(ELMOs) internal perspective
Product# Description Price QOH
P-1 Chocolate
Chip
1.05 200
P-2 Chocolate .95 205
P-3 Peanut
Butter
1.00 97
P-4 Pecan 1.10 257
Invoice
#
Receipt
Timestamp
Amount
Applied
I-1 2JUL0830 14.75
I-2 3JUL0800 2.00
I-2 5JUL0800 18.00
I-3 8JUL1145 9.90
I-4 8JUL1145 9.20
Invoice# Dollar
Amount
Date Salesperson
Employee#
Customer
#
I-1 14.75 1JUL E-1234 C-987
I-2 20.00 2JUL E-1235 C-888
I-3 9.90 3JUL E-1236 C-999
I-4 9.20 5JUL E-1237 C-999
Product# Invoice# Quantity
P-2 I-1 5
P-3 I-1 10
P-3 I-2 20
P-4 I-3 9
P-1 I-4 4
P-3 I-4 5
COOKIES
SALE
COOKIES-stockflow-SALE
SALE-duality-
CASH_RECEIPT
Partial Database for Elmos
Cookie Business
Why is this invoice amount $14.75 ??
How is customer paying for this ???
A business process is a set of activities that takes one or more
kinds of input and creates an output that is of greater value to the
customer (Hammer and Champy)
A value chain is a purposeful network of business processes
aimed at assembling the individual components of a final product
(i.e., its portfolio of attributes) of value to the customer (Porter
and Geerts/McCarthy)
Part of ELMOs Value Chain for Providing Cookies
cookie
ingredients
Acquisition
Cycle
cash
business process
labor
cookies
Conversion
Cycle
business process
Revenue
Cycle
cash
business process
value chain
Enterprise Systems classification structure is from David, McCarthy & Sommer, Communications of the ACM, May 2003, pp. 65-9.
Enterprise
Systems
No Organizing
Rationale Outwardl y
Organized
Single Entry
Transactions
& Obligations
A = L + OE
Enterprise
Value Chain
Bookkeeping
Modular
Integration:
ABC, MRP
ERP
Supply
Chain
Multi-
dimensional
Accounting
Hybrid
Inwardly Oranized
Best of
Breed ERP
Integrator-
Enabled
Standards-
Enabled
Singl e
Source
ERP
Customer
Focused
MS Money
Quicken
Peachtree
Quickbooks
Platinum
Solomon
Peopl eSoft
SAP
OMG
OAG
Siebel
Goldmine
i2
Ariba
Constellar Hub
Vitri a
BPCS
Great Plains Dynamics
Tradi ng
Partner
Independent
ebXML
ISO Open -EDI
Semantic infrastructure of system
matches extended REA pattern
Different perspectives on REA modeling
needed for enterprise modeling (value chains)
and collaboration space (supply chains)
Enterprise modeling (as evidenced in normal ERP systems) is done
from the perspective of one company or entrepreneur. Business
processes are viewed as components of a single value chain. A single
exchange (like the sale of a product for money) would be modeled
twice, once in the enterprise system of each trading partner.
Collaboration space modeling (as evidenced in ebXML or ISO Open-
edi) is done from a perspective independent of each trading partner. A
single exchange is modeled once in independent terms that can be
then mapped into internal enterprise system components. Supply
chains are networks of business processes that alternate internal
transformations and external exchanges (definition due to Bob
Haugen).
REA modeling works in both cases and the independent to trading
partner mapping is absolutely straightforward and completely defined.

Business
Process
Business
Process
Business
Process
Business
Process
Business
Process
Business
Process
Independent view of
Inter-enterprise events
Enterprise
Enterprise
Enterprise
Business
Process
Business
Process
Business
Process
Illustration of Perspective: Trading Partner vs. Independent
Trading Partner view of
Inter-enterprise events
(upstream vendors and
downstream customers)
Blue arrows represent flow of goods, services,
and cash between different companies; green
arrows represent flows within companies
SOURCE: Adapted from ISO 15944-4, K. Morita
Used for
collaboration space
modeling
initiating transfer
Economic Resource
from
to
to
from
stock-flow
stock-flow
Economic Event
Economic Agent
Economic Agent
Economic Agent
Economic Agent
Economic Resource
duality
Economic Event
REA model of cookie sale from independent
(collaboration space) perspective
responding transfer
Ontological Extensions to the REA
Model (Geerts and McCarthy)
Type images for basic objects allows
specification of policies and controls plus
abstract specification of negotiation
components
Commitment images for economic events
allows specification of contracts and
agreements
State machine model allows specification and
ordering of business events as collaboration
space messaging and/or internal workflow
Aggregation of binary collaborations allows
mediated collaboration with third parties
SOURCE: Geerts and McCarthy, The Ontological Foundations of REA Enterprise Information Systems, 2003.
ISO Open-edi Ontology Collaboration Model
Bilateral
Collaboration
governs
Economic
Event
Economic
Resource
Economic
Agent
stockflow
from
to
Economic
Contract
Economic
Commitment
reciprocal
fulfills
establish
duality
Economic
Resource
Type
typifies
specifies
Economic
Event
Type
Business
Role
specifies
specifies
typifies
qualifies
reserves
involves
Partner Third
Party
Mediated
Collaboration
Business
Transaction
participates
requires
Agreement
Regulator
constrains
SOURCE: Adapted from ISO 15944-4, W.E. McCarthy
Cookie-Monster and Elmo after their
economic exchange (both economic agents
have now reached higher levels of utility)
Cookie Monster and Elmo are of course
characters from the Public Broadcasting Service
TV show Sesame Street*. Their use here is
only illustrative. Cookie Monster is a great
example of a typical buyer (has money, wants
goods) because he is most happy when he has
a cookie to eat. The use of Elmo as a typical
seller (has goods, wants money) is only a
convenient illustration.

* see http://www.sesameworkshop.org
Online resources:

AIS Romney 2006 notes Chapter15
Database Design Using the REA

AIS Romney 2006 notes Chapter 16
Implementing an REA