Use of An Accounting Object Infrastructure for Knowledge

From: AAAI Technical Report SS-97-06. Compilation copyright © 1997, AAAI (www.aaai.org). All rights reserved.
USE OF AN ACCOUNTINGOBJECT INFRASTRUCTURE
FOR KNOWLEDGE-BASEDENTERPRISE MODELS
Guido L. Geerts and William E. McCarthy
Departmentof Accounting, N270North Business Complex
MichiganState University
East Lansing, MI48824, USA
E-mail: Geerts "23358MGR@msu.edu"
-- McCarthy "21277WEM@msu.edu"
Telephone: 517-355-7486Fax: 517-432-1101
Abstract
This paper reviewsthe basic tenets and structure of the
REA(Resource-Event-Agent)accounting model, and
discusseshowthat modelhas beenusedin a widevariety of
knowledge-intensive
environmentsto facilitate automated
reasoning concerning economicphenomenain business
enterprises. Themodel’sbasic conceptsandstructures are
reviewedat both higher (enterprise valuechain) and lower
(businessprocesstasks) levels of abstraction. Theuse
REAin someprototypeAI systemsandits use in empirical
assessments
is also discussed.
Introduction
Mostcorporateenterprise informationis concernedwith the
acquisition, transfer, conversion,and sale of economic
resourceslike cash, inventory,and supplies of labor and
services. Bydef’mition,such data traditionally has been
tracked primarily by accountingsystemswith individual
computerizedmoduleslike payroll, accountspayable and
receivable,job costing, order entry, andgeneralledger. In
both small and large companies,the accounting system
designers usually have a preemptivecall on the basic
schemesused to type economicdata either because of
statutory reportingrequirements
(to agencieslike the IRSor
the SEC)or becauseof private reporting requirementsto
creditors and shareholders. If accountants use these
preemptiveprivileges to force traditional accountcoding
onto the organization database as its fundamental
classification architecture(in other words,if they require
early joumalizing of Wansaction data), then many
dysfunctionaleffects arise. McCarthy
(1982)first noted
these, andhis list wasreiterated andexpandedby Andros,
Cberrington,and Denna(1992) in conjunctionwith work
41
that involvedrestructuringandconsolidationof all of IBM’s
worldwideaccounting systems. Prominent amongthese
dysfunctionalfeatures of traditional accountingenterprise
architectureswerethree that weintendto focusuponin this
paper: (1) their inability to integrate well withknowledgebased decision tools, (2) their inability to accommodate
process-orientedmodelsof the enterprise, and (3) their
inability to be usedinter-organizationally.Asa remedy
for
these deficiencies, weproposethe application of the REA
accountingmodelin the analysis, operation, anduse of an
enterprise information system.
REAspecifically
incorporates the semanticsof economicobjects into the
information architecture of a fLrm. Such embedding
facilitates couplingwith knowledge-based
decisionsupport
systems. Additionally,recent advancesin REAtheory have
incorporatedits explicit top-down
use as a processmodelof
enterprise economic
activities alonga value-addedchain.
This allowsthe processsemanticsof a firm’s constellation
of economicobjects to be viewedat multiple levels of
abstraction andto be used in understandingandusing the
corporatedatabase(Geerts andMcCarthy,1997).
Therest of this paperis organizedas follows.Wefast give
an overviewof the REA
accountingmodel,especially as it
can be viewed as a top-downportrayal of the basic
economicrationale for organizing and structuring a
company.Somewhat
informally, werefer to this rationale
as the "businessentrepreneur
script." Thisscript is simplya
process modelof the enterprise at different levels of
abstraction. The term REA(which stands for resourceevent-agent) refers to the prototypical economicobject
constellationassociatedwith eachprocessin this top-down
script. Following
illustration of the entrepreneurscript, we
moveto an expositionof an architecturefor the accounting
objectinfi’astructure,andwespeculateonthis architecture’s
use in the day-to-dayoperation of a business. Oncedone
with the architecture, wemoveto a comparison
of systems
built on PEAprinciples with those built on conventional
precepts. Our comparisons here will focus on the
possibilities for automated
reasoningandfor couplingthese
systemswith knowledge-based
decision tools. Wefinish
with an enumeration
for both the near anddistant future of
the possibleuses for our REAenterprise architecture. Our
listing will emphasizeimmediatepractical use of these
ideas, andour explanationswill includequickdescriptions
of three AIsystemsbuilt withthese ideas.
REAAccounting as a Business Entrepreneur
Script
In simpleterms, all businessesenterprises operate in the
samemanner.Somebody
has an idea about howto provide
a new/improvedservice or product (e.g., a better
mousetrap,a newwayto cure somemalady,a better/faster
wayto improvesomething,etc.). This entrepreneur then
acquiressomeinitial financingin the formof debtor equity
for the enterprise. Theentrepreneurthenengagesin a chain
of purposefuleconomic
exchangeswith other parties (like
vendors and employees), each time giving up some
economicresource (like money)in return for taking back
anotherresourceof greater valuewherevalueis defmedin
termsof a deliverableportfolioof attributesattractiveto the
fh’m’sultimate customers.Hopefully,mostentrepreneurs
fred that when they have consummatedtheir final
exchanges
with their customersandpaid off their creditors,
theyenjoya justifiable profit fromthese activities (i.e., in
the longterm, they take in morecash than they giveout).
Asuccessful entrepreneurcycles throughsuch a chain of
value-added
activities on a continualbasis. Acorporation
doesthe same,exceptin morebureaucraticfashion.
In processterms,this entrepreneur
script is illustratedat the
top of Figure1 at different levels of abstraction.Thetoplevel process "I engagein value-addedexchanges"is
explodedto the three process bubblesjust belowit where
each second-level process has identified economic
resources as both input and output (R.M.= raw materials;
F.G. = finished goods). Accountantswouldrefer to the
three second-levelprocessesshownfromleft to right in
Figure1 as the acquisitioncycle, the conversioncycle, and
the revenuecycle. AnPEAprocess modelof the fh’mcan
considersucha processhierarchyat great depths, although
wehaveshownjust two levels here. A typical enterprise
model would have a much deeper and wider process
hierarchy that wouldapproximatea Porter-type (1985)
value chain. Themicroeconomic
rationale for these entire
enterprise modelsis explained by Geerts and McCarthy
(1994b).
42
Surrounded
by a dotted line at the bottomof Figure1, we
have shownthe REAobject constellation (in entityrelationship form)of each exchangeprocess. In general,
each process explodesto eight entities, althoughthere
almost always is someoverlap. Each exchange has an
incrementevent (or possiblya set of events)linked with
decrementevent (or set of events). The incrementand
decrement
eventshaveentity constellationsthat are actually
mirror imagesof each other. Exact definitions for the
economic resources, the economic events, and the
economicagents follow from those given by McCarthyin
1982 as do the defmitions for the different types of
relationshipsinvolvedin the prototypicalobjecttemplate.
Tomakematters a little moreconcrete, wenote that the
revenuecycle of Figure1 (i.e., the bubblelabeled"I sell
f’mished goods") might have the following set of REA
entities:
decrement:a sale event occurs whichinvolves
givingthe resourcefinished goodsby an internal
agentsalespersonto an external agentcustomer
increment:a cash receipt event occurs which
involvestaking the resource cashby an internal
agentcashier froman external agentcustomer.
Readersinterested in howsuchentity constellationscan be
implementedwith database technology mayconsult Gal
and McCarthy(1986).
The RIgA Accounting Object Infrastructure
Whenthe entrepreneurscript is fully specified top down
and wheneach leaf node in the process hierarchy is
explodedto give its full complement
of REAentities and
relationships, a candidateenterprise schemafor a company
results. In almostall corporatecases, this schemawill be
augmented
with manyobjects that do not relate directly to
the acquisition,conversion,andsale of economic
resources.
However,the REAcomponentswill undoubtedlyform an
accountabilityinfrastructure for the corporateinformation
architecture. Theuse and maintenanceof this enterprise
objectmodelis portrayedin Figure2.
Wehaveattempted in the middle of this figure to show
simultaneously
both the processandeconomic
object flavor
of an REAinfrastructure. The five processes each have
their appropriate economicevents portrayed, although
space constraints preclude delineation of the economic
resourcesand agents. Readersinterested in seeing a full
entity-relationship modelfor a similar manufacturing
firm
mayconsult Davidand McCarthy(1995). Additionally,
eachof the eventsillustrated maybe further dividedinto a
set of tasks needed to accomplish them (Geerts and
McCarthy
forthcoming).
explainedin detail by Geertsand McCarthy
(1994a). What
it entails however can be summarizedquickly. The
repeated use of a standard object template in the
construction of an REAenterprise modelallowsautomated
reasoning (involving specific pattern matches on all
appropriateobjectconstellations)to occurat as higha level
of conceptdefinition as possible. Thus,instead of having
to write multiple proceduresto defmevarious types of
economicclaims (which in PEAterms are imbalances
betweensets of incrementsanddecrements),wefind that it
is possibleinstead to define sucha conceptonceandlet a
reasoner find its instantiations. Such use makesthe
semanticsof such definitions muchclearer by removing
themfromproceduresand makingthemdeclarative.
Onthe top left of Figure2, wehaveillustrated the inputs
which might be associated with day-to-day use of a
knowledge-intensive
enterprise informationsystembased
on our explanations thus far. Wenote that most of the
populationof the conceptsin the objectstructureof the firm
wouldcomefrom its transaction level input. However,
other sourcescouldbe usedsystematicallyin an integrated
fashion. Thesemightinclude both managerialinformation
and estimates from inside the firm (such as budget
informationor engineeringspecifications for a bill of
materials)andpubliclyavailabledata fi’omoutsidesources
(such as commodityprices or information on product
substitutes/complements
fromcompetitors). Theimportant
point to remember
for enterprise operationhere is that REA
specification of economicphenomenaallows semantic
integration of data fromdisparatesources.Thusa piece of
inventorycould be given an integrated descriptionof its
cost andavailability (fromtransactiondata), its physical
specifications (from engineering estimates), and its
competitiveness (from outside data sources). Such
integratedsemanticsare impossiblein traditional business
informationsystemswhichrely on bookkeepingartifacts
for classificationpurposes.
How RIgA Object Enterprise
Models Can
Work with Knowledge-Based Tools
At present, there havebeenonly a handfulof directed PEA
implementations
in actual companies,althoughfirms like
Price-Waterhouseand IBMhave adopted certain of its
principles as guidingarchitectural features for accounting
systemdesign (Cherringtonet al. 1993). Noneof these
implementationshave beenfulI-REAmodelsin the sense
of the object enterprise modelshownin Figure2 whereall
processes and objects are specified and implemented
without cost-benefit compromise.
Empiricalassessmentof
the possibilities for the accountingsoftwaremarketplace
to
be able to movetoward full-PEA implementations is
somethingwe plan to do in the future. For the present
section, however, we assume that the technology
constraints of processingtime andstoragecapacities could
be overcome,and wespeculate in Figure 3 howsuch full
process modelsmight be linked with certain types of
knowledge-basedsystems. Such an assumption and its
accompanying
discussionis actually quite realistic in a
methodological
environment
wherethe full possibilities for
an architecture are considered thoroughly in an early
assessment phase unfettered by cost and technology
constraints.
On the top right of Figure 2, we show the outputs
associated with daily operation of the REAobject
enterprise model.Reports to managersmightnot differ
muchfrom traditional architectures, but coupling with
decision support systems-- especially if those systems
contain semanticallyspecified components
-- mightchange
dramatically. AnREAenterprise informationarchitecture
maintains its object-level and process-level semantics
within itself. In a way,its meaningis conveyedwith its
data, and this makesany connectionto anotherautomated
systemless problematicbecauseit leaves less roomfor
misinterpretation. This "conveyedmeaning"also makes
automated
use of components
of the enterprise modeleasier
for users outside the f’mn.Suchuse wouldfacilitate the
development
for instance of "conceptualEDI."
Figure3 illustrates howinformationabout the real world
(in the shapeat the middleleft) mightbe filtered through
financialdecisionmakers(in the circle at the middleright)
throughtwodifferent types of accountingsystem.Bothold
(bookkeeping-based) and new (PEA-based)accounting
showproposed use of knowledge-basedtechnology with
lines emanatingfrom the decision makers;however,the
difference is in the nature of their linkages to the
computerizedinformation system of an enterprise. Both
are describedbelow.
At the bottomof the REAobject enterprise modelshownin
the middleof Figure2, wehaveportrayeda component
of
these systemswhichperhapsdifferentiates themthe most
fromtraditional accountinginformationarchitectures-- the
specificationof additionalconceptdeclarations.Theuse of
suchdeclarations in a knowledge
intensive environment
is
44
m
o
t._
e~
z..
t._
om
oamlb
2)
45
r-
cOo
zo
46
Thetop of Figure3 illustrates the architectureneededfor
FSA,one of the early AI prototypes intended to be used
with the EDGAR
system. (Mui and McCarthy1987). FSA
(Financial StatementAnalyzer)wasable to take automated
corporatefiling data (froma 10-kreport for example)and
calculate any numberof f’mancialratios commonly
usedby
analysts in assessing the financial well-being of a
corporation. This seemslike a relatively straightforward
task, and indeed, it is one that is often taught in
undergraduatefinance and accounting classes. Havinga
machinehandle the task completelyhowevercaused the
FSAdesigners fromArthurAndersento confrontthe highly
idiosyncraticnatureof old accounting
systems.First of all,
an exhaustivechart-of-accountsknowledge
structure had to
be built into FSAbecause of the individualistic and
synonymous
namingconventions used by manycompanies
to label variousasset, liability, equity,income,andexpense
accounts. Second, because muchof the actual account
informationis buffedin textual foomotes,FSAalso hadto
be equippedwith NLPcapabilities for certain limited cases
suchas the contra-accounts
for depreciation(on inventory)
andsub-leases (on rental expense).Theseare adjustments
that expert humananalysts fmdsomewhat
easy, but which
cause significant interpretation problemsfor a fully
automatedsystem.
FSAworkedwell in its very limited domain,althoughit did
require a high level of expertise with knowledge
representation structures and tradeoffs, with knowledge
acquisition problems, and with object-oriented
programming
techniques(in KEE)to makeit operational.
A companionAI system called ELOISE
(used for natural
languageprocessingof other 10-kmaterial) wasalso built
for EDGAR
by Arthur Andersenat approximatelythe same
time. However,
neither of these systemsnor any similar AI
efforts werepart of the productionversions of EDGAR
that
wereimplemented
in the 1990s(Thereforethe only actual
use optionfor prospectiveusers is the indicateddirect link
to the EDGAR
files). Therationale for this exclusionwas
not madepublic, but a compellingcase can be madefor one
reason whyit was not attempted. All the semantics
necessaryfor a systemlike FSAto function had to come
fromthe AI tool itself becauseof the idiosyncratic and
syntactic nature of the accountingreporting systems. A
good example of such idiosyncrasies were the many
conventions needed to cover receivables (These are
explainedin Figures 2 &3 in Muiand McCarthy
(1987)).
As wementionedin our last section, PEAcoverageof such
claims is muchmore direct and declarative. If the
accountingsystems in question had moreof a semantic
base, building expert systemsto workon (or with) them
might not have been such a daunting hurdle. As EDGAR
exists in 1996,its disseminated
outputcontainslots of data
but verylittle assistancein determining
the meaning
of that
data. Therefore it is no surprise that technologically
sophisticated efforts are under wayto "intelligently
process" EDGAR
output for users whofred its present
offeringsless thanusable.
At the bottom of Figure 3, we have illustrated howa
reconfigureddecision support systemlike FSAmightwork
for f’mancialdecision makersin an PEAenvironment.The
process and (more importantly in this case) the object
semantics in an PEAimplementationremain intact and
reside with the enterprise model.UnlikeFSAwhichhadto
be augmented with account hierarchy and footnote
schemataknowledgestructures, our newknowledge-based
systemwouldneedonly the structures associatedwith the
specific decisionexpertise(suchas whetherto invest in
certain type of stock). If this expertise werecodedas
semanticnetwork, the coupling betweenthe two systems
wouldbe especially close. Essentially, the expert system
wouldspecify the concepts only at the type level with
individual consultations being instantiated with direct
object-object connections.Theorganizationalandcapital
marketramificationsof such direct corporate databaseto
decision-maker
links involvea set of issues describedby a
numberof accounting theorists. These argumentswere
summarized
and analyzedrecently by Geerts and McCarthy
(1995).
Possible Migrations toward REAEnterprise
Models and Uses for Research Results
In this paper, we have outlined the PEAapproach to
building object infi~structures for enterprise process
models.Wewouldlike to emphasizethat, although it is
certainly true that our modelslook quite different from
traditional accountingarchitecturesbuilt uponbookkeeping
ideas, it is also the casethat there are enterprisesoftware
packagesthat afford hospitable implementation
platforms
for systems built upon PEAprinciples (for examples,
readers may consult McCarthy, David, and Sommer
(1996). This is becausemanyof the database tenets
which PEAwas originally based in 1982 -- such as an
emphasis
on strong semantics,an insistenceon versatile use
and delayed procedural aggregation of economic
transaction data, and a strong orientation towardwider
communities
of users to include both accountantsandnonaccountants- are features that makeaccountingsoftware
attractive in the 1990s.Webelievethat it is possibleto take
a strong directed PEAapproachto building enterprise
modelsthat can serve both as blueprints for strategic
informationarchitectures and as initial databaseschemas
that can be compromised
by cost-benefit considerationsin
individual companies.In this sense, our PEAframeworks
are like the "prototypical models"for certain lines of
businesses that someanalysis methodologiesadvocateas
starting points for informationsystemdesign. Withsuch
possibilities in mind,wefinish by mentioninghowsomeof
the REA
researchaccomplished
thus far can affect practical
designof enterprise modelsthat facilitate knowledge-based
use.
Ourresearch and practical implementationworkwith REA
modelingof accounting phenomena
has progressed on a
numberof software engineeringand empirical validation
fronts, summaries
and assessmentsof whichare listed in
Durra and McCarthy(forthcoming). For example,wehave
built the following knowledge-based
systemswith these
principles.
a.
b.
C.
REACH-- This is a CASEtool for view
modelingand view integration that integrates
three different types of knowledge:
(1)first order
principles of the REAtemplate, (2) heuristic
guidance of implementationcompromisesbased
on object pattern matches,and(3) reconstructive
ideas for prototypical modelsbaseduponlibrary
guides for the design of account-based
bookkeepingsystems (McCarthyand Rockwell
1989).
CREASY
-- This is also a CASEtool that
supportsconceptualandoperationaldesignof fullREAmodels. The CREASY
environment embeds
both methodsknowledge(of semantic modeling
structures and constraints) and domain-specific
knowledge(of REAaccounting) for automated
use by novice modelersand users (Geerts and
McCarthy1992).
REAL
-- This is a knowledge-baseddecision
support tool of the type identified in our
discussionof Figure3. REAL
is an expert system
for purchasing that embodiessemantic network
representationsof certain logistical facts suchas
the location of transportation vehicles and the
patternsof past deliveriesof rawmaterials.These
expert systemintensionalstructures are linked to
REAdatabases for actual operation whereinthe
object conceptsare instantiated for a particular
consultation (McCarthy
and Rockwell1991).
Theseand other knowledge-based
REAtools are reviewed
in an integrated methodological fashion by Geer~,
/48
McCarthy,and Rockwell(1996) whosuggest manyother
possible ways where the REAmindset can assist an
enterprise modeler. Additionally, there has been some
initial empirical assessmentsundertakenof (1) howREA
principles fare in promotingbetter decision-making
environments
(by controlling complexitywith object-level
interfacesable to manipulate
levels of semanticabstraction)
for individuals (Dunn1995). and (2) howREAadherence
in actual accountingsystemoperationcan affect perceived
levels of competitive advantage associated with an
accounting system (David, 1995). Results of these
empirical assessmentshave beententative and mixed;we
plan to continuea programof such assessmentsto pinpoint
waysin whichREAprinciples can be best used in actual
operation.
References
Andros, D. P., J. O. Cherrington, and E. L. Derma.
"Reengineer Your Accounting,the IBMWay,"Financial
Executive, July/August1992,pp. 28-31.
Cherrington,J O., W.E. McCarthy,D. P. Andros,R. Roth,
and E. L. Derma,"Event-Driven Business Solutions:
ImplementationExperiencesand Issues," Proceedingsof
the FourteenthInternational Conferenceon Information
Systems, Orlando,December
1993,p. 394.
David, J. S. and W.E. McCarthy,"Ventura Vehicles:
TeachingNotes and DatabaseImplementations,"Michigan
State University,1995.
David, J. S. An Empirical Analysis of REAAccounting
Systems, ProductivRy, and Perceptions of Competitive
Advantage,PhDdissertation, MichiganState University,
July, 1995.
Dunn, C. L. "AnAbstraction Hierarchy as a Database
Interface: Doesit Control Complexity?,"Workingpaper,
FloridaState University,1995.
Durra, C. L. and W. E. McCarthy, "REAAccounting
Systems:Historical Antecedentsand Future Directions,"
Working
paper, MichiganState University,1995.
Gal, G. and W.E. McCarthy,"Operationof a Relational
AccountingSystem,"Advancesin Accounting,No.3, 1986,
pp. 83-112.
Geerts, G. L. and W. E. McCarthy,"The ExtendedUseof
Intensional Reasoningand 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, (3. L. and W. E. McCarthy, "Augmented
Intensional Reasoning in Knowledge-BasedAccounting
Systems," Paper presented at The International Workshop
on Knowledge-BasedSystems and Strategic Management,
ABO,Finland, June 1994a.
(3eerts, (3. L. and W. E. McCarthy, "The Economicand
Strategic Structure of REAAccounting Systems," Paper
presented to the 300th Anniversary Program,Martin Luther
University, Halle-Wittenberg, Germany,September1994b.
Geerts, G. L. and W. E. McCarthy "The Semantic
Reofientation of Financial Information Systems for
Strategic Use," Proceedings of the Second Annual
Financial Information Systems Conference, Sheffield,
England, June 1995.
McCarthy,W. E. and S. R. Rockwell, "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, "Database
Instantiation
of Transaction Templates in an Expert
System," Paper presented at The International Conference
on Expert Systems in Management and Accounting,
Pasadena, California, October 1991.
Mui C. and W. E. McCarthy, "FSA: Applying AI
Techniques to the Familiarization Phase of Financial
Decision Making,"IEEEExpert, Fall 1987, pp. 33-41.
Porter, M. E. Competitive Advantage: Creating and
Sustaining Superior Performance. NewYork, The Free
Press, 1985.
(3eerts, (3. L. and W. E. McCarthy"Modeling business
enterprises as value-added process hierarchies with
Resource-Event-Agentobject templates," in J. Sutherland
and D. Patel (eds.).
Business Object Design and
Implementation, Springer-Verlag, forthcoming.
Geerts, G. L. and W.E. McCarthy,"Using Object
Templates from the PEAAccounting Model to Engineer
Business Processes and Tasks," paper to he presented at
the EuropeanAccountingAssociation, (3raz, Austria,
April 1997 (forthcoming).
Geerts, G. L., W. E. McCarthy and S. R. Rockwell,
"AutomatedIntegration of Enterprise Accounting Models
Throughout the Systems Development Life Cycle," The
International
Journal of Intelligent
Systems in
Accounting, Finance & Management, September 1996,
pp. 113-128.
McCarthy, W. E. "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., J. S. David, and B. S. Sommer," The
Evolution of Enterprise Information Systems -- From
Sticks and Jars Past Journals and Ledgers Toward
Interorganizational
Webs of Business Objects and
Beyond," paper presented
to the OOPSLA 1996
Workshop on
Business
Object
Design and
Implementation.
/49