An Ontology-Based Dynamic Enterprise Model: A Proposal for Enterprise Planning
Kim Church
Sam M. Walton College of Business
University of Arkansas
Rod Smith*
Sam M. Walton College of Business
University of Arkansas
Nov 30, 2005
*Corresponding Author, Sam M. Walton College of Business, Department of
Accounting, Business Building 401, University of Arkansas, Fayetteville, AR 72701-
1201, email: rsmith@walton.uark.edu

An Ontology-Based Dynamic Enterprise Model: A Proposal for Enterprise Planning
ABSTRACT : In this paper we propose an ontology-based dynamic enterprise model with application for enterprise planning. We use the resource-event-agent (REA) framework as an enterprise domain ontology from which we develop a systems dynamics model of enterprise processes. Such a model may have broad application for enterprise planning, but we specifically describe how the model can be used to plan ongoing compliance with section 404 of the Sarbanes-Oxley Act. We use a systems dynamics approach to describe generic procedural elements of the REA ontology. We thus make two contributions to the design science literature. First, systems dynamics have been extensively applied to business problems, but there is little evidence that any systems dynamic models of enterprise processes have been based on established ontologies. Our approach employs an established ontology, i.e., the REA framework, which facilitates reuse of and learning from these models in a variety of business contexts. Second, the existing REA literature provides no clear guidance about how to model the procedural elements of business processes. Geerts and McCarthy (2000b,
2002) and Dunn et al. (2005) describe task level modeling as part of the REA ontology, but they do not provide any systematic guidance for developing procedural (task level) models. Our approach does provide a systematic method for converting REA models to procedural models.
Key Words : REA framework; ontology; systems dynamics; enterprise planning;
Sarbanes-Oxley Act
Data Availability : not applicable.
2

I. INTRODUCTION
In this paper we propose an ontology-based dynamic enterprise (OBDE) model with application for enterprise planning. We use the resource-event-agent (REA) framework as an enterprise domain ontology from which we develop a systems dynamics model of enterprise processes. Such a model may have broad application for enterprise planning, although for this paper we specifically describe how the model can be used in a managerial planning system to plan ongoing compliance with section 404 of the Sarbanes-Oxley Act.
We employ an ontology-based approach to provide a standard semantic structure for a dynamic enterprise model. Ontologies provide a formal specification of the concepts and relationships that can exist for an agent or a community of agents
(Gruber 1993). Thus, ontologies enable knowledge sharing and information integration and provide a consistent basis for understanding and communicating domain phenomena. They facilitate what Geerts and McCarthy (2000a) term augmented intensional reasoning , which allows the sharing of concepts across functional boundaries and the reuse of those concepts in various applications.
We select the REA framework as an enterprise domain ontology for several reasons. First, since the REA framework has been published in peer-reviewed accounting journals, it has undergone extensive analysis. It has proven to be a faithful representation of the objects and relationships between those objects that exist in an enterprise accounting context (e.g., McCarthy 1982; Geerts and McCarthy 1999, 2000b,
2002; Dunn et al. 2005). Second, the REA framework is consistent with the underlying structure of major commercial enterprise software, such as SAP (O’Leary 2004). The
3

REA framework thus supports an integrated view of enterprise processes. Third, there is ongoing research that extends the REA framework to the broader enterprise domain, effectively modeling both enterprise economic and management activities (e.g., Church and Smith 2005). This indicates that REA is an ontology and the principles support the design of many types of enterprise systems.
We describe how the REA ontology can be used to define a dynamic model 1 of enterprise processes to support enterprise planning at the strategic level. We apply systems dynamics methodology to develop our OBDE model. Business problems are often complex and changing over time. Systems dynamics provides a “powerful method to gain useful insight into sit uations of dynamic complexity,” especially when experimentation with real systems is impractical or infeasible (Sterman 2000, 39). There is, however, little evidence that existing dynamic models of enterprise processes have been based on established ontologies.
We use a systems dynamics approach to describe generic procedural elements of the REA ontology. Existing REA literature provides no clear guidance about how to model procedural elements of business processes. Geerts and McCarthy (2000b,
2002) and Dunn et al. (2005) describe task level modeling as part of the REA ontology, but they do not provide any systematic guidance for developing procedural (task level) models. Our approach offers a systematic method for converting REA models to procedural models.
We expect that our OBDE model has broad application for many strategic enterprise planning purposes 2 , but we specifically describe how the OBDE model can
1 We use the term dynamic model to indicate a model developed with systems dynamics methods.
2 We also expect that our model has broad application for research, which we will outline later.
4

be used in a managerial planning system to plan ongoing enterprise compliance activity in connection with section 404 of the Sarbanes-Oxley Act (The Public Company
Accounting Reform and Investor Protection Act of 2002, hereafter referred to as SOA).
By all accounts, the SOA has already required substantial compliance efforts. Some reports indicate that Fortune 1000 companies spent almost $8 million on average for first year compliance efforts (Charles River Associates 2005). An Ernst and Young
(2005) survey found that 60% of firms with over $20 billion revenue invested over
100,000 hours on section 404 activities. The overall costs of ongoing SOA compliance efforts are expected to exceed $30 billion in five years (Sammer 2005, citing an AMR
Research study). Firms are therefore trying to allocate resources cost-effectively in a dynamic environment (Sammer 2005; KPMG 2005). We demonstrate how our OBDE model supports a risk-based evaluation of the impact of compliance investments.
We proceed as follows. In the next section, we discuss ontology theory, how ontologies enable effective systems design, and we describe the REA framework as an ontology. In section three, we describe systems dynamics and the benefits of systems dynamics models. We use the REA framework to develop an ontology-based systems dynamics model of enterprise processes. We then use a systems dynamics approach to describe generic procedural elements of the REA framework. In section four, we apply the OBDE model to a managerial planning system in an SOA compliance context and show how it can facilitate compliance planning. We then conclude and provide recommendations for future research.
5

