The REA Approach to Database Modeling:The REA Approach

The REA Approach

Central to the database philosophy is the recognition that corporate data should support the information needs of all users in the organization. An important aspect of data modeling, therefore, is creating a model that faithfully reflects the organization’s physical reality. This is not easily accomplished when different people within the organization see and use the same data differently.

You will recall from Chapter 9 that a user view is the set of data that a particular user needs to achieve his or her assigned tasks. For example, a general ledger clerk’s user view will include the organization’s chart of accounts, but not detailed transaction data. A sales manager’s view may include detailed customer sales data organized by product, region, and salesperson. A production manager’s view may include finished goods inventory on hand, available manufacturing capacity, and vendor lead times.

A problem arises in meeting these diverse needs when a single view that is inappropriate for entity- wide purposes dominates the collection, summarization, storage, and reporting of transaction and resource data. The accounting profession has long been criticized for focusing too narrowly on the role of accounting information. Many researchers today encourage the profession to shift its emphasis away from debits, credits, double-entry accounting, and GAAP and move toward providing useful information for decision making and helping organizations identify and control business risk.

Modern managers need both financial and nonfinancial information in formats and at levels of aggregation that the traditional GAAP-based accounting systems generally fail to provide. The response within many organizations to the dominant single view of accounting information has been to create separate infor- mation systems to support each user’s view. This has resulted in organizations with multiple information systems that are functionally disconnected. Often, data entered in one system need to be re-entered in the others. With such widespread duplication of data, accuracy and data currency issues pose serious problems.

Such concerns have led a number of database researchers to develop semantic models or frameworks for designing accounting information systems that support multiple user views. A semantic model cap- tures the operational meaning of the user’s data and provides a concise description of it. One such exam- ple, of great importance to accounting, is the REA model. In 1982, REA was originally proposed as a theoretical framework for accounting.1 Since that time, however, it has gained considerable attention as a practical alternative to traditional accounting systems.

THE REA MODEL

The REA model is an accounting framework for modeling an organization’s critical resources, events, and agents and the relationships between them. Unlike some traditional accounting systems, REA systems permit both accounting and nonaccounting data to be identified, captured, and stored in a centralized database. From this repository, user views can be constructed that meet the needs of all users in the organization. REA models may be implemented within either relational or object-oriented database architectures. For purposes of discussion in this chapter, we will assume a relational database as this is the more common architecture for business applications.

Figure 10-1 illustrates the basic REA model, which is a unique version of an entity relationship (ER) diagram consisting of three entity types (resources, events, and agents) and a set of associations linking them. From this point, we will refer to this documentation technique as an REA diagram. The conventions for describing associations, assigning cardinality, and normalizing tables as discussed in Chapter 9 for traditional ER diagrams also apply to REA diagrams.

Elements of an REA Model

RESOURCES. Economic resources are things of economic value to the organization. They are defined as objects that are both scarce and under the control of the enterprise. Resources are used in economic exchanges with trading partners and are either increased or decreased by the exchange.

EVENTS. REA modeling embraces two classes of events: economic events and support events. Economic events are phenomena that effect changes (increases or decreases) in resources as represented by the stock flow relation in Figure 10-1. They result from activities such as sales of products to customers, receipt of cash from customers, and purchases of raw material from vendors. Economic events are the critical information elements of the accounting system and must be captured in as disaggregated (highly detailed) form as possible to provide a rich database.

Support events (not shown in Figure 10-1) include control, planning, and management activities that are related to economic events, but do not directly effect a change in resources. Examples of support events include (1) determining inventory availability for a customer prior to making a sale, (2) verifying supporting information (performing a three-way-match) prior to disbursing cash to a vendor, and (3) checking customer credit before processing a sale.

AGENTS. Economic agents are individuals and departments that participate in economic and support events. They are parties both inside and outside the organization with discretionary power to use or dis- pose of economic resources. Each economic event is associated with at least one internal agent and one external agent who participate in the exchange. The respective roles of internal and external agents in transactions with outsiders are usually apparent. For example, in a sales transaction, the internal agents are various employees of the company and the external agent is the customer. For purely internal transactions, however, the roles of internal and external agent may not be so obvious. The convention in REA modeling is to treat such transactions as if they were sales. For example, in the transfer of products from work-in-process to finished goods inventory, the work-in-process clerk is viewed as selling the product to the finished goods clerk. Therefore, the clerk giving up control and reducing the resource (work-in-process clerk) is the internal agent and the clerk assuming control and increasing the resource (finished goods clerk) is the external agent.

Internal and external agents are also involved in support events, but the exchange involves information rather than economic resources. For example, a customer (external agent) checking on product prices receives information from the sales clerk (internal agent), who gives up the information. Linking internal agents to events in this way promotes control and permits organizations to assess the actions taken by their employees.

DUALITY. REA’s semantic features derive from the elements of an economic transaction. The rationale behind an economic transaction is that two agents each give the other a resource in exchange for another resource. In actuality, the exchange is a pair of economic events, which is expressed via the duality association shown in Figure 10-1. In other words, each economic event is mirrored by an associated economic event in the opposite direction. Figure 10-2 expands the basic REA model to illustrate the connection between these dual events: the give event and receive event. From the perspective of the organization

function being modeled, the give half of the exchange decreases the economic resource, as represented by the outflow association. The receive half of the exchange increases the economic resources represented by an inflow association. Figure 10-3 presents several examples of the give and receive events as they relate to the revenue, expenditure, and conversion cycles.

Note that an economic exchange does not require duality events to occur simultaneously. For example, inventory is reduced immediately by the sale to a customer, but cash may not be increased by the customer’s remittance for several weeks. The REA model accommodates credit-based transactions and the associated time lags, but does not employ traditional mechanisms such as AR or AP ledgers in accounting for these events. In fact, REA rejects the need for any accounting artifacts, including journals, ledgers, and double-entry bookkeeping. As mentioned previously, economic phenomena should be captured in a disaggregated form consistent with the needs of multiple users. To reflect all relevant aspects of economic events, therefore, business data must not be preformatted or artificially constrained. Journals, ledgers, and double-entry bookkeeping are the traditional mechanisms for formatting and transmitting accounting data, but they are not essential elements of an accounting database. REA systems capture the essence of what accountants account for by modeling the underlying economic phenomena directly. Organizations employing REA can thus produce financial statements, journals, ledgers, and double-entry accounting reports directly from event database tables via user views. We demonstrate how this is done later in the chapter.