Printer Friendly

A teaching case for understanding the data structure of an accounting database: comparing a commercial system to REA.


This case concerns design of a database for an accounting system. It compares two databases: a database from an actual market-leading accounting system and a database designed using the REA database design methodology. REA is often taught in accounting information system courses. This course is written for students that have had some exposure to both REA and database design. Its most common use would be in an accounting information system course, either at the undergraduate or the graduate level, but it could also be taught in a database design course if the students were to spend extra time learning the REA methodology. The case is designed to require approximately one hour in-class discussion and two hours out-of-class student preparation for students familiar with both REA and database design basics. Other students will need to spend additional time mastering these topics based on the level of their knowledge.


A recent college graduate is hired as an accountant attempts to reconcile what he learned in college with an actual accounting system. The underlying database structure of the actual accounting system is significantly different than how he learned a database system should be structured. In understanding the actual accounting database, he attempts to work out why the actual system is different. This case is designed to help students develop skills in analyzing accounting databases and understanding the structure of accounting databases. Textbooks, research, and educational cases related to databases focus on using REA as a design methodology of accounting systems. Although accounting systems in practice include some elements of REA, they also include elements that REA eliminates. In this case, students compare an accounting database from Great Plains to the REA methodology and evaluate why the differences exist.


Teaching Approaches

REA is taught in the majority of accounting information system courses (Bradford et al., 2007) and related topics take up a significant portion of accounting information systems textbook pages and course time (Badua, 2008; Bain et al., 2002). Research on accounting systems is also primarily oriented toward the REA methodology (Geerts, 2009). Similarly, educational cases related to accounting information systems are also primarily oriented toward using the REA methodology. Actual accounting systems, while having some similarities to the REA methodology, include tables that would not be concluded in an REA-compliant system. This case gives instructors of accounting information systems courses a method to relate REA as described in textbooks to the structure of an actual accounting system.

The case objectives are to help students

1. Understand REA,

2. Understand database structure of accounting systems used in practice,

3. Understand implementation compromises in implementation of accounting systems for reasons of efficiency.

Accounting education journals include many cases for creating querying accounting databases, but all of these cases use databases based on the REA methodology. By including databases that are built strictly on the REA methodology, these cases miss the opportunity to familiarize students with components of accounting system databases that are present in almost all practicing accounting systems, including general ledgers, journal entries, financial statement preparation, and decision support. This case can be used to fill the gap between the REA database methodology as taught in accounting information system textbooks and the database structure of actual accounting systems.