Ontology theory
II. ONTOLOGY THEORY AND REA FRAMEWORK
Ontological theories impose order on domain phenomena and help us describe the structure of the domain and relations between objects therein (Weber 2003; Zuniga
2001). An ontology is a formal representation of the constructs needed to describe particular types of phenomena that occur in some domain (Gruber 1993; Wand and
Weber 1996). It defines the common words and concepts used to describe and represent an area of knowledge (Obrst 2003; Schreiber 2003; Linthicum 2004). Thus, ontologies provide a consistent basis for understanding and communicating domain phenomena. Well defined ontologies should therefore facilitate the accurate communication critical to the successful implementation of enterprise systems
(Linthicum 2004; Uschold et al. 1997, Weber 2003) by providing the architecture necessary to design effective systems. Systems design ontologies enable what Geerts and McCarthy (2000a) term augmented intensional reasoning , which allows the sharing of concepts across functional boundaries and the reuse of those concepts in various applications.
The REA framework as an ontology
The REA framework depicts causal events that are converted into accounting information (Church and Smith 2005). McCarthy (1982) presents the original REA framework as a general model of “the stock-flow aspects of accounting object systems” by characterizing accounting phenomena in terms of economic events and the associated enterprise resources and agents as shown in Figure 1. Resources are defined as things of economic value that are provided or consumed by an enterprise’s
6

activities and operations. Economic events reflect the increment (stock inflow) or decrement (stock outflow) of economic resources. Agents are the persons, organizations, or organizational units that control or participate in economic events.
Through ongoing research in the field of design science, the REA framework has been extended to specify broadly the set of objects and relationships among the objects that exist in the accountability infrastructure for an enterprise domain (Geerts and
McCarthy 1999; Church and Smith 2005; Dunn et al. 2005). Geerts and McCarthy
(1999, 2000b, 2002) argue that the extended REA framework meets the definitions of an enterprise domain ontology. The REA framework has been extensively analyzed and published in peer-reviewed journal. It is consistent with the underlying structure of major commercial enterprise software, such as SAP (O’Leary 2004), and it supports an integrated view of enterprise processes. There is no other framework with similar qualifications to serve as a blueprint for strategic information architectures and enterprise systems.
III. SYSTEMS DYNAMICS, ENTERPRISE MODELS, AND REA
Systems dynamics
According to Sterman (2000), systems dynamics is an interdisciplinary approach to examining complex systems, such as business processes. It uses stock and flow models to simulate the behavior of complex systems over time. It offers tools to represent difficult problems and formal simulation methods to test and improve models.
7

Stocks and flows are the basic building blocks of dynamic models.
3 Stocks represent accumulations, such as inventory value. Flows represent changes in stocks, such as shipments from inventory or receipts into inventory. Stocks characterize the state of a system at a particular time, and flows characterize the changes in the stocks during any period. The relationship between stocks and flows can be described mathematically:
Stock(t) = t
 t 0
[ Inflow ( s )

Outflow ( s )] ds + Stock(t
0
) (1) where Inflow(s) is the value of the inflow and Outflow(s) is the value of the outflow from the stock at any time, s, between the initial time, t
0
, and the current time, t.
We follow the conventions for modeling stocks and flows established in Sterman
(2000) and several systems dynamics simulation software products, as shown in Figure
2.
4 Stocks are represented by rectangles. Inflows are represented by a pipe pointing into a stock. Outflows are represented by a pipe pointing out of a stock. Biflows (flowing either in or out depending on the value of the flow) are represented by pipes pointing both ways. The valves on the pipes regulate flow rates. The clouds at the end of some flow pipes represent sources or sinks for the flows (outside the boundary of the model).
The circles represent converters, which define external inputs to the model, calculate algebraic relationships, or hold constants. The curved arrows, e.g., from converters to flows, connect model elements and indicate that mathematical relationships exist between those elements.
3 See Sterman (2000) for a complete description of stocks and flows in systems dynamics modeling.
4 We employ iThink software from ISEE Systems, Inc.
8

