Three “Events” That Define an REA Methodology for Systems Analysis, Design, and Implementation

Three “Events” That Define an REA Methodology for Systems Analysis, Design, and Implementation by Julie Smith David Arizona State University October 18, 2022 Preliminary, please 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 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 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 Upper case words are used to designate specific components of the Merchant of Venice business 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 - Insert Figure Here Figure 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 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 Here Figure 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 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 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 for the diagram showing the first step in integrating the Merchant of Venice’s individual REA diagrams - Insert Figure 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 more thorough representation of the firm that focuses on its value chain, rather than accounting conventions2 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 These difficult questions must be faced even in firms as simple as the Merchant of Venice In Figure 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 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 its costs This terminology and the analogy from Covey (1989) was recommended by Andrew Kristich 10 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 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, firms that have fewer information events receive benefits? How many business-level events are being performed in organizations, and how 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 24 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 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 (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 (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 Grabski, S.V and R.J Marsh 1994 Integrating accounting and manufacturing information systems: An ABC and REA-based approach Journal of Information Systems (2): 6180 25 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 26 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 27 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 Employee Service Get Employee Service Manager 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 S Deck Hand Get Employee Service Employee Service Manager Ship Builder Manager Ship Buy Ship Figure 5: Completed Economic Event-level Diagram for the Merchant of Venice 32 33 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 34 Call on Cust Salesperson Customer Take Order Manager Get Silk Silk Silk Seller Manager Cash Disbursement Deliver Silk Cash Receipt Cash Investor Use ES Manager Customer 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 35 Table Key Characteristics to Differentiate Traditional and REA Accounting Information Systems Support all critical events Store a detailed history of events Store the data in an integrated data repository Have the ability to retrieve and manipulate the data to meet users needs Process the events as they occur Directed REA design and implementation Prepare the financial statements without journal entries and a general ledger Source: David 1995 36 Table I Overview of the REA Design Methodology 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: “Overlay” duplicate entities Several entities (rectangles) can be drawn to represent the same resource, event, or agent if it makes the diagram more manageable Analyze each Event to ensure that the duality relationships between the “gives” and “takes” are maintained 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 37 Table 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 38 ... 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.. .Three “Events” That Define an REA Methodology for Systems Analysis, Design, and Implementation ABSTRACT While the original representation of the REA theory of accounting... 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