Three “Events” That Define an REA Methodology
for Systems Analysis, Design, and Implementation
by
Julie Smith David
Arizona State University
August 25, 1999
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 non-financial 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.
32
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 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 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 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 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 CASH[1] 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.
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 ---
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 company-wide 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.