Proponents of systems dynamics argue that simulation models using these building blocks overcome deficiencies in other planning tools. Other planning tools often fail to consider feedback, time delays, and nonlinearities (Sterman 2000). Simulation models therefore offer the only practical way to evaluate how conjectured causal relationships might influence the performance of complex, dynamic systems, such as business processes.
Skeptics argue that formal simulation models are constrained by the assumptions upon which they are based (Sterman 2000). However, all planning systems share this problem, and there is an extensive body of literature that indicates that systems dynamics modeling provides a rigorous approach that helps managers understand — and improve decisions about
—complex business problems.
5
While common models exist , such as “archetype” models 6 , there is little evidence that any dynamic models of enterprise processes have been based on established ontologies. This limits the reusability of such models. A dynamic model can provide insight into a complex business problem, but it may not be broadly applicable to a variety of processes. By basing a dynamic model on an established ontology, i.e., the
REA framework, we provide an approach that overcomes that limitation.
Converting an REA model to a dynamic model
Figure 3 portrays the mapping of an REA model to a dynamic model (DM). We use the sales/collection process as an example, as follows:
5 For example, the journal Systems Dynamics Review publishes peer-reviewed articles on the applications of systems dynamics to business and other problems.
6 Archetype models are systems dynamics tools for gaining insight into patterns of behavior reflective of the underlying structure of the systems being studied.
9

o The REA resources (Inventory and Cash) become DM stocks that represent the accumulated values. o The REA events (Sales and Cash Receipts) become DM stock inflows and outflows. Specifically the REA Sales event becomes a DM inflow to the
Receivables stock and the REA Cash Receipt event becomes a DM outflow from the Receivables stock. Note that we assume a traditional model with collections at some point after the sales. The REA cardinalities for the relationship between Sales and Cash Receipt indicate whether the cash is received before or after the sale and would determine the appropriate dynamic model.
7 Some firms may receive cash prior to the sale; in that case, the DM would represent unearned revenue. The REA Cash Receipt event would become a DM inflow into the Unearned Revenue stock (and the REA
Sales event would become a DM outflow). For the planning model, we are not interested in tracking individual transactions, but rather the rate of sales transactions. In the REA model, the value of receivables can be computed from the transaction detail. In the systems dynamics model, we specifically compute the value of receivables by including a stock. o The REA agents (Customers and Sales Employees) become DM stocks. We add biflows to model changes in the number of customers and employees over time. o The REA stockflow out relationship (between Inventory and Sales) becomes a DM outflow from the Inventory stock. The REA stockflow in relationship
7 Complex situations could require multiple stocks and flows; state diagrams can facilitate understanding of the appropriate representation. See Whitten et al. (2001) for descriptions of state diagrams.
10

(between Cash Receipt and Cash) becomes a DM inflow to the Cash stock.
These flows represent the periodic changes in the stocks, and they implement the effect of the REA duality relationship on resources. o The REA duality relationship (between Sales and Cash Receipts) becomes a
DM stock (Receivables) to accumulate receivable balances. o The REA participation relationships (between Sales and Cash Receipts events and corresponding Employee and Customer agents) become connectors that link the DM stock with the corresponding DM in or out flow.
Specifically the REA Employee and Customer are linked to the DM Sales inflow by a connector.
Additionally, we add converters and connector arrows to implement assumptions about business policies and expected causal relationships. For example, the Time-to-
Collect converter would describe the expected length of time to collect receivables, and the Sales-Discount-Rate converter would describe the expected discount. The
Customer-Demand-Factor converter describes expected sales per customer per period.
The Sales-Employee-Productivity converter describes the expected sales per employee. Thus, the periodic sales are a function of the number of customers, the demand per customer, the number of employees, and the employee productivity.
8
The dynamic sales model allows us to establish initial values for stocks and simulate the sales process for a number of periods. We can then examine the effect of assumptions or policies on future performance. For example, we can change the customer demand or employee productivity assumptions and see the effect on inventory
8 Other factors may also influence the demand and constrain the business process, but this represents a generic model, like the basic REA pattern. We will discuss enhancements to the model in section five.
11

or cash. More importantly, we can use this process to create integrated, dynamic model of business processes and tailor the model to specific business situations.
Figure 4 illustrates a similar systems dynamics model for purchase/cash disbursements processes. Figures 5 and 6 present extended models that include commitments. Figure 5 shows the sales order event for the sales/cash receipts process, and Figure 6 shows the purchase order event for the purchase/cash disbursements process. Unlike REA models, the dynamic models do not represent detailed transactions; instead they represent summary level data. The dynamic models are therefore similar to other planning tools, such as budgets, while offering the flexibility to investigate complex causal relationships, handle nonlinearities, and plan across multiple periods. Like REA models, however, they can be integrated across processes via shared resources. For example, the Inventory and Cash stocks (resources) are shared.
The purchase process creates a stock inflow to the Inventory stock and the sales process creates a stock outflow from the Inventory stock. Cash receipts create stock inflow to the Cash stock, and Cash Disbursements create cash outflows from the Cash stock.
Procedural Elements of a REA model using systems dynamics
The original REA framework presented a declarative model of enterprise economic phenomena (McCarthy 1982). Subsequently, the REA framework was extended to include procedural elements termed scripts that determine the configuration of processes within a firm or the set of tasks necessary to carry out a process (Geerts and McCarthy 2000b, 2002; Dunn et al. 2005). The existing REA research does not,
12