This case focuses on the structure of Great Plains Dynamics, which is a common accounting software product. Many practice sets are available for accounting information system classes using Great Plains (Arens & Ward, 2008; Yacht & Crosson, 2006), so using Great Plains should be convenient of accounting faculty. None of these practice sets involve investigating the actual data structure of a Great Plains implementation, although they may be written as if Great Plains is consistent with REA (Brundson et al., 2005). Although different accounting software brands are built upon a unique database structures, they should be similar to Great Plains (eg. O'Leary, 2004).

The case could be used in either a first or second semester accounting information systems course. Alternatively, the case can also be used in a database design course. Students completing the case should have been taught REA, database normalization, and entity relationship diagrams. The case should be discussed when due from the students.

Some suggested questions to ask the students include

1. List the differences between REA and Great Plains.

2. Describe why you think Great Plains is different than REA. Do the differences make for a better or a worse system?

3. Do the financial reporting requirements of Generally Accepted Accounting Principles (GAAP) influence the difference between Great Plains and REA?


1. List the differences between REA and Great Plains.

Great Plains retains accounting artifacts such as double-entry accounting and a general ledger. One of the primary characteristics of REA is the elimination of double-entry accounting and general ledger, as this is perceived as unnecessary categorization and summarization that reduces the value of accounting data.

Great Plains contains summary data in decision support tables in addition to detailed data included in transaction tables. REA requires that data be stored at the most basic level without summarization, which should be sufficient for decision support.

Great Plains is similar to REA in that is substantially includes the REA framework by including tables for storing transactions, resources, and parties to transactions. It merely adds structure that REA eliminates.

2. Describe why you think Great Plains is different than REA.

Two hypotheses are possible concerning the cause of the difference. Proponents of REA may say that accounting artifacts are present in Great Plains because of the inertia in changing accounting systems. Because accountants expect to see a general ledger and a chart of accounts, Great Plains includes them despite the resulting inferior system. The decision support files could be viewed as an unnecessary addition, as the same data could be gleaned from the transaction files.

An alternative position is that accounting systems include accounting artifacts and decision support tables for valid reasons. A paper about REA concluded that "...if existing systems are using the REA model or its constructs in some conceptual or compromised fashion, such implementations must have benefits that exceed their costs" (Dunn & McCarthy, 1997). The same reasoning can be applied to accounting artifacts. Benefits of using a general ledger and chart of accounts include

Summarized information for preparation of financial statements is available without a user having to create a query to generate the financial statements. Producing such a query may be beyond the expertise of many users.

Because the information is made available by the posting process, the transaction system is not slowed by processing queries to generate financial statements. In an REA system, querying data in the transaction processing tables can take computing processing resources away from transaction processing and slow transaction processing.

Financial statement format is largely determined by regulation. Including financial statements in accounting systems takes advantage of economies of scale by not requiring each user to generate a unique query to obtain the information.

The actual database underlying an accounting system like Great Plains is quite complex. By storing summarized financial information in a general ledger, Great Plains reduces the need for an end user to understand and navigate the database.

Most of the same arguments can be used in favor of the decision support tables. Storing duplicate information in summarized form eases the task of obtaining that information and reduces the strain on a transaction processing system of running decision support queries.

3. Do the financial reporting requirements of GAAP influence the difference between Great Plains and REA?

The answer to the preceding question mentions how GAAP influences the design of Great Plains. Data is stored and reports are formatted in a system that complies with GAAP. REA can be thought of as both a way to design an accounting system as well as a philosophy regarding the accounting process and financial reporting. Papers on REA primarily stress using REA to design an accounting system, but wide acceptance of REA as an accounting system design methodology probably would depend on a fundamental reexamination of the accounting model would a move away from double-entry accounting. REA research has not considered how REA would institute complex accounting situations such as accounting for business combinations and derivatives.


Arens, A. A. & Ward, D. D. (2008). Computerized Accounting Using Microsoft Dynamics GP 10.0. (4th ed.) Okemos, Michigan: Armond Dalton Publishers Inc.

Badua, F. (2008). Pedagogy and the PC: Trends in the AIS curriculum. Journal of Education for Business, 259-264.

Bain, C. E., Blankley, A. I., & Smith, L. M. (2002). The examination of topical coverage for the first accounting information systems course. Journal of Information Systems, 16, 143-164.

Bradford, M., Richtermeyer, S. B., & Roberts, D. F. (2007). System diagramming techniques: An analysis of methods used in accounting education and practice. Journal of Information Systems, 21, 173-212.

Brundson, T. J., Romney, M. B., & Steinbart, P. J. (2005). Introduction to Microsoft Great Plains 8.0: Focus on Internal Controls. Upper Saddle River, New Jersey: Prentice Hall.

Dunn, C. & McCarthy, W. E. (1997). The REA accounting model: Intellectual heritage and prospects for progress. Journal of Information Systems, 11, 31-51.

Geerts, G. L. (2009). Introduction to the REA 25th Anniversary Special Section. Journal of Information Systems, 22, 215-217.

McCarthy, W. E. (1979). An entity-relationship view of accounting models. The Accounting Review, 54, 667-686.

McCarthy, W. E. (1982). The REA accounting model: A generalized framework of accounting systems in a shared data environment. The Accounting Review, LVII, 554-578.

O'Leary, D. (2004). On the relationship between REA and SAP. International Journal of Accounting Information Systems, 5, 65-81.

Whaley, R. L. (2005). Great Plains Information Flow & Posting. Altamonte Springs, Florida: Accolade Publications.

Yacht, C. & Crosson, S. V. (2006). Computer Accounting with Microsoft Business Solutions Great Plains 8.0. New York: McGraw Hill.

Darryl J. Woolley, University of Idaho
COPYRIGHT 2012 The DreamCatchers Group, LLC
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2012 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Woolley, Darryl J.
Publication:Journal of the International Academy for Case Studies
Article Type:Case study
Geographic Code:1USA
Date:Feb 1, 2012
Previous Article:The development of a strategic plan for HealthTrust Utah.
Next Article:Advanced Game Products, Inc.

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters