Guido L. Geerts, Michigan State University


                                          William E. McCarthy, Michigan State University


                                              Stephen R. Rockwell, University of Florida




























We would like to thank for the referees for their comments and criticisms on earlier versions of this paper.  Financial support for this work was provided by Arthur Andersen LLP and the Department of Accounting at Michigan State University.










This paper summarizes and projects research in the field of automated software engineering as that work has been applied to the domain of accounting-centered enterprise models.  In particular, we review the basic concepts and goals of the REA (Resource-Event-Agent) accounting model and speculate on its past, present, and future use as an embedded domain theory of enterprise economic activity within computer-aided systems engineering (CASE) tools.  The REA CASE tools reviewed here include ones like REAVIEWS, CREASY, and REAtool that have already been built plus others like REACH, FREACC, and REAVERSE that have been specified only in theory.  The entire systems development life cycle is used as a discussion vehicle to treat these tools and projected future work in an integrated way.



KEY WORDS:  CASE tools, REA accounting model, value chain, enterprise modeling, data models, database design          









Building accounting systems, either by starting from scratch or by adapting existing application software, is a knowledge-intensive process performed primarily without the support of automated assistance.  As envisioned by Whitten, Bentley, and Barlow, CASE tools aim to partially rectify this problem:


            Computer-aided systems engineering (CASE) is the application of computer technology to systems development activities, techniques, and methodologies.  CASE "tools" are programs (software) that automate or support one or more phases of a systems development life cycle.  The technology is intended to accelerate the process of developing systems and to improve the quality of the resulting systems (1994, p.169).


The phases of the systems development life cycle (SDLC) that Whitten et al. refer to are these five (1994, pp. 101-2).


     1.    Systems planning whose purpose is to identify and prioritize those information systems applications whose development would most benefit the business as a whole.


     2.    Systems analysis whose purpose is to analyze the business problem or situation, and then to define the business requirements for a new or improved information system.   


     3.    Systems design whose purpose is to design a computer-based, technical solution that meets the business requirements as specified in the systems analysis.


     4.    Systems implementation whose purpose is to construct and/or assemble the technical components and deliver the new or improved information system into operation.


     5.    Systems support whose purpose is to sustain and maintain the system for the remainder of its useful life.


For data-intensive applications, which in an accounting context would mean that the provision and maintenance of a database of modeled accounting phenomena is a preeminent goal of any development effort, the enumeration of SDLC steps usually includes a slightly different grouping of steps (Lum et al. 1979; Batini, Ceri, and Navathe 1992): (1) Requirements analysis, (2) Information analysis and definition (also called conceptual design), (3) Implementation design (also called logical design), and (4) Physical design.  Researchers and practitioners who aim to improve CASE tools, either for the SDLC in general or for database design more specifically, tend to describe their efforts under the process headings most familiar to their constituencies.  Thus, Whitten et al. (1994) use the first categorization above, while Reiner (1992) uses the second.  In McCarthy, Rockwell, and Armitage (1989), these four data-intensive sub-steps were identified and integrated within a normal SDLC, and for the rest of this paper, we will use the Whitten et al. SDLC steps as major categories, but refer to data-intensive sub-steps in much the same manner that McCarthy, Rockwell, and Armitage (1989), Batini et al. (1992) and Reiner (1992) do.  We use this combined approach to highlight the important role of proper database construction for accounting systems.  Additionally, in a very approximate fashion, the data-intensive sub-steps of each phase correspond to the "data" column of John Zachman's framework for information systems architecture (Zachman 1987; Sowa and Zachman 1992), a framework referenced extensively by Whitten et al. (1994).  Therefore, we will use some of Zachman's prescriptions in describing normatively how accounting database design can be improved.  


Two recent papers have provided extended reviews of CASE use in database design.  Rosenthal and Reiner (1994) concentrate on a particular CASE tool -- the Database Design and Evaluation Workbench (DDEW) -- and use it as a vehicle to describe a variety of automated techniques and tools for comprehensive design.  They discuss some heuristic tools, but none of these are driven by enterprise models.  Storey and Goldstein (1993) reviewed twelve knowledge-based CASE tools for database design, but again they found little evidence of enterprise knowledge use.  In fact, when they categorized efforts in this area, one of their most homogeneous dimensions was domain independence with all but one of their twelve systems being rated as strong in this category.  Thus it appears that CASE use in the analysis, design, and operation of data-intensive information systems (like corporate accounting systems) has reached an advanced stage, but very few of these advances rely on integrated use of either enterprise models or specific enterprise knowledge.  Most of the knowledge-based assistance or heuristics reviewed concentrate on methods knowledge of the type that helps in pursuing normalization or syntactical correctness. 