however, provide extensive guidance (note for presentation: can use flowcharts, but no structure or rules exist for implementing the flowchart) on the modeling of such scripts.
Figure 7 describes the extended REA framework. The accountability infrastructure includes three levels: the value chain level, the process level, and the task level. At each level, there is a corresponding policy infrastructure that includes the knowledge level objects necessary to support management information requirements, e.g., budgets, standards, and internal control structures.
We use a systems dynamics approach to describe generic procedural elements in the task level of the REA ontology in a manner that facilitates structure. By mapping the REA ontology into procedural elements of the dynamic model, we provide guidance for the modeling of the REA scripts. We propose our OBDE model replace the task level specification of the REA ontology with a forward looking systems dynamics model necessary for planning.
IV. ENTERPRISE PLANNING USING DYNAMIC MODELS IN A SOA CONTEXT
Dynamic Models of Enterprise Planning
We describe how the REA ontology can be combined with the procedural elements of systems dynamics to produce an OBDE model of enterprise processes to support enterprise planning at the strategic level. Business problems, such as capital budgeting, outsourcing, mergers and acquisitions, and regulatory compliance, can be complex and changing over time. Our OBDE model provides a theory based approach to provide a vehicle for solving situations of dynamic complexity. We apply a generic managerial planning tool to a specific compliance process.
13

Sarbanes-Oxley section 404
According to the Public Company Accounting Oversight Board’s (PCAOB)
Release Number 2005-009 May 16, 2005 policy statement on the SOA:
Section 404 of the Act aims to strengthen the internal controls that underpin the accuracy and reliability of a company's published financial information. That section, along with the SEC's implementing rule, requires a public company to annually report its assessment of the effectiveness of its internal control over financial reporting. The section also requires such a company to provide its auditor's attestation to, and report on, the company's assessment.
In that policy statement, the PCAOB recognizes the challenges that public companies face in complying with section 404 requirements. Furthermore, they note that many companies have found the SOA requirements “costly and demanding, and many have questioned whether the benefits are worth the cost.” They cite a Financial
Executives Institute survey of 217 public companies that found first year compliance costs exceeded $4.3 million and required over 27,000 hours on average. Clearly, the costs of SOA compliance are substantial, and managers have to make important planning decisions to minimize the cost and maximize the benefits of efforts to sustain compliance.
An approach to Sarbanes-Oxley section 404 compliance
Since compliance with SOA section 404 is an important challenge faced by a large number of managers, we propose an example of how an OBDE model could facilitate managers’ compliance decision-making. First, we have to understand how
14

managers implement section 404 requirements. A number of accounting firms have issued guidance for managers. In all cases, the guidance follows the Committee on
Sponsoring Organizations (COSO) framework. We select the guidance from
PricewaterhouseCoopers (PWC) (2004) as our reference, since it is consistent with guidance from the other major accounting firms but more comprehensive.
9
PWC (2004) provid es guidance for “evaluating and testing the design and operational effectiveness of control over financial reporting that will be conducted in the future and (ii) affirm or initiate a reassessment of established work plans or processes.”
They outline several steps for an effective compliance project. We focus on two of those steps, the scope and evaluate functions. The four major steps of scoping are as follows
(PricewaterhouseCoopers 2004, 9):
1. Identify significant accounts and disclosures by considering Items separately disclosed in the consolidated financial statements, and the materiality at the consolidated financial statement level.
2. Identify business processes and sub-processes and map them to significant accounts and disclosures.
3. Identify the relevant financial statement assertions for each significant account and disclosure.
4. Perform a risk assessment of the business sub-processes.
Firms carry out these four steps for every location or business unit that are
“individually important” or “financially significant” as defined in the PCAOB’s Auditing
Standard No. 2. In other words, firms have to make a risk-based evaluation of internal
9 We compared the following documents from the big 4 accounting firms and others: Deloitte 2004,
2005a, 2005b; Ernst & Young 2005; KPMG 2005; PricewaterhouseCoopers 2004, 2005a, 2005b; Protiviti
2005.
15

control for each business process expected to have a material effect on the financial statements. PWC recommends that firms use the most recent annual financial reports, current budgets, or a combination of recent quarterly and annual data to select which processes at which locations to assess. While this recommendation addresses the requirements of the auditing standard, it may not allow managers to react to dynamic changes in business processes and anticipate future risks. PWC goes on to recommend that budget or prior year data should be updated to reflect significant anticipated changes, but they do not offer any systematic way for managers to test and evaluate anticipated changes. Thus, managers need a planning tool with which they can evaluate dynamic changes in process risk.
After determining the scope of SOA compliance efforts, managers must evaluate whether their system of internal controls is suitably designed to prevent or detect misstatements (PricewaterhouseCoopers 2004, 46) by determining if the controls are effective in managing risk. When managers consider anticipated changes, they must therefore also consider the hypothetical effect of possible control options. By considering multiple control options, managers can also evaluate which set of controls provides the desired benefit at the least cost. Thus, managers need a planning tool with which they can evaluate dynamic changes in costs and benefits.
Example of dynamic model for planning Sarbanes-Oxley section 404 compliance
We use the sales/cash receipts process to provide an example of how an OBDE model can be used to plan and manage SOA compliance. Development of a complete
SOA compliance model is beyond the scope of this paper and would require modeling across multiple processes. We provide a simplified example for proof of concept.
16

For section 404 compliance, PWC recommends that managers set priorities based on an assessment of the impact of process risk factors on the possibility of material financial misstatements (PricewaterhouseCoopers 2004, 98-99). Following the
PWC recommendations, we select the sales/cash receipts process, because of the substantial ef fect that this process has on firms’ financial statements. We focus on three basic control objectives: 1) sales are accurately recorded, 2) cash collections are accurately recorded, and 3) shipments from inventory are accurately recorded and reflect sales actually made to customers.
The benchmark for this process is the basic Sales/Cash Receipts process model
(Figure 3). We add three converters to the model: Risk of Inaccurate Sales Recording ,
Risk of Inaccurate Cash Collections , and Risk of Inaccurate or Inappropriate Shipments as shown in Figure 8. Each converter corresponds to one of the three basic control objectives and represents the likelihood that the control objective will be violated. The values that each of these three converters takes on over time is a function of the five
COSO 10 internal control components: control environment, risk assessment, control activities, information and communication, and monitoring. For this example, we model these five components as single converters as shown in Figure 8, although we expect these components to be broken down into appropriate subcomponents in more refined models.
There are several options for modeling the values that each COSO component takes on. For this example, we set the value of each component as a percentage of best practice, i.e., optimal compliance with all objectives for that component. To apply
10 Recent developments indicate COSO ERM has eight components. The COSO revision adds additional complexity to the model while distracting from the intent of the simplified example.
17

the model to a real business situation, managers would make those determinations based on familiarity with the company, the business unit, the location, and the business process. For this example, all five components affect each of the three converters that correspond to the three control objectives as shown in Figures 8 and 9. We assume that each component has the same weight. Again, managers would modify these relationships to reflect the real business situation. Finally, the COSO components may affect the converter value (lower component percentages drives a higher level of risk of misstatement), or they may affect the variance in the converter value (lower component percentages drives a higher variance in the risk of misstatement). We select the second option for this example; the COSO components affect the variance in the three “Risk” converters.
Table 1 describes the parameters for this example and compares results for this model against the no-risk benchmark model over 20 fiscal quarters using iThink software. Appendix A describes the initial values and equations for each model.
Although we apply very basic assumptions to the models, Table 1 shows the impact of
COSO component deficiencies and how those deficiencies might interact in a business process. The difference in recorded sales is less than 3 percent, but the differences in both cash receipts (stockflow in) and inventory shipments (stockflow out) exceeds 5 percent of the benchmark values. The results also show that the assumed 2 percent sales growth rate increases the level of differences, but the random variation in the
“Risk” converters sometimes tends to hide the growth.
In our simplified example we measure the absolute difference between the benchmark and risk models. We assume the risk of recording sales, cash, and
18

inventory accurately will always provide values below the benchmark, this may not always be the case. It is equally reasonable to model the variance from the target and track the number of times the value exceeds an inappropriate threshold.
Clearly, this sort of information is important to managers in evaluating dynamic changes in process risk and the tradeoff between the costs and benefits of internal control initiatives. For example, the cost of an investment to improve monitoring can be compared to the benefit achieved by improving that COSO component value. Managers can also examine the impact of sales growth on related account values and how sales growth exacerbates the effect of internal control deficiencies. Importantly, the OBDE model allows managers to visualize the potential impact of decision alternatives.
V. CONCLUDING REMARKS AND RECOMMENDATIONS FOR FURTHER
RESEARCH
We propose an ontology-based dynamic enterprise model with application for enterprise planning. We use the REA framework as an enterprise domain ontology from which we develop a dynamic model of enterprise processes. We specifically describe how the model can be used in a managerial planning system to plan ongoing compliance with section 404 of the Sarbanes-Oxley Act, but such a model may have broad application for enterprise planning.
We use a systems dynamics approach to describe generic procedural elements in the task level of the REA ontology in a manner that provides process modeling guidance. By mapping the REA ontology into procedural elements of the dynamic
19

model, we provide the guidance necessary for the modeling of the REA scripts. We propose our OBDE model replace the task level specification of the REA ontology.
We thus make two contributions to the design science literature. First, systems dynamics have been extensively applied to business problems, but there is little evidence that any dynamic models of enterprise processes have been based on established ontologies. Our approach employs an established ontology, i.e., the REA framework, which facilitates reuse of and learning from these models in a variety of business contexts. Second, the existing REA literature provides no clear guidance about how to model the procedural elements of business processes. Geerts and
McCarthy (2000b, 2002) and Dunn et al. (2005) describe task level modeling as part of the REA ontology, but they do not provide any systematic guidance for developing procedural (task level) models. Our approach does provide a systematic method for converting REA models to procedural models.
We provide only a few, limited examples of dynamic models. We recommend further research to integrate and expand these models into a complete dynamic model of the firm. Such a model would have broad application to a variety of business problems and support academic research into those problems. We recognize that our dynamic models must be tailored to specific business situations.
McCarthy’s (1982) basic REA pattern has proven robust, but it also must be tailored to specific business situations. The most important aspect of the REA framework is that it provides the conceptual building blocks for a database-oriented accounting information system. An
REA-based dynamic model can also provide the conceptual building blocks for enterprise planning systems.
20

