Three “Events” That Define an REA Methodology
for Systems Analysis, Design, and Implementation
by
Julie Smith David
Arizona State University
February 6, 2016
Preliminary, please do not quote without the author’s permission.
The author would like to thank the students at Arizona State University and the participants of
the ASU REA Research Roundtable for both their patience with earlier versions of this paper and
their thoughtful suggestions. The insights provided by Joe Schultz and an anonymous reviewer
are also appreciated very much.
Three “Events” That Define an REA Methodology
for Systems Analysis, Design, and Implementation
ABSTRACT
While the original representation of the REA theory of accounting (McCarthy 1982)
included explicit definitions for resources, events, and agents, other researchers have extended
and modified the theory. This paper builds upon this literature to explicitly identify and define
three different types of events: economic events, business events, and information events.
Economic events are those which change the quantity of a resource, such as sale and cash receipt.
Business events are additional events that provide the organization with new information which
management can use to better plan, monitor, and control the economic events. For example,
place purchase order is a business event because it provides management with new information:
goods are scheduled for receipt, and prices are negotiated. Information events are processes that
are performed solely to capture or communicate information about the business and economic
events. These include activities such as generate invoice, print A/R aging report, and display
customer history.
An REA methodology is then developed to illustrate how these three levels of analysis
can be used for systems design and implementation projects. By restricting early analysis to the
economic events, value-added activities are identified. When expanding the analysis to include
business and information events, one is required to justify every additional process necessary to
implement an economic event. Therefore, this methodology can provide a framework for
implementing world-class solutions such as reengineering.
This research is valuable to both academics and practitioners. This methodology can be
used in practice to help design and implement systems that will support both financial and nonfinancial information needs. In addition, using the REA methodology to guide systems projects
will force management to recognize implementation compromises every time they add an activity
to a business process or modify the system to reduce their ability to trace costs. This
methodology also provides a framework for academics. By developing more precise definitions
of events and the REA methodology, future empirical REA research could incorporate these
definitions to design more rigorous tests of the costs and benefits associated with implementing
REA systems.
Three “Events” That Define an REA Methodology
for Systems Analysis, Design, and Implementation
INTRODUCTION
The accounting profession is undergoing radical change as it strives to provide value in
today’s automated society. Many argue that financial measures of performance are no longer
adequate and the profession must expand its domain if it is to continue (although this discussion
was initiated over 20 years ago, recent examples include Eccles 1991 and Elliott 1994). In
response to these concerns, there has been a call to expand the scope of Accounting Information
Systems. For example, Stambaugh and Carpenter (1992) discuss the importance of executive
information systems in organizations and opportunities for accountants to design, implement, and
control the data necessary to support senior management. Rather than merely focusing on
financial analysis, Brecht and Martin (1996) identify opportunities for accountants to participate
in the development of strategic systems that focus more on business opportunities.
In the midst of these rising concerns, McCarthy (1982) proposed an alternative approach
to capturing information about accounting phenomena. Rather than focusing on debits and
credits, which by design omit important data about economic events, he recommended capturing
the detail about each resource under the firm’s control, the events that change the amount of each
resource, and the agents who participate in these events (termed REA analysis for Resources,
Events, and Agents). Since REA was introduced, many papers have been written that provide
REA system implementations (Gal and McCarthy 1983 and Denna et al. 1992), rigorous
applications of REA (Denna et al. 1994 and Grabski and March 1994), and empirical analyses of
REA (Dunn 1994 and David 1995). As a result, more people have been exposed to the concepts,
the ideas are becoming more accepted, and they are being integrated into today’s accounting
3
information systems texts (Hollander et al. 1996, Gelinas and Oram 1996, and Romney et al.
1997).
The REA framework can be used for more than designing databases. Adopting this
approach enables accountants to become valued business partners, shifting our focus from
financial performance and control to a broad business focus, as recommended by Brecht and
Martin (1996). This paper illustrates how the REA concepts can be used as a guide during
business analysis and can help identify strategic opportunities for organizations.
The first step in describing the REA methodology for business analysis is to provide
explicit definitions of each construct in the model, and to show how these constructs work
together. This is important because some of the definitions of REA have been modified, the
overall template has been expanded, and some of the initial concepts have been de-emphasized.
For example, in Denna et al. (1993), the definition of “events” is broader than McCarthy’s (1982)
definition of event, and location has been added, expanding the model to “REAL” analysis.
The second focus of this paper is to provide a methodology that will incorporate the
different definitions of events to describe two different stages of REA analysis. This REA
methodology is a flexible tool for understanding businesses, guiding new system design projects,
and structuring accounting information systems courses. Adopting this approach to accounting
will change more than the data that is captured by accountants. It will help accountants to
embrace a business focus and assist in strategic decisions critical to firm success.
The following section of this paper provides an overview of the REA approach to
accounting. It defines and describes three different types of events that are critical to today’s
businesses: economic events, business events, and information events. Section III of the paper
provides an overview database implementations from REA diagrams. The next section
4
summarizes the methodology while the fifth describes how it may be applied to current business
process analysis in reengineering projects. Conclusions and extensions are discussed in the final
section.
DEFINING “EVENTS” IN REA ANALYSIS
To successfully analyze an organization and redesign its systems, a delicate balance must
be made between learning enough about the business to understand the forces that drive its
operations, and focusing too much on the current environment. If the analyst does the former,
she may be unable to meet current users’ expectations of future systems. If the latter is
performed, it is more difficult to identify radical, creative solutions that break with tradition
(Yourdon, p. 322). REA can be a powerful tool in this process because it can be used perform
value chain analysis (Porter 1985). With REA analysis, analysts and managers limit their view of
their complex organizations to their most basic elements, highlighting activities that consume
valuable resources while adding value for customers. In addition, the REA methodology forces
designers to critically evaluate every non-value adding activity.
A key to using an REA approach in business analysis projects is understanding three
different types of events that are important to organizations: economic, business, and
information. By understanding the differences between these events, users are able to prepare
documentation at varying levels of detail, analyze the organization’s key business processes, and
communicate several types of business information to users. The following subsections will
define the three different classes of events and how they relate to the REA design methodology.
These definitions will be illustrated with a simple, hypothetical company: The Merchant
of Venice. This company has one manager who receives funding from outside investors. His
goal is to purchase silk in China and sell it to the wealthy people in Italy. To accomplish this
5
goal, he first purchases a boat. Next he hires a deck hand to captain the ship to China and back.
While in China, the manager will negotiate with silk sellers and purchase silk. When the return
trip is completed, the manager will pay the deck hand, and sell the silk.
Economic Event-Level Analysis -- An Introduction to REA
Identify and Document Individual Exchanges
The first step in performing REA analysis to identify the events that increase or decrease
the quantity of a firm’s resources, termed economic events. Specifically, McCarthy (1982)
incorporated Yu’s (1976) definition of events: “a class of phenomena which reflect changes in
scarce means (economic resources) resulting from production, exchange, consumption and
distribution” (p. 562). Examples of economic events are sale, cash receipt, purchase, and raw
material issue.
Resources are defined as “objects that are (1) scarce and have utility and (2) are under the
control of an enterprise” (Ijiri 1975 as quoted in McCarthy 1982 p. 562). Common examples of
resources are cash, inventory, and fixed assets.
Agents are the third component in REA and are defined as those who participate in the
events. For each event, two agents must be identified: one within the business unit who was
responsible for the event, and the second, outside the business unit, with whom the event was
performed. The outside agent is often outside of the organization, such as a customer or vendor.
However, if the transaction is a transfer of resources between two business units, the internal
agent will be the one giving up the resource, while the external agent will be the one receiving it.
Identifying the individuals responsible for each transaction helps control the economic resources.
If there is a problem with the quantity of a resource, an auditor is able to trace the transactions to
individuals. Outside agents may be individuals, or, more likely, other firms that are interacting
6
with the firm being modeled. Examples of internal agents include salesperson, supervisors, and
clerks. Outside agents would include vendors, customers, and investors.
REA analysis is also used to document why the firm exchanges resources with outside
agents. Every time the firm reduces the quantity of a resource, its management expects to receive
something in return. Therefore, every event must be related to at least one other event that is the
other half of the economic exchange. The relationship between the increment and decrement
events is called a duality relationship, and the resulting pair of related events is an economic
exchange. For example, when the Merchant of Venice purchases silk, the manager must give
cash to the vendor who is providing the silk. Buying silk and paying cash are both economic
events because the change the quantity of resources. The relationship between these events is the
duality relationship that documents why the firm is willing to give the cash to the vendor. In
total, the two events and the relationship between them are an economic exchange.
In the Merchant of Venice, five exchanges are critical to the business. First, there is an
exchange of CASH1 with the INVESTORS (first the manager gets cash from them, and the
implication is that cash will be paid to them in the future). Second, there is an exchange of
CASH for SHIP, followed by CASH for EMPLOYEE SERVICE and CASH for SILK. Finally,
the manager will exchange SILK for CASH with his CUSTOMERS. Each of these exchanges is
composed of a pair of economic events: CASH RECEIPT - CASH DISBURSEMENT; BUY
SHIP - CASH DISBURSEMENT; GET EMPLOYEE SERVICE - CASH DISBURSEMENT;
PURCHASE SILK - CASH DISBURSEMENT; SELL SILK - CASH RECEIPT. Each of these
individual events is an economic event because the quantity of a resource is being increased or
decreased. When linked together with a duality relationship, they become economic exchanges.
7
It is important to recognize that the duality relationship between two events does not
mean that the events must happen simultaneously, or that one is a precursor to the other. For
example, the merchant enjoyed the EMPLOYEE SERVICE throughout the venture to and from
China. The CASH DISBURSEMENT occurred at a later date.
REA systems are often documented with entity-relationship diagrams. Each resource,
event, and agent can be modeled as an “entity” (shown as a rectangle). The relationships
between the entities are represented by diamonds. This technique can be used to model the
exchanges performed in the business. For example, the Merchant of Venice’s exchanges are
documented in Figure 1.
--- Insert Figure 1 Here --Figure 1 only shows the economic events and the duality relationships between them.
This type of diagram is referred to as an entrepreneurial script of the firm (Geerts and McCarthy
1995). Complete economic event-level REA diagrams also include resources and agents,
following the pattern for the “generic” REA diagram shown in Figure 2. This diagram shows the
essential components of an economic exchange and can be used as a template for developing
REA diagrams of organizations.
--- Insert Figure 2 Here --Figure 3 shows an expanded entrepreneur script for the Merchant of Venice with the
resources and agents added. Each of the exchanges is modeled separately, and each diagram
follows the generic REA template.
---- Insert Figure 3 Here ---
1
Upper case words are used to designate specific components of the Merchant of Venice business.
8
Perform View Integration
As discussed, the first step in REA analysis is identifying each economic exchange and
modeling them individually, following the REA template. Once that analysis is complete, view
integration must be performed to consolidate the individual exchange diagrams into a companywide diagram. The resulting diagram should show all of the events that affect the quantity of
resources, and all of the organization’s exchanges.
Initially, the integration is performed by linking the individual REA diagrams by their
common entities such as CASH or CASH DISBURSEMENT. See Figure 4 for the diagram
showing the first step in integrating the Merchant of Venice’s individual REA diagrams.
--- Insert Figure 4 Here --To complete the view integration process, the analyst must perform additional analysis to
insure the completeness of the resulting diagram. First, every resource must be studied to
determine if the analyst has identified at least one event to increase the quantity of the resource,
and at least one event to decrease the quantity.
Second, the analyst must verify that every economic event participates in a duality
relationship so there is a complete picture of how the company produces value. During this
process the designer will often be faced with difficult decisions. Why did the firm purchase fixed
assets? How did the firm use of its employee service? These questions are often avoided in
traditional accounting systems either through expensing the resource or applying its usage with
some allocation method. In REA analysis, the analyst attempts to be more precise and develop a
9
more thorough representation of the firm that focuses on its value chain, rather than accounting
conventions2.
These difficult questions must be faced even in firms as simple as the Merchant of
Venice. In Figure 4 the analyst has only documented how the EMPLOYEE SERVICE and SHIP
resources are incremented. How were these resources “used up”? They were needed to sail to
China; they were “used up” during the course of the sailing venture. Therefore, the analyst
could add an entity to the diagram to represent the economic event, SAIL SHIP, defined as the
occurrence in time in which decreases the quantity of our SHIP. This does not mean that the
whole ship was used during one venture, but it is the actual sailing of the ship that causes the
wear and tear on the ship. A second event, USE EMPLOYEE SERVICE could be added to
represent the decrement to the EMPLOYEE SERVICE resource.
As is common in business processing, these two decrement events occur simultaneously,
and the firm must expend a bundle of resources to successfully sail to China. The SHIP could
not sail without the DECKHAND. Therefore, an additional relationship can be added to the
diagram to show the link between the two new events. This relationship is an example of a new
type of relationship: synergy relationships3. These relationships are defined as describing
multiple events that occur in conjunction with each other and result in the whole being greater
than the sum of the parts. As discussed in Covey (1989), synergistic situations can lead to
creative solutions to problems and better overall performance than either party could enjoy
2
As discussed in McCarthy 1982, it may not be cost justified to implement a system that captures this detail.
However, the E-R diagram should be a model of the business and should show the complete representation of how he
firm operates. If necessary, the system may be simplified during the implementation phase. However, all involved
in the project should realize that every compromise moves the firm away from complete traceability of its costs.
3
This terminology and the analogy from Covey (1989) was recommended by Andrew Kristich.
10
individually. In the Merchant of Venice, the SHIP and the EMPLOYEE SERVICE were not able
to provide value to the firm until they were used together.
Once the sailing venture is included in the REA diagram, the analyst must confirm that
every event on the diagram participates in a duality relationship. In other words, the analyst is
going to document what the firm received in exchange for every decrement event so all duality
relationships will be recognized. Having added the SAIL SHIP and USE EMPLOYEE
SERVICE events, the analyst must identify what was received as a result of these events. The
manager was willing to perform the sailing venture because he had identified it as the optimal
method to purchase the silk. In other words, the new decrement events should be related to the
GET SILK event. As shown in Figure 5, this representation shows that more resources were
needed to get the SILK than just CASH. To determine the full cost of the SILK, one must also
consider the costs associated with the SHIP and the EMPLOYEE SERVICE required for the
sailing venture.
--- Insert Figure 5 Here --If a system is created from this diagram, it would capture the economic realities of the
sailing venture. It would treat the SHIP and EMPLOYEE SERVICE resources very differently
from a traditional accounting system. Historically, accountants have used depreciation to match
fixed asset expenses, such as the SHIP, to revenues. This was an attempt to communicate the
fixed asset’s long term value to the firm, but was an arbitrary estimation of how much cost was
associated with sales. As our information technology has evolved, however, it is possible to
capture more direct measures of asset usage. In an REA system, we would attempt to identify
how the costs were incurred, identify what was received in exchange, and capture the data
necessary to track this phenomenon. In the case of the Merchant of Venice, we would match the
11
costs of sailing the SHIP with SILK purchases. We may have to estimate costs based on the
number of sailing ventures we expect the ship to make, but the SILK purchased during each
venture would incur its share of the SHIP’s costs.
EMPLOYEE SERVICE is also handled differently in a complete REA system. The
analyst identified the exchange of GET EMPLOYEE SERVICE and CASH DISBURSEMENT
when evaluating payroll processing. The REA template forced her to recognize the resource
EMPLOYEE SERVICE that is being received by the firm in exchange for CASH. Notice that
while EMPLOYEE SERVICE’s existence is short-lived, it is a resource because it meets the
necessary criteria: it is scarce, provides utility, and is under the firm’s control. If EMPLOYEE
SERVICE was included in the initial analysis, the analyst will recognize that there must be at
least two events related to it during the view integration process. One event must increase its
quantity (GET EMPLOYEE SERVICE), and another will represent how it is used. This
decrement event may not have been identified otherwise. In the case of the Merchant of Venice,
the reduction of EMPLOYEE SERVICE was represented as part of the economic event USE
EMPLOYEE SERVICE that supports the BUY SILK and SAIL SHIP events.
Business Event-level Analysis
For simple organizations, their economic event-level REA diagram would describe all of
the processes in their organization. For example, the Merchant of Venice travels to vendors to
buy goods and later sells them directly to customers; the integrated diagram in Figure 5
adequately describes the processes performed. However, as businesses become more complex,
more activities are often involved in an exchange than the simple give and take. For example,
assume the Merchant chooses to start taking customer orders prior to sailing to China. In
addition, he hires salespeople to make cold calls on potential customers, hoping to interest them
12
in fine silk products. The information gathered during these new activities is critical to the
Merchant’s ability to manage the business, but would not have been included in the economic
event-level REA diagram.
Therefore, once the economic event-level diagram of an organization is completed, a
lower level of analysis is needed before a database can be developed or procedures can be
formalized. During this phase of analysis, the definition of event will be expanded to include the
business events that are important to the organization.
Business events are defined as “any business activity that management wants to plan,
monitor, and evaluate” (Denna et al. 47). These events result in changes to the physical world
and provide new information that can be used by the firm’s management to make decisions. This
definition of event includes all of the economic events already discussed. However, they should
continue to be designated as “economic events” because that term is more precise term and
identifies those events used to produce financial information. A business event-level diagram,
therefore, will contain all of the economic events identified in the first phase of analysis, but will
be supplemented with the additional business events.
Examples of business events include requisition goods, place purchase order, and take
customer order. In each of these cases, the events provide management with a better
understanding of future economic events. For the more complex Merchant of Venice, TAKE
CUSTOMER ORDER is an event in which the manager and the customer commit to two future
economic events: it is a promise that the Merchant of Venice will provide SILK to the
CUSTOMER, and that the CUSTOMER will provide a certain amount of CASH for each unit of
SILK they receive. No resources are increased or decreased at the time the TAKE CUSTOMER
ORDER occurs, so this is not an economic event. However, this is a business event because
13
once the order is placed, there is new information available to help management plan, monitor,
and evaluate operations. For example, the Merchant will be able to purchase the exact SILK the
CUSTOMER wants rather than estimating demand. Scheduling sailing ventures may be based
on projected sales volumes from the customer orders. By tracking orders, trends in silk
preferences may be identified more quickly, and the Merchant can take proactive steps to better
manage the revenue process. Finally, he may be able to control the sales process by validating
customers, monitoring credit limits, etc. during the TAKE CUSTOMER ORDER business event.
The general relationship between economic and business events is that one economic
event may be supported with several business events. Therefore, analysts should first document
the firm’s economic exchanges. Once that is completed, they can critically evaluate the business
events. To illustrate this relationship, an economic-level and a business-level diagram of the
Merchant of Venice’s revenue cycle are shown in Figure 6.
--- Insert Figure 6 Here --Continuing the Merchant of Venice example, the analyst studied the sales processing and
identified two events that were necessary to complete a SALE event. First, she identified the
DELIVER ORDER event as the occurrence that actually decreases the quantity of SILK.
Therefore, she renamed the economic event, SALE, as DELIVER ORDER to describe more
explicitly this economic event. Then she documented the additional business event, TAKE
CUSTOMER ORDER, necessary to perform the economic event, DELIVER ORDER. In the
economic event-level diagram shown in Figure 6, there was only one entity used to represent the
transfer of inventory to the customer. This single economic event is decomposed into two events
(highlighted within the dashed square) in the business event-level diagram.
14
The analyst also has identified a business event that was not explicitly part of the sales
processing but was important to the revenue cycle: CALL ON CUSTOMER. This is an event
that is performed by a SALESPERSON who travels to the CUSTOMERS, making cold calls.
The Merchant wants to evaluate SALESPERSON productivity, so it is important to monitor how
many CALL ON CUSTOMER events each SALESPERSON performs, and what INVENTORY
items are discussed during these calls. This information could also be valuable for making
promotion decisions, training programs, etc. Therefore, the Merchant of Venice needs to capture
information about the CALL ON CUSTOMER event, even though it is not directly related to
individual sales and does not have a direct effect on any resource other than salespeople’s time.
See Figure 7 for the Merchant of Venice’s complete business event-level REA diagram.
--- Insert Figure 7 Here --While there is a wide range of additional events that are also included in the business
event category, the goal of the organization should be to have as few business events as possible
to perform the economic event. For example, the best business process of a SALE would be to
have the exact inventory the customer wants materialize at the customer’s site when the customer
places the order. Unfortunately, this is not often possible except in the Star Trek world of
replicators and transporters! As a result, many firms must compromise and add additional
business events such as TAKE CUSTOMER ORDERs, and then, at a later time, actually
transport the goods to the customer.
The business-level REA diagram is a more detailed view of the organization than the
economic event-level REA diagram. However, it should still contain the important information
from the economic event-level diagram. As such, business-level REA diagrams should include
the duality relationships between the economic events, and one should be able to trace the
15
quantity of resources through all of their increases and decreases. Therefore, the basic
framework of the economic-level REA diagram is maintained in this more detailed diagram.
Information Event-level Analysis
Information events4 are the third type of events encountered in organizations during
systems analysis projects. These events are defined as “procedures that are performed in
organizations solely to capture, manipulate, or communicate information.” The key distinction
between these events and business and economic events is that no new data is identified
(although the previously identified data may be captured or summarized and reported), and
nothing changes in the physical that the REA diagram has not already described. This type of
event includes the specific implementation methods for capturing data about the resources,
events, and agents, as well as any report generation performed with the data in the system. For
example, if management has identified CUSTOMERS as an important agent to their
organization, the steps performed to gather the information about a customer would not be
included in the diagram (such as COMPLETE CUSTOMER CREDIT APPLICATION).
Another example of an information event is preparing customer invoices. This is a
procedure that management has argued must occur for proper internal control and is performed
by most modern organizations. However, it is neither an event that changes the quantity of a
resource nor supports the transfer of resources. All that it does is communicate information
about what has already occurred: some quantity of goods has been given to the customer, and
they are required to pay a certain amount per unit that was negotiated at the time of the
CUSTOMER ORDER. In fact, both parties already know this information (the organization
through the shipment of the goods, and the customer through their receipt), so neither
16
organization should reflect the sending or receiving of the invoice as a business or economic
event. Rather, each company’s system should maintain the transaction details about the
inventory and cash transactions. If the detailed records and the duality relationship between the
event tables are maintained, the system can calculate the accounts receivable or accounts payable
balances as the difference between the resources received and given. For example, a customer’s
accounts receivable balance would be calculated by summing all of their SALES records, then
subtracting the sum of the CASH RECEIPT records for that customer.
REA diagrams should not be used to document information processes. Their strength lies
in modeling the activities that actually occur and helping management evaluate them.
Information processes, on the other hand, while perhaps necessary in organizations, are merely
processes that either capture or use the information captured about the resources, events, and
agents. While the data required is a design issue, how one chooses to physically capture or report
the information is an implementation issue.
If management determines that these events are required (and only after careful, critical
thought), then other documentation approaches will provide more information about how they
are implemented. For example, systems flowcharts or data flow diagrams could be developed to
show how the actual information processes are performed, and how information is
communicated both within and among organizations.
DATABASE IMPLEMENTATIONS5
Once the resources, business and economic events, and agents have been modeled, the
design phase of the REA analysis project has been completed. Next, the analyst must evaluate
4
5
These are called “information processes” in Denna et al. 1993.
Much of this section is from David 1995.
17
how to implement the system. This discussion provides a brief overview of a database
implementation process.
First, all of the necessary data about each of the entities should be identified. For
example, all of the data about CUSTOMERs that would be required by the Merchant of Venice
and its salespeople should be identified. CUSTOMER attributes could include name, address,
credit limit, contact name, and phone number. Similar analysis would be performed for each
entity and relationship in the firm’s entity-relationship diagram.
After the important data are identified, the organization’s REA accounting database can
be created by implementing each entity, relationship, and attribute in a centralized data
repository. If using database technology, one table would be created for each entity on the
organization’s business event-level diagram. In addition, the relationships between the entities
must be implemented.6 Once the tables are created, details of each event would be stored as
records within the tables. Once application programs are developed to enter, store, manipulate,
and report this data, an REA accounting information system can provide detailed information
about the business. The records in this database could be sorted and summarized to generate the
same information as in journal entries in a traditional accounting system. However, additional
“views” of the data are available for other system users with different information needs. As a
result, both financial and non-financial information about events can be accessible to all systems
users.
This illustrates how REA accounting systems store much more data than traditional
accounting systems. To a large extent, the main difference between an REA accounting system
and a more traditional one is when data are “filtered.” In an REA accounting system, less
18
transaction data is filtered before they are stored. The majority of the filtering occurs later when
reports are generated and only the information needed for the report is used. For example, SALE
data can be grouped and summarized by sales person for the sales manager, or by customer for
the marketing manager. If the relationship between SALE and INVENTORY is also
implemented, the data may also be sorted by product for the production manager. In addition,
the data could be summarized to prepare the financial statements when needed by management or
to meet demands by outside institutions (such as the SEC, etc.).
On the other hand, traditional accounting systems place a filter on the data before they are
stored in the system. The journal entries used to store the data limit event attributes to periodic,
summarized financial amounts that can be entered into the General Ledger by account number.
Therefore, the information that can be reported is limited to the account information that is stored
in such a system.
--- Insert Table 1 Here --Difficult decisions regarding implementation must be made. Several characteristics of
REA systems were identified in David (1995), and are shown in Table 1. During
implementation, the analyst and managers must perform cost-benefit analysis to determine if
each characteristic should be included in the resulting system. For example, analysts must
determine the best method for capturing the data. In general, capturing data at its origin is
preferable over any method that adds a time lag between the processes and their information
capture. If done in real time, the database users will be able to see a clear view of the
organization any time they process a query.
6
For more information about creating data base tables from E-R diagrams, see Chapter 6 in Romney et al 1997 or
McCarthy 1979.
19
If this design methodology is used throughout the project, the resulting system should
efficiently processes the critical business and economic events of the organization. The resulting
organization should be streamlined with the elimination of unnecessary business and information
events. By integrating the data, and providing users with a tool with which to extract the data,
the information events should be kept to a minimum. Users will be able to answer their
questions when they arise, and resources will not be spent generating reports that are never used.
CONSOLIDATION OF CONCEPTS: REA AS A DESIGN METHODOLOGY
Once one understands the unique characteristics of economic, business, and information
events, REA can be used as the foundation of systems design and business process analysis
projects. A general framework for this methodology is presented in Table 2. Points one through
three summarize the analysis steps, while the remaining steps describe implementation issues.
--- Insert Table 2 Here ---
METHODOLOGY EXTENSION: REENGINEERING
As has been discussed since the early REA papers, REA analysis and the resulting E-R
diagrams can be followed by data analysis and database implementation to produce an integrated
data repository. The data can be used to produce financial statements and non-financial reports
to support both predetermined and ad hoc management needs (McCarthy 1982). However, the
REA methodology can also aid reengineering projects.
Reengineering is defined as “the fundamental rethinking and radical redesign of business
processes to achieve dramatic improvements in critical, contemporary measures of performance”
(Hammer and Champy 1993, 32). While this has enjoyed wide-spread coverage (Hammer and
20
Champy 1993, Davenport 1993, and Coulson-Thomas 1994), one of the most difficult steps in
reengineering is the identification of processes that are good candidates for reengineering.
Hammer and Champy (1993) define a process as “a collection of activities that takes one or more
kinds of input and creates an output that is of value to the customer” (p. 35). Unfortunately, they
admit that many organizations are unable to think in this fashion because they are too focused on
the individual tasks that are performed throughout their organization. They are not able to think
at a high enough level to identify a process (Coulson-Thomas 1994, 118-119; Davenport 1993,
7). When they document their current systems with traditional techniques such as flowcharting,
they often prematurely focus on the details (Hammer and Champy 1993, 118-119).
REA analysis can help guide reengineering projects because a process is an economic
exchange, represented by increment and decrement events linked with a duality relationship. By
definition, an exchange represents what resources the firm is using (inputs) in order to increase
other resources (outputs). In addition, integrated economic event-level diagrams show how
resources that are acquired through one exchange are used in another. The agents in the second
exchange are actually the customers for the first. Consider purchasing inventory as an example.
The firm is willing to use CASH to PURCHASE INVENTORY. Thus, INVENTORY is the
output of this exchange. If this company manufactures FINISHED GOODS, the agents in the
manufacturing exchange (USE INVENTORY - MAKE FINISHED GOODS) are the customers
of the purchasing exchange. Any reengineering project concerning the purchasing process must
consider the demands of the manufacturing agent to be successful. As this shows, starting with
an economic event-level diagram can help identify processes as potential reengineering projects.
After identifying a process for reengineering (an economic exchange), management must
identify how to minimize time and costs, improve quality, or whatever other characteristics
21
management has determined to be key to success. By continuing the REA analysis to the
business-level events, management is forced to justify each additional business or information
event that is added to the process.
To illustrate this use of REA, consider one of the most famous reengineering success
stories: Ford Motor Company’s reengineering of their accounts payable processing (Hammer
and Champy 1993, 39-44). Ford management discovered Mazda was able to process payables
with a fraction of the personnel that Ford used. Ford decided, therefore, to reengineer its process
to enjoy the same efficiencies. The first modification Ford made was to automate the receiving
activity so the receiving data was being entered in real time by the receiving clerks, rather than at
a later date from hand-written receiving reports. Next, they automated the 3-way match activity
so vendor invoice amounts were entered and electronically compared to the product of the
quantity of goods received (from the receipts file) and the unit cost of the goods (from the
purchase order file). By automating the process they enjoyed some productivity improvements in
their A/P department, but not the dramatic improvements they had hoped for. Their final change
was to recognize that they did not need to wait for the vendor invoice, but actually had the
information necessary to make a cash disbursement as soon as the inventory receipts were
entered into the system. As a result, they modified their system to automatically generate an
electronic funds transfer to the vendors, in effect pushing any 3-way matching back to the
vendors. Then Ford reaped the benefits!
In REA terms, Ford identified the economic exchange of get inventory (receipt) -- give
cash (cash disbursement) as one that had the potential for radical change. Had they performed
REA analysis at the start, they would have challenged each additional step (i.e., every business
and information event) in the process. The receipt of goods and cash disbursements are
22
economic events, and are necessary for this exchange to be completed. However, the entering of
a vendor invoice is merely an information event: it “double checks” information that should
already be in the system. As such, this is an event that should only be included if absolutely
necessary.
Hammer and Champy (1993) presented several other reengineering examples using
processes that could be identified by studying the critical REA exchanges (see Table 3 for a
summary). In each case, the firms identified a process, and worked to streamline it. The results
were quicker response times, more thorough data for analysis, and more efficient operations.
--- Insert Table 3 Here --To use REA in reengineering, management should first prepare an integrated economic
event-level diagram of their firm. Management should then evaluate the value provided by each
economic exchange. This analysis will be performed at a very high level. Next, they should
examine how their business accomplishes (or should accomplish) these processes by designing a
business event-level diagram of the activities. Their goal should be to add NO additional
business events during this process. If they resist adding extra events, they will streamline the
process, and reduce costs and time necessary to complete the exchanges.
Of course, these benefits only occur if the organization has an information system that is
able to generate the required information without incurring additional information steps. In
Ford’s case, they could not make automatic cash disbursements until their system stored the
inventory receipts and purchase orders, and had the capability of linking these events. Referring
back to Table 1, reengineering project success often hinges on information systems that capture
detailed event data and are able to provide integrated information when required.
23
CONCLUSIONS
This paper extends REA research by formalizing the relationships among three types of
events currently performed within organizations. By focusing on events that change the
organization’s economic reality, analysts will be able to assist organizations in streamlining their
processes and eliminating redundant or non-value adding activities. The resulting computerized
information systems will be able to support a wide range of user needs. Financial statements can
be generated by summarizing the detailed economic event data. Internal users will have access to
the detailed data to support ad hoc information requirements that arise throughout the system’s
life.
This work can be used in many situations. First, some consulting firms and organizations
are adopting REA approaches to their systems development projects. Price Waterhouse has
started a practice in “events-based” accounting information systems (Cherrington et al. 1993),
and IBM has modified their systems with input from REA researchers (Denna et al. 1992). As
these concepts are gaining acceptance, they must be communicated to a wider audience. By
presenting a generic methodology for use in systems development projects, this paper may
enhance other consultant’s understanding and opportunities.
To help meet this goal, the REA methodology can add precision to the definition of
“event” and to help students work with challenging REA problems. In addition, if the course is
reorganized with REA as the fundamental framework, students are able to begin with “simple”
situations (economic event-level discussions), graduating to more detailed process
representations (business event-level) of today’s organizations. A final section of the course can
focus on the opportunities available to accountants to provide value to firms they are working
24
with who, in turn, must provide value to their customers if they are to survive. The application
of REA to reengineering can illustrate its usefulness.
Finally, empirical REA research must continue to examine the relationship between the
REA systems and their more traditional counterparts. It would be valuable for researchers to
study differential benefits of systems which process each type of event. For example, do firms
that have fewer information events receive benefits? How many business-level events are being
performed in organizations, and how do their systems support these activities? Weber (1986) has
begun this work by examining Customer Order Processing systems, identifying the inclusion of
customer orders, thus extending the economic-events identified in earlier REA work. However,
there are many more opportunities for others to evaluate the model presented here.
25
References
Brecht, H.D. and M.P. Martin. 1996. “Accounting information systems: The challenge of
extending their scope to business and information strategy.” Accounting Horizons. 10
(4): 16-22.
Cherrington, J.O., W.E. McCarthy, D.P. Andros, R. Roth, and E.L. Denna. 1993. Event-driven
business solutions: implementation experiences and issues. Proceedings of the
Fourteenth International Conference on Information Systems. Orlando, FL. p. 294.
Coulson-Thomas, C., ed. 1994. Business process re-engineering: myth & reality. London,
England: Kogan Page Limited.
Covey, S.R.1989. The 7 habits of highly effective people. New York, NY: Simon & Schuster.
Davenport, T.H. 1994. Process innovation: Reengineering work through information
technology. Boston, MA: Harvard Business School Press.
David, J.S. 1995. An empirical analysis of REA accounting information systems, productivity,
and competitive advantage. Ann Arbor, MI: U.M.I. Dissertation Services.
Denna, E. D.P. Andros, and J.O. Cherrington. 1992. "Reengineer your accounting, the IBM way"
Financial Executive (July/August, 1992).
_____, E., J. Cherrington, D. Andros, and A. Hollander. 1993. Events-Driven Business
Solutions: Today's Revolution in Technology. Irwin, IL: Business One.
______, J. Jasperson, K. Fong, and D. Middleman. 1994. Modeling conversion process events.
Journal of Information Systems 8 (1): 43-54.
Dunn, C. 1994. An investigation of abstraction in events-based accounting systems.
Unpublished doctoral dissertation, Michigan State University.
Eccles, R.G. 1991. The performance measurement manifesto. Harvard Business Review,
(January-February): 131-137.
Elliott, R.K. 1994. Confronting the future: Choices for the attest function. Accounting Horizons
8 (3): 106-124.
Gal, G. and W.E. McCarthy. 1983. “Declarative and procedural features of a CODASYL
accounting system,” in Entity-Relationship Approach to Information Modeling and
Analysis, P. Chen (ed.), North-Holland. pp. 197-213.
Geerts, G. and W.E. McCarthy. 1995. “Use of an accounting object infostructure for
knowledge-based enterprise models.” Submitted to IEEE Expert.
Gelinas, U. J. and A. E. Oram. 1996. Accounting Information Systems, 3rd ed. Cincinnati, OH:
South-Western College Publishing.
26
Grabski, S.V. and R.J. Marsh. 1994. Integrating accounting and manufacturing information
systems: An ABC and REA-based approach. Journal of Information Systems. 8 (2): 6180.
Hammer, M. and J. Champy. 1993. Reengineering the Corporation: A Manifesto for Business
Revolution. NY, NY: HarperBusiness.
Hollander A., E. Denna, and O. Cherrington. 1996. Accounting, Information Technology, and
Business Solutions. Chicago, IL: Richard D. Irwin.
Ijiri, Y. 1975. Theory of Accounting Measurement (American Accounting Association). (Quoted
from McCarthy 1982).
McCarthy, W.E. 1979. An entity-relationship view of accounting models. The Accounting
Review (October): 667-686.
______. 1982. The REA accounting model: A generalized framework for accounting systems in
a shared data environment. The Accounting Review (July): 554-77.
Porter, M.E. 1985. Competitive Advantage, New York NY: The Free Press.
Romney, M., P. Steinbart, and B. Cushing. 1997 Accounting Information Systems. Reading,
MA: Addison-Wesley.
Stambaugh, C.T., and F.W. Carpenter. 1992. The roles of accounting and accountants in
executive information systems. Accounting Horizons. (September): 52-63.
Yourdon, E. 1989. Modern Structured Analysis. Englewood Cliffs, NJ: Prentice-Hall, Inc.
Yu, S. C. .1976. The Structure of Accounting Theory (The University Presses of Florida, 1976).
(Quoted from McCarthy 1982).
Weber, R. 1986. “Data models research in accounting: An evaluation of wholesale distribution
software.” The Accounting Review (July): 498-518.
27
Cash
Disbursement
Cash
Disbursement
Cash
Disbursement
Buy
Ship
Cash
Receipt
Sell
Silk
Get
Employee
Service
Cash
Disbursement
Cash
Receipt
Purchase
Silk
Figure 1: Exchanges Important to the Merchant of Venice
28
Inside
Agent
Stock flow
Resource
Event (-)
Control
Outside
Agent
Duality
Inside
Agent
Stock flow
Resource
Event (+)
Control
Outside
Agent
Adapted from McCarthy 1982
Figure 2: Generic REA Template
29
Manager
Get Financing
(Cash Receipt)
Cash
Investor
Cash
Disbursement
Cash
Manager
Manager
Ship
Manager
Buy Ship
Silk
Sell Silk
Ship
Builder
Cash
Customer
Cash
Disbursement
Cash
Manager
Cash
Receipt
Manager
Manager
Manager
Employee
Service
Get Employee
Service
Silk
Deck
Hand
Cash
Cash
Disbursement
Purchase
Silk
Silk
Seller
Cash
Cash
Disbursement
Manager
Manager
Figure 3: Individual REA Diagrams for the Merchant of Venice
30
Manager
Manager
Get Silk
Silk
Sell Silk
Silk
Seller
Manager
Customer
Cash
Disbursement
Cash
Cash
Receipt
Investor
Investor
Manager
Ship
Builder
Deck Hand
Get Employee
Service
Employee
Service
Manager
Ship
Buy Ship
Figure 4: First Step in View Integration
31
Manager
Manager
Get Silk
Silk
Sell Silk
Silk
Seller
Manager
Customer
Cash
Disbursement
Cash
Receipt
Cash
Use ES
Investor
Investor
Sail Ship
Manager
S
Deck Hand
Get Employee
Service
Employee
Service
Ship
Builder
Manager
Ship
Buy Ship
Figure 5: Completed Economic Event-level Diagram for the Merchant of Venice
32
Business Event REA
Economic Event
REA
Customer
Call on
Customer
Salesperson
Manager
Silk
Sale
Silk
Take
Customer
Order
Manager
Deliver
Order
Customer
Cash
Receipt
Manager
Customer
Cash
Cash Receipt
Manager
Cash
Figure 6: Relationship Between Economic Event and Business Event REA Diagrams
33
Call on Cust
Salesperson
Customer
Take Order
Manager
Manager
Get Silk
Silk
Deliver Silk
Silk
Seller
Manager
Customer
Cash
Disbursement
Cash
Receipt
Cash
Investor
Use ES
Investor
Sail Ship
Manager
Ship
Builder
Deck Hand
Get Employee
Service
Employee
Service
Manager
Ship
Buy Ship
Figure 7: Business Event-level Diagram for the Merchant of Venice
34
Table 1
Key Characteristics to Differentiate
Traditional and REA Accounting Information Systems
1. Support all critical events.
2. Store a detailed history of events.
3. Store the data in an integrated data repository.
4. Have the ability to retrieve and manipulate the data to meet users needs.
5. Process the events as they occur.
6. Directed REA design and implementation.
7. Prepare the financial statements without journal entries and a general ledger.
Source: David 1995
35
Table 2
Overview of the REA Design Methodology
I.
Economic event-level analysis
Identify economic exchanges.
II.
A.
Develop individual E-R diagrams for each exchange following the REA template. Be sure to
include all resources, even those which are not tracked in traditional accounting systems.
B.
Perform view integration of the exchanges:
1.
“Overlay” duplicate entities.
2.
Several entities (rectangles) can be drawn to represent the same resource, event, or
agent if it makes the diagram more manageable.
3.
Analyze each Event to ensure that the duality relationships between the “gives” and
“takes” are maintained.
4.
Analyze each Resource to identify, at a minimum, both an increase and a decrease.
Evaluate each economic event to determine if there are required business events.
A.
Be very critical before adding any business events.
B.
Do NOT include any information events. Instead, identify attributes about the resources,
events, and agents necessary to produce the information. Create the database with these
attributes, and identify the most effective method of capturing that data so it will be available in
the future.
III.
Supplement the economic events in the diagram with the business events.
IV.
Create a system to store the data.
V.
Capture the data about transactions as they occur so the data mirrors the activities in the business.
VI.
Provide users with access to the data.
A.
Create on-line inquiry screens for answers to standard, repetitive questions.
B.
Provide a query generation tool for non-standard question answers.
C.
Create reports only if necessary.
36
Table 3
Reengineering Examples from Hammer and Champy 1993
and Economic Exchanges Affected
Company
IBM
Process Reengineered
Credit application for
computer purchasers
Hallmark
Product development
Sales Analysis
Taco Bell
Eliminate production
activities and dining
facilities
Capital Holding
Customer service and
selling insurance
Human Resources performance appraisal
Sell Carrier Access
Bell Atlantic
Economic Exchange
Give Money (Loan)Get Money
(Payments)
Use Resources Make Cards
Sell Cards Get Money
Use Resources Make Tacos, and
Sell Tacos Get Money (key
focus for customer
value)
Sell Insurance Get Money
Get Employee Service
- Give Money
Sell Access Get Cash
37