One means of both accelerating system development and improving system quality throughout the SDLC is to embed domain-specific knowledge directly into CASE tools as discussed by McCarthy, Rockwell, Storey, Ram, and Mannino (1993), and such placement, with accounting-specific models and heuristics, is the primary topic of this paper.  The accounting enterprise model we choose to feature is the Resources-Events-Agents framework developed initially by McCarthy (1982) and extended by Geerts and McCarthy (1994).  The REA model has already been embedded in at least three CASE tools: (1) REAVIEWS (Rockwell 1992), (2) CREASY (Geerts and McCarthy 1992), and REAtool (Chen, McLeod, and O'Leary 1995).  Additionally, its use in other CASE tools such as REACH (McCarthy and Rockwell  1989; 1990) and FREACC (Geerts and McCarthy 1996) has been outlined and specified although not yet fully programmed.  We intend to examine all of this work in the context of a full review of the entire SDLC and to use that analysis both to reflect on past work and to speculate on future uses.







The remainder of this paper follows the outline of Figure 1.  To each of the SDLC phases enumerated above, we dedicate one section where we discuss in turn: (a) the data-intensive sub-steps involved in that phase, and (b) a set of possible knowledge-based uses of REA modeling that could be embedded in a new generation of tools for building accounting systems.  As mentioned above, some of these new generation uses are closer to fruition than others.  Those that have already been implemented, we specify in bold type in Figure 1; those whose architecture has only been outlined in theory, we specify in italic type; and finally, those whose operation we are speculating on here for the first time, we simply show unadorned.  After covering all phases of the entire life cycle, we end this paper with a summary section.


Because some knowledge of the REA accounting model is presumed in the rest of this paper, we indicate to readers at this point the availability of a short appendix that explains with a few summary figures the basic tenets of REA structure and use.  This appendix follows our summary section.



                                                        I. SYSTEMS PLANNING




In general, the term "Systems Planning" is used to refer to the strategic planning of information systems (Olle et al. 1991). The strategic planning process identifies and prioritizes the overall types of new systems (applications) that are needed rather than detailing specifications for a particular new system.  Martin (1989) splits the strategic planning phase in two steps.  The first step analyzes the impact of Information Technology (IT) on enterprise goals. Issues addressed here among others are critical success factor analysis and technology impact analysis.  The second step focuses on identification of corporate value chains and information architectures, and it accentuates the use of  enterprise modeling (Bernus and Nemes 1996), a concept that we examine in more detail next.


Enterprise modeling describes the corporation as a whole. Enterprise models are useful for both business analysis and data architecture representation.


   -   Enterprise modeling as business analysis should not be limited to merely studying the existing organization.  Instead, it should help in understanding the long-term conceptual goals of the business and the information processing elements (processes and tasks) needed to effect those goals.  In Sowa and Zachman's terms (1992), business analysis equates to the scope description of the information systems architecture, and it includes a listing of the things, processes, locations, organizations, events, and goals that are important to the business.


   -   Enterprise modeling as data architecture representation should help in recognizing the entities and relationships about which the enterprise wants to store data, i.e. a high level data model of the enterprise.  Typically, entities and relationships are related to business processes; business processes are aggregated into business functions; and an enterprise model integrates the different business functions.  Such a related set of functions is analogous to the Porter (1985, chap. 2) concept of a value chain.


Specific domain expertise that can be embedded in CASE tools would help out with both business analysis and data architecture representations.




No tools have been developed yet which primarily address automated support for the systems planning phase relying on REA domain knowledge.  However, Geerts and McCarthy (1992; 1994) and Geerts (1993) clearly indicate the potential of REA-based automated support for the systems planning phase. The key concept here is full-REA modeling, a modeling effort that results in a picture of an enterprise's chain of value-added activities.  Among other things, a full-REA enterprise model will indicate how resources are traced through the enterprise and through specific business functions, how processes are interrelated and how they contribute to value, how specific tasks effect completion of economic events, and how processes are controlled.  Stated differently, the full-REA structure will act as an economic model showing how an enterprise generates value for its owners, customers and other stakeholders (Geerts and McCarthy 1994).  This is exactly the type of knowledge which is needed to use an enterprise model for business analysis purposes.  Full-REA modeling is helpful in rethinking the enterprise structure: what are the fundamental business processes, to what extent do processes add value, etc.  Since knowledge technology allows us to explicitly record the enterprise model, automated tools may reason with the full-REA structures.  However, an automated tool should add extra features for business analysis purposes. For instance, in recognizing fundamental business functions, the tool should provide support by relying on standard frameworks like those published in Porter (1985), CAM-I (1988), Martin (1989), and Bernus and Nemes (1996).


CREASY (Conceptualizing REA Systems), one of the CASE tools which embeds REA knowledge, supports the idea of full-REA modeling by requiring the SDLC be started with a complete description of the economic activities of an enterprise.  This tool, or another implementation similar to it, could be augmented further with planning expertise by translating some of the standard enterprise models mentioned above (e.g., CAM-I or Porter) into full-REA process models.  Doing this in CREASY might change those strategic frameworks somewhat because full-REA modeling has strict conventions for resource specification and full traceability (Geerts and McCarthy 1994), and the pattern-matching in CREASY does not allow any implementation compromises.  However,  the resulting translation would undoubtedly be useful as a first attempt at an enterprise data architecture .


When full-REA modeling provides a high level planning data model for an enterprise, it also provides a skeleton schema useful for the later phases of the life cycle.  This is an area where other strategic frameworks come up short.  Geerts (1993) discusses how to compromise and extend an enterprise model in support of different applications once the SDLC has been initiated with a full analytical schema (Geerts and McCarthy 1994).



                                                        II.  SYSTEMS ANALYSIS




Systems analysis defines user requirements and priorities with an eye toward a new or improved application.  Whereas the data-intensive needs of the prior SDLC step (systems planning) focused on a loose description of entities and processes important to the company (Zachman 1987), data needs here become much specific.  In database terms (Batini et al. 1992), we have moved into a combination of requirements analysis and conceptual design; what we expect as an output is a fully-specified semantic data model.  Whitten et al. (1994, p. 253) characterize systems analysis as "business problem solving, independent of technology." 


Each new functional data need is identified during requirements analysis; each old decision or program need is also documented and transformed from physical to logical form.  These parallel activities give rise to the specification of data elements needed to support a certain view (McCarthy et al. 1989).  These views are then combined into an enterprise conceptual schema in a two-step process that involves (1) view modeling and (2) view integration.  Both of these steps are excellent candidates for REA-based support as described below.










Figure 2 illustrates how two CASE tools, CREASY and REACH, use embedded REA knowledge for conceptual database design. 


   -   In CREASY, the analyst is tasked with ascertaining overall decision needs for all users (upper left corner) which are then recast with methods knowledge into a object network of candidate entities and relationships (bottom left).  CREASY then uses its embedded knowledge of the REA accounting framework to transform that network into a conceptual database design (middle right) for the enterprise.  Syntactic knowledge is applied first, then semantic.  


   -   In REACH by contrast, the individual data elements of a view (upper left corner) are parsed both syntactically (via normalization rules and other methods-oriented heuristics) and semantically (with REA templates) to produce object constellations (middle right) that are strongly congruent (albeit in a very fragmented way) to REA cycle templates.  Syntactic and semantic knowledge is applied simultaneously.


In CREASY, enterprise database design is done in one pass, so there is no need to integrate any individual views, and a designer is done when he or she reaches the right side of Figure 2.  In REACH however, the multiple data-modeled views need to be combined in a view integration step.  That process is accomplished in a component of REACH called REAVIEWS.  The mechanics of REAVIEWS (Rockwell 1992) are illustrated in Figure 3 and explained below.







Figure 3 portrays three views (credit policy assessment, sale invoice processing, and remittance advice processing) that are each: (1) individually documented in data flow diagrams during requirements analysis, and (2) individually data modeled (as described in Figure 2 and just above).  In the middle of Figure 3, view integration is illustrated with these views and an enterprise E-R template (also called a managerial schema (Batini et al. 1992, chap.5)).  The managerial schema in REAVIEWS has a very strong REA flavor that was developed from two sources:  (1) the framework itself and (2) reconstructive knowledge of what should be in a particular type of entity's accounting system (Pescow 1976).  Additionally, REAVIEWS encoded data combination heuristics of the type proposed by McCarthy (1982, pp. 566-67) such as using the need for both increments and decrements in a particular cycle or the need for both inflows and outflows for a particular economic resource to identify combination possibilities.


Both CREASY and REAVIEWS have been implemented, while much of the intended components of REACH have only been specified in theory.  In our opinion, this SDLC phase of systems analysis offers the most promise for REA-enhanced CASE tools.  The amount of detail to be managed is enormous, and abstraction, especially theory-driven abstraction, is a complexity management mechanism which is simply unavoidable.  Enterprise models in general and REA in particular are good tools for complex data management.



                                                         III.  SYSTEMS DESIGN




In systems design, a technical solution aimed at a particular implementation platform is fashioned.  McCarthy et al. (1989) stress that CASE assistance can be rendered for both the procedural part of systems design which develops the programming modules and the structure charts for implementation and the declarative part of design which deals with cost-benefit refinement of the schema and its translation into the data definition language of a targeted database system.  Only the declarative part of systems design is of interest here.  Batini et al. (1992) refer to this set of steps as logical design.


Logical design usually makes cost-benefit tradeoffs on the basis of non-semantic factors such as database loads and logical accesses (Teorey 1990).  Such assessments allow designers to collapse the number of objects to be supported in the targeted software and/or to decide that some information will be produced with procedures instead of being stored explicitly.  Additionally, most translation of the semantic networks built during conceptual design into DBMS-processable schemas is also heavily laden with syntactical rules, and the translation process itself borders on algorithmic (for example, see Batini et al. 1992, chaps. 12-14).   Basically, this means that the preponderance of any automated support for logical design works without enterprise knowledge. However, with accounting systems design, we believe that this should not be the case, and we explain our REA-driven extensions below.  





In outlining how knowledge-based models of REA templates can be embedded and used, we focus on the two primary phases of logical design described by Batini et al. (1992, p.271) as model-independent and model-dependent.  The first of these usually involves decisions to delete objects or entities from the targeted schema, while the second involves translating semantic objects (like entity definitions) into logical model objects (like records and segments).  Descriptions of REA enhancements to both are given in a paragraph below.


In the architectural outline for REACH, McCarthy and Rockwell (1989) mentioned several semantically-grounded heuristics for logical design.  Two of these were heavily based on partial matches between REA exchange templates and particular sub-constellations of an enterprise schema.  For example, the following REA pattern:


                        "inflow event -- economic resource -- outflow event"


is very commonly compromised to a record-like structure that represents the resource explicitly, but which aggregates temporally the attributes of the two events into a single field (like "quantity-on-hand" or "account balance" for inventory and cash respectively).   These heuristics were not implemented in REACH, because of cost-benefit and timing constraints.  However, future implementations of this type should prove promising, and we plan extensions that will incorporate them explicitly.


We describe here how REA-driven support can be implemented for the other data-intensive portion of system design -- the translation of a semantic model into a computer-processable schema for a network DBMS.  Batini et al. (1992, chap. 13) describe how an E-R model is transformed into a network or CODASYL schema, and their rules include many syntactic ones also used by Gal and McCarthy (1983) for this same task.  However, the Gal and McCarthy declarative and procedural implementation also uncovered some unexplicated REA pattern-matching heuristics, one of which is illustrated in Figure 4 and explained as thus:   







            It is usually the case that relationships between all classes of the economic resource "inventory" and the economic events that affect it are "many-to-many" and that these relationships thus necessitate a CODASYL intersection record-type to both effect the link and provide a home for any jointly dependent attributes.  Furthermore, the procedural uses of this data structure involve most commonly a sequential access path through the more stable "inventory" entity.  Therefore, in the E-R to CODASYL translation, provide automatic schema definitions for these facilities whenever this pattern is encountered.


Without resorting to detailed definitions of what the CODASYL structure on the right of Figure 4 specifies (these are clearly beyond the scope of this paper), let it suffice for us to say that this pattern-matched translation (and others which could be gleaned from other REA implementation work) would greatly enhance the value of a design CASE tool in which it was embedded.  Again, this is a promising area for future work.



                                              IV.  SYSTEMS IMPLEMENTATION




Systems implementation means the construction of the new system (i.e., physical database design and actual program coding) and the delivery of that system into operation.  In other words, the term "implementation" refers to the activities which result in computerizing the system.  In a traditional sense, the major effort of the systems implementation phase is coding.  Automated tools to facilitate coding may include: (1) code generators, (2) screen generators, and (3) report generators.  All of these CASE tools are widely available, and a major effect of using them will be an increase in coding production.  In general, the functions embedded in these CASE tools are overtly involved with data and the meaning of data; however, the nature of their coding does become more data-intensive when algorithmic procedures are supplanted by declarative specifications.  This shift is explained below.


   -   Procedural specifications are fixed sets of instructions to accomplish a certain task (HOW). For example, to materialize information, we may develop a step-by-step specification to assemble data from files.


   -   Declarative specifications describe the concepts involved in a task (WHAT). In a predominantly declarative environment, it becomes the system's (inference engine) responsibility to select the rules to be applied in solving the problems posed; this is like assembling data in response to information requests.


When an implementation migrates toward more declarative specification, the use of conceptual domain models becomes more important.





REA domain knowledge will not affect any of the automated tools mentioned above (such as screen generators).  However, REA domain knowledge may have a dramatic impact on systems implementation when knowledge technology is used as an implementation platform.  Geerts and McCarthy (1992) discuss at length the CREASY tool which supports the active use of REA knowledge in materializing accounting information.  We describe CREASY and knowledge-intensive processing of accounting data in some more detail below.


   -   Building an accounting system with CREASY starts with a full-REA description of the enterprise activities.  These intensional structures are explicitly recorded and can be used for reasoning (a feature called augmented intensional reasoning).  In addition to REA-structured entity-relationship constellations, CREASY supports definitions for attributes and cardinalities.


   -   CREASY further extends its basic structures with features such as procedural attachments and role declarations.  An example of a role declaration is a "date" attribute for an economic event, something used for financial statement materializations.


   -   All application building (coding) relies heavily on the explicitly-recorded intensional structure.  One of the examples proposed in detail by Geerts and McCarthy (1992) is "claim" materialization.  They argue that in conventional AIS, individual procedures have to be developed for each of the different types of claims (such as receivables, payables, etc.).  They show then how CREASY reduces some application building to a declarative addition process.  Conclusion materializations are built in two steps: (1) an intensional pattern match is used to identify a generally defined concept (like claim) across the full-REA enterprise model, and (2) extensional occurrences are linked with the identified patterns.  Geerts (1993) describes numerous other examples of applications relying on knowledge-intensive processing of accounting data.  He also illustrates how missing declarative descriptions may be replaced by procedural specifications.


CREASY illustrates how accounting practice may be dramatically affected by knowledge-intensive processing of accounting data.  The implementation of AIS might be largely reduced to the specification of the intensional structure (REA-based enterprise model) and the declarative descriptions of domain-specific concepts in terms of the domain theory.  This is clearly illustrated in Figure 5.  The knowledge base consists of the conceptual schema (intensional structure), the database (schema extension) and a set of declarative descriptions of domain-specific concepts like claim and asset.  Knowledge-augmented procedures are embedded in the inference engine which is capable of responding to information requests for external schema use (such as various account balances and variance numbers).








                                                         V.  SYSTEMS SUPPORT




Systems support involves on-going maintenance of a system after it has been installed, and according to Whitten et al. (1994, p.746), it encompasses four ongoing activities:


   1.  Correct errors (also called the maintenance).


   2.  Recover the system.


   3.  Assist users of the system.


   4.  Adapt the system to new requirements (also called reengineering).


Only the first and the fourth of theses activities are data intensive in a manner that encourages use of enterprise models.  Recovery (#2) will often involve repairing lost or corrupted data files, but there is little knowledge-based processing in this system-dependent and highly algorithmic procedure.  Assisting users (#3) is primarily manual.  The maintenance (#1) and reengineering (#4) activities are actually very similar.  Both are reactions to a real or perceived inadequacy in the current computerized system, and they differ primarily in scope:  maintenance involves small changes, reengineering big changes.  CASE technology for maintenance is certainly more advanced at the present time with program structure analyzers and code tracers available from multiple vendors (Whitten et al. 1994, p.746).  Because of this and because we believe that enterprise knowledge of the type provided by REA is actually more applicable to big changes, the suggestions we give below with regard to schema migration and program reverse engineering are discussed in the context of the fourth activity given above.  However, they could be considered as at least partially applicable to maintenance. 





Whitten et al. (1994) describe five substeps for systems enhancement and reengineering: (1) analyze enhancement request, (2) write simple, new programs, (3) restructure files or databases, (4) analyze program library and maintenance costs, and (5) reengineer and test programs.  They also comment that the data restructuring needed for the third substep is actually done manually in many businesses, but that there is a clear trend toward more automation.  Participating in this trend toward automation is the body of research dealing with schema evolution (Li and McLeod 1989).  In the paragraph below, we describe REAtool -- a schema evolution CASE tool that uses REA enterprise knowledge directly.


REAtool (Chen, McLeod, and O'Leary 1995) uses the REA framework as both a domain model and as a basis for developing certain domain-specific evolution heuristics.  Their general schema evolution operators include create, sprout, merge, delete, move, and convert: all of these operate on a semantically defined and evaluated schema to guide its evolution toward a new target.  In REAtool, this target is REA-compliance, a concept that involves checking to make sure that components of the original framework specified by McCarthy (1982, p.564) are accounted for.   REAtool is presently a research prototype that works with the most general form of REA templates, but future plans call for its extension with more specific domain knowledge.


At the end of their systems analysis and design book, Whitten et al. (1994, p.757) speculate on the next generation of CASE tools and say that the ultimate goal of such systems ought to be the recovery of both implementation models and essential (conceptual) models from existing programs and data structures.  They term such reclamation design recovery and analysis recovery respectively.  They note that there are emerging CASE tools in design recovery. However, they also say that there is a major challenge inhibiting analysis recovery -- the inability to reverse the implementation back to its conceptual essence -- and they speculate that expert system and decision support solutions will likely be necessary to meet this challenge.  REA systems can clearly help here.  In Figure 6, we illustrate an architecture for analysis recovery called REAVERSE that was proposed by McCarthy and Rockwell (1990).  REAVERSE was planned as a component of REACH, and as readers may see, its goal was to take implemented files in an environment like COBOL and to extract from those files their uncompromised essence via the use of REA cycle templates and REA guided reversal heuristics.  As also predicted by Whitten et al., McCarthy and Rockwell envisioned that this processing would need the detailed, interactive guidance of an expert analyst for it to work well.  The REAVERSE component of REACH was not implemented, but its basic architectural ideas remain sound.  Again, this is an area for future research.










This paper has reviewed extensively the use of the REA accounting model in automated tools designed to assist analysts and designers as they perform the very intricate task of building complex enterprise information systems.  We reviewed all five phases of a standard system development life cycle and discussed both past and future uses of this first principles theory of accounting and heuristics built upon its structure.  At present, we are exploring other analysis and design phases amenable to REA use, and we intend in the future to speculate on the possibilities for combining all of our REA tools into one computerized support environment. 


For commercial businesses, the information system objects representing their fundamental economic phenomena (their resources, the events affecting those resources, and the agents participating in those events) constitute an accountability infrastructure for their enterprise information architecture.  Obviously, knowledge of this infrastructure's constituent parts helps a builder of business systems, although it is certainly true that REA-associated data components form only a part of the data needed to operate and manage an enterprise well.  Knowledge from other business domains (such as marketing or management) can and should be grafted onto the REA infrastructure within CASE tools when semantic models of those domains become available.


In our opinion, embedding domain-specific expertise into CASE tools serving every phase of the system development life cycle represents one of the most promising areas for development in software engineering.  This is especially true when the expertise in question is somewhat heuristic and more symbolic, and it must therefore be represented as explicitly as possible with knowledge-based techniques before it is embedded in the software.  O'Leary (1988, p.26) commented that software engineering research can benefit significantly in some cases from the specificity of context offered by accounting information systems, and we clearly believe that to be the case here.  Very few other domains offer semantic frameworks like REA.  In terms of a range of CASE tools, we think that the increased use of accounting-specific expertise moves research in this area further along a passive-active spectrum as portrayed in Figure 7 and explained below.






Building systems used to be almost exclusively a manual task, accomplished with tools like pens, paper, and flowchart templates.  Early CASE tools provided more support, but primarily with algorithmic assistance like drawing tools.  More recently, software has begun to provide support for specific analysis and design methodologies such as structured analysis, normalization, and E-R diagramming.  With each of these advances, CASE tools have moved forward in the direction of providing support that mimics the assistance one would receive from an all-knowledgeable human expert who has spent his or her life building systems exactly like the ones targeted on a particular SDLC project.  Such an expert, according to Loucopoulos and Harthoon (1988), would possess methods knowledge (e.g. normalization or structured programming), specific domain knowledge (e.g., accounting or medicine), and detailed knowledge of the targeted system's hardware, software, and organizational environment.  CASE research in the methods area has progressed well, but the same cannot be said of specific domains.  We believe that the tools, both implemented and prospective, discussed here will bring tools for accounting systems closer to that ideal.



The REA accounting model (McCarthy 1982; Geerts and McCarthy, 1994; 1996) is best understood from the top down as a strategic enterprise meta-model with three levels of abstraction:  (1) the enterprise level, (2) the process level, and (3) the task level.  The enterprise and process levels don’t tend to vary much over time for a given enterprise unless the firm changes its mode of operation or expands/contracts its lines of business (either vertically or horizontally).  On the other hand, the task level is very much dependent upon available technology for data capturing, data processing, and data reporting; therefore task specifications tend to change more.  We explain the enterprise REA level first.







Figure 8 illustrates a partial translation of Porter's generic value chain (1985, p.37) in REA terms.  Each of his activities becomes a process or exchange (shown as bubbles or circles), and his full value chains become abstract overviews of an enterprise where value-added exchanges are chained purposefully (Geerts and McCarthy 1994).  Each of the four circles in Figure 7 represents a full economic exchange with the decremented resource (i.e., what the enterprise gives up in the exchange) as input and the incremented resource (i.e., what the enterprise takes in during the exchange) as output.  The entrepreneur script for this generic firm is this:


   1. we first acquire employee services for cash in the human resource management process;


   2. we acquire raw materials for cash plus use of a truck and employee services in the inbound logistics process;


   3.  we use employee services and raw material to produce finished goods in the operations process; and


   4.  we consume finished goods and the use of employee services in a marketing and sales process that results in an inflow of cash from customers.


The Figure 8 value chain is not complete, and its illustrated processes could be decomposed further.  However,  as a first cut example, it suffices to give readers an idea of what an REA model looks like at the enterprise level.  The top left circle in this value chain (“Human Resource Management”)  is exploded in Figure 9 and explained in the paragraph below.







The process level of REA illustrates the object pattern for economic phenomena that first gave the model its name (McCarthy 1982).  Starting with the left half of the exchange bubble, this process consumes cash (the Resources as referenced by an account#) via a cash disbursement (the Event as referenced by a check#) with a cashier and an employee (the Agents).  This “give” Event is linked to an employee services acquisition “take” Event (as referenced by a time-card#) that also has a designated Resource and set of Agents.  The dotted line designating the stock of employee service indicates that this resource may not always be represented declaratively in an accounting database but instead materialized procedurally.  The give-take pattern of REA has two mirror-image object constellations which a systems analyst/designer can expect to see instantiated in every economic exchange process.


The task level of REA modeling for the process shown in Figure 9 would involve documentation (with tools like system flowcharts, data flow diagrams, or workflow systems) of the steps needed to accomplish the two events.            For the cash disbursement event, such steps might include authorizing the disbursement,  cutting the check, and distributing the checks to employees.  With a different technology, the same event could be accomplished via time-phased direct deposit into employee bank accounts.  Readers interested in more detailed explanations of REA components and levels are referred to Geerts and McCarthy (1994; 1996). 




Batini, C., S. Ceri and S. B. Navathe (1992), Conceptual Database Design. An Entity-Relationship Approach, Benjamin-Cummings, 1992.


Bernus, P. and L. Nemes, eds. (1996), Models and Methodologies for Enterprise Integration, Chapman and Hall, 1996.


CAM-I (1988), Cost Management for Today's Advanced Manufacturing. The CAM-I Conceptual Design, C. Berliner and  J. A. Brimson (eds.), Harvard Business School Press, 1988.


Chen, J-L, D. McLeod and D. O'Leary (1995), "Domain Knowledge Guided Schema Evolution for Accounting Database Systems," Working Paper, The University of Southern California.


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. (1993), Toward a New Paradigm in Structuring and Processing Accounting Data, Unpublished Dissertation, Free University Brussels, 1993.


Geerts, G. and W. E. McCarthy (1992), "The Extended Use of Intensional Reasoning and Epistemologically Adequate Representations in Knowledge-Based Accounting Systems," Proceedings of the Twelfth International Workshop on Expert Systems and Their Applications, Avignon, France, (June 1992), pp. 321-332.


Geerts, G. and W. E. McCarthy (1994), "The Economic and Strategic Structure of REA Accounting Systems," Working Paper, Presentation to the 300th Anniversary Program, Martin Luther University, Halle-Wittenberg, Germany, September 1994.


Geerts, G. and W. E. McCarthy (1996),  “Modeling Business Enterprises as Value-Added Process Hierarchies with Resource-Event-Agent Object Templates,”  Forthcoming in Business Object Design and Implementation, Springer-Verlag,  J. Sutherland and D. Patel (eds.).


Li, Q. and D. McLeod (1989), “Conceptual Database Evolution Through Learning,” in R. Gupta and E. Horowitz (eds.), Object-Oriented Databases and Applications, Prentice-Hall, 1989, pp. 62-74.


Loucopoulos, P. and C. Harthoorn (1988), "A Knowledge-Based Requirements Engineering Support Environment," Proceedings of the Second International Workshop on Computer-Aided Software Engineering", Cambridge, Mass. (July 1988), pp. 13-10 to 13-14.


Lum, V., S. Ghosh, M. Schkolnick, D. Jefferson, S. Su, J. Fry, T. Teorey, and B.Yao (1979), "1978 New Orleans Data Base Design Workshop Report," Research Report RJ2554(IBM Research Laboratories, San Jose, CA, July 1979). Abridged version also published in Proceedings of the Fifth International Conference on Very Large Data Bases (IEEE,1979), pp. 328-39).


Martin, J. (1989), Information Engineering, BOOK II: Planning and Analysis, Prentice-Hall, 1989.


McCarthy, W. E. (1982), "The REA Accounting Model -- A Generalized Framework for Accounting Systems in a Shared Data Environment," The Accounting Review (July 1982), pp. 554-78.


McCarthy, W. E. and S. R. Rockwell (1989), "The Integrated Use of First Order Theories, Reconstructive Expertise, and Implementation Heuristics in an Accounting Information Design Tool," Proceedings of the Ninth International Workshop on Expert Systems and Their Applications, Avignon, France, (June 1989), pp. 537-48.


McCarthy, W. E. and S. R. Rockwell (1990), "Knowledge Synthesis in REACH: An AI-Based Design Tool for Accounting Systems," Paper presented at TIMS/ORSA Joint National Meeting, Las Vegas, May 7-9, 1990.


McCarthy, W. E., S. R. Rockwell and H. M. Armitage (1989), "A Structured Methodology for the Design of Accounting Transaction Systems in a Shared Data Environment," Proceedings of the 1989 Conference of the Structured Techniques Association, Chicago, USA, (May 1989), pp. 194-207.


McCarthy, W. E., S .R. Rockwell, V. C. Storey, S. Ram and M. V. Mannino (1993), "On The Role of Domain-Specific Knowledge in CASE Tools," Panel presentation, in Proceedings of the Third Annual Workshop on Information Technologies & Systems, WITS '93, Orlando, (December 1993), pp. 86-89.


O'Leary, D. (1988), "Software Engineering and Research Issues in Accounting Information Systems," Journal of Information Systems, (Spring 1988), pp. 24-38


Olle, T. W., J. Hagelstein, I. G. Macdonald, C. Rolland, H. G. Sol, F. J. M. Van Assche and A. A. Verrijn-Stuart (1991),  Information Systems Methodologies: A Framework for Understanding, Addison-Wesley, 1991.


Porter, M. (1985), Competitive Advantage, The Free Press, 1985.


Pescow, J. K. (ed.) (1976), The Encyclopedia of Accounting Systems, Prentice-Hall 1976.


Reiner, D. (1992), "Database Design Tools," in C. Batini, C. Ceri, and S. Navathe (eds.), Conceptual Database Design: An Entity-Relationship Approach, Benjamin Cummings, 1992.


Rockwell, S. R. (1992), The Conceptual Modeling and Automated Use of Reconstructive Accounting Domain Knowledge, Unpublished Dissertation, Michigan State University, 1992.


Rosenthal, A. and D. Reiner (1994), "Tools and Transformations -Rigorous and Otherwise - for Practical Database Design,"  ACM Transactions on Database Systems, Vol.19., No.2, (June 1994), pp.167-211.


Sowa, J. F. and J. A. Zachman (1992), "Extending and formalizing the framework for information systems architecture," IBM Systems Journal, Vol. 31, No. 3, 1992, pp. 590-616.


Storey, V. C. and R. C. Goldstein (1993), "Knowledge-Based Approaches to Database Design," MIS Quarterly, (March 1993), pp. 25-46.


Teorey, T. (1990), Database Modeling and Design, Morgan Kaufmann, 1990.


Whitten, J. L, L. D. Bentley and V. M. Barlow (1994), Systems Analysis and Design Methods, Irwin, 1995.


Zachman, J. A. (1987), "A Framework for Information Systems Architecture," IBM Systems Journal, Vol.26, No.3, 1987, pp. 276-292.







Identify and prioritize systems applications

Business analysis

Data architecture           representation

Full-REA modeling

Full-REA modeling


Analyze business problem and
define business requirements

Conceptual design

- view modeling and  view  integration




Technical design

Schema refinement

Schema conversion

Object-oriented design


REA-logical design



Construct the system

Conclusion materializations



Sustain and maintain the information

Schema migration

Reverse engineering




Figure 1 — Integration of Conceptual Accounting Domain

Knowledge Into the Life-Cycle




Figure 2 — Domain Specific Design


Figure 3 — Inputs to View Integration
[Source: Rockwell 1992]



Figure 4 — Conversion of REA to Network Schema



Figure 5 — Augmented Intensional Reasoning in Creasy



Figure 6 — The REAVERSE System


Figure 7 — CASE Tools: Active-Passive Spectrum






Figure 8 — REA Enterprise View of a Generic Value Chain


Figure 9 — REA Process View of Human Resource Management