REFERENCES
Charles River Associates. 2005. Sarbanes-Oxley Section 404 Costs and Remediation of Deficiencies: Estimates from a Sample of Fortune 1000 Companies . CRA No.
D06155-00, April. Washington DC: Charles River Associates.
Church, K., and R. Smith. 2005. An Evaluation of the REA Framework as an Enterprise
Domain Ontology: Does the REA Framework Support Balanced Scorecard Information
Requirements? Working paper.
Deloitte. 2004. Taking Control; A Guide to Compliance with Section 404 of the
Sarbanes-Oxley Act of 2002 . Deloitte and Touche LLP and Deloitte Consulting LLP.
__________. 2005a. Deloitte’s Point of View; Sarbanes-Oxley Compliance: A Bridge to
Excellence . Deloitte and Touche LLP and Deloitte Consulting LLP.
__________. 2005b. Under Control; Sustaining Compliance with Sarbanes-Oxley in
Year Two and Beyond . Deloitte and Touche LLP and Deloitte Consulting LLP.
Dunn, C. L., J. O. Cherrington, and A. S. Hollander. 2005. Enterprise Information
Systems , Third Edition. New York: McGraw-Hill Irwin.
Ernst & Young. 2005 . Emerging Trends in Internal Controls; Fourth Survey and Industry
Insights . Ernst & Young.
Ge, W., and S. McVay. 2005. The disclosure of material weaknesses in internal control after the Sarbanes-Oxley Act. Accounting Horizons , 19(3): 137-158.
Geerts, G. L., and W. E. McCarthy. 1999. An accounting object infrastructure for knowledge-based enterprise models . IEEE Intelligent Systems & Their Applications
(July/August): 89-94.
________. 2000a. Augmented intensional reasoning in knowledge-based accounting systems. Journal of Information Systems , Fall: 27-50.
________. 2000b. The Ontological Foundation of REA Enterprise Information System.
Working paper.
________. 2001a. Using object templates from the REA accounting model to engineer business processes and tasks. The Review of Business Information Systems , 5(4): 89-
108.
________. 2001b. The ontological foundation of REA enterprise information systems,
Working Paper, Michigan State University.
21

