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 ImplementationABSTRACT While the original representation of the REA theory of accounting McCarthy 1982 inc

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

by

Julie Smith David Arizona State University

August 9, 2024

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

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 capturingthe 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), rigorousapplications of REA (Denna et al 1994 and Grabski and March 1994), and empirical analyses ofREA (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 finalsection

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 toindividuals 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 iscomposed 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 theseindividual 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 toinsure 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

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 SHIPresources 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 relationships 3 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.

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

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

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 thebusiness 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 ofSILK they receive No resources are increased or decreased at the time the TAKE CUSTOMERORDER occurs, so this is not an economic event However, this is a business event because

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 businessevents 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 thetransfer 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

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 howmany 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 captureinformation 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

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 events 4 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

organization should reflect the sending or receiving of the invoice as a business or economic

4 These are called “information processes” in Denna et al 1993.

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 payablebalances 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 toshow how the actual information processes are performed, and how information is

communicated both within and among organizations

DATABASE IMPLEMENTATIONS 5

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 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 transaction data is filtered before they are stored The majority of the filtering occurs later whenreports are generated and only the information needed for the report is used For example,

6 For more information about creating data base tables from E-R diagrams, see Chapter 6 in Romney et al 1997 or McCarthy 1979.

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

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 resultingorganization should be streamlined with the elimination of unnecessary business and informationevents By integrating the data, and providing users with a tool with which to extract the data,