________. 2002. An ontological analysis of the economic primitives of the extended-
REA enterprise information architecture . International Journal of Accounting Information
Systems , 3: 1-16.
________. 2003. Type-level specifications in REA enterprise information systems.
Working Paper, Michigan State University.
Gruber, T. 1993. A Translation Approach to Portable Ontologies. Knowledge
Acquisition , pp. 199-220.
Harrington, C. 2005. The value proposition. Journal of Accountancy , September: 77-81.
Journal of Accountancy. 2005. The cost of complying…with everything! Journal of
Accountancy , July: 17.
Kim, H. M., M. S. Fox, and M. Gruninger. 1999. An ontology for quality management – enabling quality problem identification and tracing. BT Technology Journal , 17(4): 131-
140.
KPMG. 2005. The Compliance Journey; Making Compliance Sustainable . KPMG
International.
Lampe, J. C. 2002. Discussion of an ontological analysis of the economic primitives of the extended-REA enterprise information architecture. International Journal of
Accounting Information Systems , 3: 17-34.
Linthicum, D. 2004. Leveraging ontologies: The intersection of data integration and business intelligence, part 1. DM Review , June.
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-578.
Obrst, L. 2003. Ontologies for semantically interoperable systems. 12th International
Conference on Information and Knowledge Management (CIKM'03) , New Orleans,
Louisiana, November 3-8, 2003.
O’Leary, D. E. 2000. Different firms, different ontologies, and no one best ontology.
IEEE Intelligent Systems & Their Applications , Sep/Oct: 72-77.
__________. 2004. On the relationship between REA and SAP. International Journal of
Accounting Information Systems , 5: 65-81.
22

PricewaterhouseCoopers. 2004. Sarbanes-Oxley Act: Section 404 Practical Guidance for Management . July 2, 2004. PricewaterhouseCoopers LLP.
__________. 2005a. U.S. Multinationals look to technology for improvements in future
Sarbanes 404 efforts . PWC Management Barometer, October 6.
__________. 2005b. How to Move Your Company to Sustainable Sarbanes-Oxley
Compliance-From Project to Process . PricewaterhouseCoopers LLP.
Protiviti. 2005. Integrated Compliance Efforts: Business Benefits Beyond Regulatory
Compliance . Protiviti Inc.
Sammer, J. 2005. New Horizons: Enterprise-wide compliance. Journal of Accountancy ,
August: 75-79.
Schreiber, Z. 2003. Semantic information architecture: creating value by understanding data. DM Review , October.
Sinnett, W. M., and E. M. Heffes. 2005. Is the pain worth the gain? Financial Executive ,
May: 30-32.
Sterman, J. D. 2000. Business Dynamics; Systems Thinking and Modeling for a
Complex World.
New York, NY: Irwin McGraw-Hill.
Uschold, M., M. King, S. Moralee, and Y. Zorgios. 1997. The enterprise ontology. AIAI
University of Edinburgh.
Wand, Y., and R. Y. Wang. 1996. Anchoring data quality dimensions in ontological foundations. Communications of the ACM, 39(11): 86-95.
Weber, R. 2003. Conceptual modeling and ontology: Possibilities and pitfalls. Journal of
Database Management, 14(3): 1-20.
Whitten, J. L., L. D. Bentley, and K. C. Dittman. 2001. Systems Analysis and Design
Methods, 5 th Edition.
New York, NY: McGraw-Hill Irwin.
Zuniga, G. 2001. Ontology: Its transformation from philosophy to information systems.
Proceedings FOIS’01, October.
23

APPENDIX A
Initial Values and Equations for the Benchmark and Risk-Assessed Models
BENCHMARK MODEL:
Cash(t) = Cash(t - dt) + (Stockflow_In) * dt
INIT Cash = 0
INFLOWS:
Stockflow_In = Cash_Receipts*(1-Sales_Discount_Rate)
Customers(t) = Customers(t - dt) + (chg_Customers) * dt
INIT Customers = 100
INFLOWS: chg_Customers = .02*Customers
Inventory(t) = Inventory(t - dt) + (- Stockflow_Out) * dt
INIT Inventory = 50000
OUTFLOWS:
Stockflow_Out = Sales*.75
Receivables(t) = Receivables(t - dt) + (Sales - Cash_Receipts) * dt
INIT Receivables = 1000
INFLOWS:
Sales = MIN(Customers*Customer_Demand__Factor,
Sales_Employees*Sales_Employee__Productivity)
OUTFLOWS:
Cash_Receipts = Receivables/Time_to_Collect
Sales_Employees(t) = Sales_Employees(t - dt) + (chg_Employees) * dt
INIT Sales_Employees = 100
INFLOWS: chg_Employees = 0
Customer_Demand__Factor = 10
Sales_Discount_Rate = .01
Sales_Employee__Productivity = 15
Time_to_Collect = 1
RISK-ASSESSED MODEL:
Cash(t) = Cash(t - dt) + (Stockflow_In) * dt
INIT Cash = 0
INFLOWS:
Stockflow_In = Cash_Receipts * (1-Sales_Discount_Rate) * (1 -
Risk_of_Innacurate_Cash_Collections)
Customers(t) = Customers(t - dt) + (chg_Customers) * dt
INIT Customers = 100
INFLOWS:
24

chg_Customers = Customers*.02
Inventory(t) = Inventory(t - dt) + (- Stockflow_Out) * dt
INIT Inventory = 50000
OUTFLOWS:
Stockflow_Out = Sales*(1-Risk_of_Inaccurate_or_Inappropriate_Shipments) * .75
Receivables(t) = Receivables(t - dt) + (Sales - Cash_Receipts) * dt
INIT Receivables = 1000
INFLOWS:
Sales = MIN(Customers*Customer_Demand__Factor,
Sales_Employees*Sales_Employee__Productivity) * (1-Risk_of_Inaccurate_Sales_Recording)
OUTFLOWS:
Cash_Receipts = Receivables/Time_to_Collect
Sales_Employees(t) = Sales_Employees(t - dt) + (chg_Employees) * dt
INIT Sales_Employees = 100
INFLOWS: chg_Employees = Sales_Employees*0
Customer_Demand__Factor = 10
Control_Activities = .95
Control_Environment = .95
Information_and_Communication = .95
Monitoring = .95
Risk_Assessment = .95
Risk_of_Inaccurate_or_Inappropriate_Shipments = 1 - RANDOM(MIN(Control_Activities,
Control_Environment, Information_and_Communication, Monitoring, Risk_Assessment), 1,
12321)
Risk_of_Inaccurate_Sales_Recording = 1 - RANDOM(MIN(Control_Activities,
Control_Environment, Information_and_Communication, Monitoring, Risk_Assessment), 1,
12345)
Risk_of_Innacurate_Cash_Collections = 1 - RANDOM(MIN(Control_Activities,
Control_Environment, Information_and_Communication, Monitoring, Risk_Assessment), 1,
54321)
Sales_Discount_Rate = .01
Sales_Employee__Productivity = 15
Time_to_Collect = 1
25

Resources
Inventory
FIGURE 1
REA Model Building Blocks
Events Agents
Sales
Employee
Part1
Stockflow
Out
Sale
Part2
Duality
Part3
Cash Stockflow
In
Cash Receipt
Part4
Customer
Resources: resources are things of economic value that are provided or consumed by an enterprise’s activities and operations. (i.e. cash or inventory)
Events: economic events reflect the stock inflows and stock outflows of economic resources. (i.e. sales or cash receipts)
Agents: agents are the persons, organizations, or organizational units that control or participate in economic events. (i.e. employees or customers)
Stockflow Relationship:
Duality Relationship: duality relationships link economic events that increment economic resources with corresponding economic events that decrement economic resources
Participation Relationship:
26

FIGURE 2
Systems Dynamics Models Building Blocks
Stock
InFlow OutFlow
Conv erter
Inflow and Outflow: flows fill and drain accumulations (stocks). The unfilled arrow head on the flow pipe indicates the direction of positive flow. (i.e. inventory receipts or shipments)
Stock: stocks are accumulations. They collect whatever flows into them, net of whatever flows out of them. (i.e. inventory)
Converter: the converter serves a utilitarian role in the software. It holds values for constants, defines external inputs to the model, and calculates algebraic relationships.
(i.e. sales). Converters connect to either inflows or outflows.
Connector: the connector (curved line between the converter and the inflow) connects model elements, allowing the user to define algebraic relationships between the elements. (In this case, Inflow is a function of Converter. See appendix A for examples)
Clouds: clouds represent the end of flows when flows do not connect to other stocks.
Valves: valves regulate flow rates on the flow pipe. (i.e., determine the periodic change in stocks)
27

LEGEND:
REA Relationship
DM Connectors
(OBDE) Mapping
FIGURE 3
Mapping an REA Model to a Dynamic Model of the Sales/Cash Receipts Process
Inv entory
Inventory
Cash
Stockf low Out
Stockflow
Out
Stockflow
In
Sale
Duality
Cash Receipt
Sales
Employee
Part1
Part2
Part3
Part4
Customer
Customers chg Customers
Customer Demand
Factor
REA Model
(REA)
Receiv ables
Cash
Time to Collect
Cash Receipts
Stockf low In
Sales Discount Rate
Sales
Sales Employ ees
Sales Employ ee
Productiv ity chg Employ ees
Dynamic Model
(DM)
28

Inv entory
FIGURE 4
Purchases/Cash Disbursement Process Dynamic Model
Vendors chg Vendors
Stockf low In
Market Price
Pay ables
Pay ments Purchase Rate
Time to Pay
Cash
Purchase Employ ee
Productiv ity
Purchase Employ ees chg Employ ees
Stockf low Out
Discount
29

Inv entory
Cash Receipts
FIGURE 5
Sales/Cash Receipts Process with Commitments
Customers
Stockf low Out chg Customers
Receiv ables
Time to Fulf ill
Sales Order
Sales Orders
Customer Demand Factor
Sales Order Rate
Sales
Time to Collect
Cash Sales Employ ees
Sales Employ ee Productiv ity
Stockf low In chg Employ ees
Sales Discounts Rate
30

Inv entory
FIGURE 6
Purchase/Cash Disbursement Process with Commitments
Vendors
Stockf low In chg Vendors
Pay ables
Time to Fulf ill
Purchase Order
Purchase Orders
MarketPrice
Pay ments
Purchase Rate Purchase Order Rate
Time to Pay
Cash
Purchase Employ ees
Order Productiv ity
Purchase Employ ees
Stockf low Out chg Employ ees
Purchase Discounts
Rate
31

REA Value
Chain Specification
FIGURE 7
REA Levels and Type Images
(adapted from Geerts and McCarthy 2002, fig. 2)
Accountability Infrastructure
Actual Business Events
Policy Infrastructure
Type Images
REA Process
Specification
REA Task
Specification is_part_of
REA
Process is_part_of
REA
Process Ty pe
Resource
Event
Agent
Commitment decomposes_into
Task-1 Task-2
Task-4
Task-3 governs
R Type
E Type
A Type decomposes_into
C Type
Task Type-1 Task Type-2 Task Type-3
Task Type-4
32

Inv entory
Stockf low Out
FIGURE 8
Sales/Cash Receipts Process with Risks
Customers chg Customers
Risk of Inaccurate or
Inappropriate Shipments
Customer Demand
Factor
Receiv ables
Cash Receipts Sales
Cash
Time to Collect
Stockf low In
Risk of Inaccurate
Sales Recording
Sales Employ ees
Sales Employ ee
Productiv ity chg Employ ees
Risk of Innacurate
Cash Collections
Sales Discount Rate
33

FIGURE 9
Linking COSO Model Components to Process Risk Converters
Control
Env ironment
Risk
Assessment
Control
Activ ities
Inf ormation and
Communication
Monitoring
Risk of Inaccurate
Sales Recording
Risk of Innacurate
Cash Collections
Risk of Inaccurate or
Inappropriate Shipments
34

Period
1
2
15
16
17
18
11
12
13
14
7
8
9
10
3
4
5
6
19
20
Benchmark
1008
1028
1230
1255
1280
1306
1332
1359
1386
1414
1049
1070
1091
1113
1136
1159
1182
1206
1443
1472
TABLE 1
Comparing Benchmark Results with Risk-Assessed Results
Over 20 Quarters
SALES STOCKFLOW (CASH) IN STOCKFLOW (INV) OUT
Risk
981
995
1195
1232
1249
1268
1290
1331
1333
1362
1025
1046
1048
1089
1119
1129
1166
1180
1406
1431
Difference Benchmark
26
33
991
1002
42
28
54
52
35
23
31
37
17
30
16
26
23
24
44
25
37
41
1194
1218
1242
1267
1293
1319
1346
1373
1019
1039
1059
1081
1102
1124
1147
1170
1400
1429
Risk
950
947
1124
1138
1196
1202
1218
1247
1268
1300
960
998
1004
1015
1052
1069
1096
1125
1309
1356
Difference Benchmark
41
54
756
771
75
72
78
72
69
80
46
65
50
56
51
46
59
41
55
65
91
73
922
941
960
979
999
1019
1040
1061
786
802
818
835
852
869
886
904
1082
1104
Risk
714
727
871
898
904
925
931
967
972
987
748
769
763
809
817
815
852
867
1022
1049
Difference
41
44
68
52
68
74
52
43
56
54
34
54
35
37
38
33
55
26
60
55
Total 24517 23872 645 23815 22575 1241 18388 17407 981
% Bench 3% 5% 5%
Initial parameters: Both models: Customers = 100; Employees = 100; Customer Demand Factor = 10; Sales Employee Productivity = 15; Time to
Collect = 1; Receivables = 1000; Sales Discount Rate = .01; Gross Margin = .25. Risk-Assessed model: Control Activities = .95; Control
Environment = .95; Information and Communication = .95; Monitoring = .95; Risk Assessment = .95.
35