REA, XBRL and More Frequent Business Reporting:
Synergies for the 21st Century Accounting Information
System
Abstract:
Timely and efficient communication between an enterprise and its information
stakeholders (i.e., bank, governmental regulators, investors, supply chain, etc.) is even
more critical in current times due to the recent accounting scandals and more scrutinized
regulation. However, much of today’s current accounting information systems’
technology simply automates manual processes, without providing improvements.
Additionally, key nonfinancial business information is either not recognized or lost in
communications due to the narrow view of many traditional accounting information
systems (AIS). As a result, disparate systems with poor interoperability make many
enterprises’ reporting processes inefficient and costly.
Feng et al. (2002) designed a conceptual model incorporating XML and a generic
semantic network in order to efficiently exchange data. The Resource-Event-Agent
(REA) model of business processes is a specific semantic mechanism used to capture the
economic data of an enterprise. REA also provides an accepted accounting theory for
model development. The combination of REA and an Extensible Markup Language
(XML) “family” member called XBRL (eXtensible Business Reporting Language), Web
Services, and an Internet transmission protocol, should provide cohesive synergies. The
synergies, in turn, should produce more frequent business reporting and benefits such as
increased interoperability, efficiency, and a lower cost of capital. The current paper
builds on Feng et al. and attempts to be the first to link REA and XBRL in more
comprehensive and semantic AIS. Adopters of the proposed AIS could reap several
critical benefits, as listed above.
Key words: XBRL; REA; Nonfinancial Information
Introduction
Currently, there is a technology shift to more semantic architectures and objectoriented programming (Geerts and McCarthy 1997). As a result, the information systems
marketplace should expect to see different methods of tracking economic phenomena in
an enterprise’s environment. Traditional accounting systems lack the semantics and
provide too narrow of an accounting “view” to provide relevant and timely information
throughout an enterprise. In many instances, the accounting information system (AIS) is
incompatible with other functional information systems within an enterprise, as well as
the systems of enterprises within the supply chain and other information stakeholders’
(i.e., banks, governmental organizations, investors) systems. Thus, significant and costly
inefficiencies arise when business event data collection is attempted and communicated
within and outside of an enterprise.
The Resource-Event-Agent (REA) model of information systems is an eventbased, semantic model for capturing economic data involving an enterprise.
Conceptually, a REA-based system can capture a comprehensive set of business
information, many times in a more efficient manner than other accounting models and
disparate systems. Yet, there are relatively few REA-based information systems in the
current marketplace. This result is due, in part, to unaddressed, physical design issues.
Physical design issues are not only one major reason for a relatively small amount
of existing REA-based information systems, but also an area of sparse research
(McCarthy 1999). What is needed to supplement the conceptually sound REA
architecture is a language both humans and computers can read and understand using any
3
combination of hardware and software. That language is eXtensible Business Reporting
Language (XBRL).
XBRL is a non-proprietary, Web-based language based on Extensible Markup
Language (XML) that tags financial and nonfinancial data and gives it context. XML
and its derivatives have become increasingly important data formats for storing and
exchanging business data among various systems on the Internet. Through the use of
Web services and a transmitting protocol such as Simple Object Access Protocol
(SOAP), enterprises all over the world are able to send and report business information in
almost real-time. However, XML-based systems lack the modeling power necessary to
describe real-world data and their complex interrelationships, which represent the
necessary semantics (Feng et al. 2002). Therefore, a business model combining XBRL
(XML for business reporting) and REA (an accepted accounting theory that provides
semantics to business data) could provide various synergies to both the companies that
adopt the model and the stakeholder users that receive the information.
An efficient and effective business model is especially critical given the
regulatory environment the accounting profession currently finds itself in. New U.S.
regulation (e.g., Sarbanes-Oxley and Regulation Fair Disclosure (FD)) and international
regulation (e.g., Direct to APRA in Australia) have resulted in the formation of new
business reporting models in which more frequent business reporting of material
information is required. XBRL is a technology many see as a key cog to enterprise
continuous reporting and a mechanism to comply with regulation.
Feng et al. (2002) designed a conceptual model that incorporated XML and a
generic semantic network. However, their purposes were to enforce XML conceptual
4
modeling power and validate the XML schema, rather than apply it to a specific AIS and
semantic mechanism. The current paper attempts to build on Feng et al.’s model and be
the first piece of academic research that combines XBRL usage with a relatively wellknown information system model, REA. Both provide similar benefits in terms of
efficiency and interoperability gains and could be a useful marriage when an enterprise is
regulated to disseminate information more quickly.
The current paper is designed in the spirit of Geerts and McCarthy (1997) as a
non-technical description of REA, XBRL, and an AIS incorporating both. The following
section provides a brief background of the REA model, followed by a description of the
benefits a Full-REA system would provide over its traditional counterpart. Then, XBRL
is introduced and discussed as a technology for internal and external business reporting.
The next section describes how the two concepts can be combined to take advantage of
their synergies as shown through examples. The paper concludes with a look at existing
software incorporating XBRL and a summary of the major points made.
The REA Model
Background
Derived from Codd’s (1970) relational framework, Chen’s (1976) methodology,
and causal double-entry concepts advocated by Ijiri (1975), McCarthy (1979, 1982)
proposed his seminal REA model as a means for an enterprise’s AIS to capture the
essence of economic exchanges between two parties. The REA model is deeply
grounded in accounting and economic theory (Geerts and McCarthy 1997) and designed
to provide information in order to answer five questions about an economic exchange
5
(Hollander et al. 1995; Denna et al. 1998): What happened? When did the exchange
occur? What roles were played and by whom? What kind and how many resources were
used? Where did the exchange occur? In its simplest form, the REA model captures an
economic exchange by recording the duality between parties in terms of stock flows and
control. Specifically, stock flows refer to the relationship between events and resources
and control refers to the relationship between events and agents. Figure 1 is adopted
from McCarthy (1982) and displays the simplified REA model.1
[Insert Figure 1 about here]
REA as a Business Process Model and Architecture
In order to understand how the REA model fits the ideas of this paper, it is
important to gain a more thorough understanding of its transcendence from an accounting
system model to a business system model. Although the model was originally developed
to provide a generalized framework for AIS in a database environment (McCarthy 1982),
it has evolved to be more comprehensive. Specifically, REA modeling has been
discussed as a method for enterprise information systems to capture all business
processes and events (Denna et al. 1998). Individual business events represent the
building blocks for economic events and are defined by Denna et al. as “any strategically
significant business activity management wants to plan, control, and/or evaluate (p.
356).” A Full-REA designed AIS would emphasize the impact of recording the essential
characteristics of business events and, with proper authority, makes the information
available to information stakeholders internal and external to an enterprise. Full-REA
modeling refers to tracking how resources are traced through enterprise specific business
functions, how business processes are interrelated and how they contribute to value, as
6
well as how specific tasks effect completion of economic events and how business
processes are controlled (Geerts et al. 1996).
The AIS architecture also needs to be considered. Architecture refers to how
data are organized and the nature of the information processing that takes place within the
system (Walker and Denna 1997). There are decided benefits to an enterprise that adopts
an AIS with a Full-REA architecture (Geerts and McCarthy 1997). One major benefit is
due to the patterns a Full-REA architecture produces. Specifically, the pattern matching
procedures produced result in wide applicability. This, in turn, enables characterization
of key procedural definitions at relatively high levels of abstractions. Many ad hoc
enterprise information systems procedures are not as applicable and definitions tend to be
disintegrated, single case programs. Additionally, the ability to create the definitions at
such a high level of abstraction allows the enterprise to focus on key procedures earlier in
the design process and induces flexibility into the system.
Other benefits of a Full-REA architecture include enabling and enhancing a
semantic strategy for reusability and interoperability (Geerts and McCarthy 1997). In
terms of reusability, a Full-REA architecture requires information to be entered into the
system only once and then reused by information stakeholders many times to fit their
particular needs. Interoperability refers to communication between different systems.
The communication could either be between systems of the same enterprise (e.g.,
accounting and human resource systems) or between two enterprises (e.g., an enterprise
and one of its vendors).
At the process level of a Full-REA architecture, business events are highly
congruent (i.e., they all look similar to the business enterprise system) irregardless of the
7
specific event or the cycle involved (i.e., acquisition, conversion, revenue; Geerts and
McCarthy 1997). The congruency provides an enterprise adopting this type of
architecture an advantage in terms of efficiency (the information requested only needs to
be processed once), effectiveness (reduction in human error due to less data entry
instances), and lower data storage costs. As a result, all information stakeholders
querying a Full-REA business event driven system are satisfied quicker, eventually
turning the advantages into profits (Walker and Denna 1997).
Although adopting a Full-REA event driven AIS can theoretically produce
significant benefits for an enterprise, the author is unaware of any of these systems
currently being implemented. McCarthy (1999) mentions that there are no Full-REA
systems or directed-REA (i.e., use of original REA model is an explicit part of system
building) enterprise packages implemented yet, although there is an increasing number of
directed-REA databases (e.g., GENEVA2 from Price Waterhouse Consulting) that are
being implemented (McCarthy et al. 1996). There are potentially many reasons for the
lack of a more REA-intensive enterprise system.
The accounting system may be the biggest impediment to significant advances in
AIS that incorporate Full-REA, due to its role as the dominant business information
source. No other functional area has the ability to combine performance measures of all
functions of business into one set of measures, hence the title of accounting as the
“language of business.” The problem is that accounting information systems are being
designed from an accountant’s view, and thus, there is a focus on only a subset of
business events that are determined by accountants to be considered “accounting
transactions,” at the cost of key nonfinancial information. Further, much of what a
8
traditional accounting system contains is generated from various sources, summarized,
and reformatted to conform to Generally Accepted Accounting Principles (GAAP) and an
architecture supporting a general ledger chart of accounts. Non-GAAP reports and
conformance with international standards are made more difficult due to this narrow
focus and summarized information (Walker and Denna 1997).
Another reason is companies are currently attempting to build 21st century
enterprises on the back of 20th century architectures, which are designed to automate
manual information systems rather than improve the processes and procedures of the
work accomplished (Walker and Denna 1997). Modern information technology is able to
support relationships within and between enterprises, but is not being used to the full
extent possible. Thus, the traditional, debit-credit-account (DCA) accounting system is
automated, along with systems of the various other business functions, instead of a FullREA system.
REA vs. The Traditional Architecture
Traditionally, accounting information systems with individual modules (such as
accounts payable and general ledger) track the acquisition, transference, conversion, and
selling of economic resources like cash and inventory (Geerts and McCarthy 1999).
Additionally, this data has been necessary to meet either statutory reporting requirements
or reporting requirements for various information stakeholders. As a result, AIS
designers have a preemptive call to design systems to capture this data.
If accountants use these preemptive privileges in an AIS to form a traditional
architecture as its primary database, many dysfunctional effects arise (Geerts and
McCarthy 1999). These effects include “an inability to accommodate the process-
9
oriented models of the enterprise, integrate well with knowledge-based decision models
of other enterprise domains such as supply chain management and strategic decision
making, and support interorganizational use (p.89).” The REA model incorporates the
necessary enterprise semantics into its architecture, allowing for horizontal and vertical
integration, reuse, and interoperability. The next three paragraphs will expound on the
dysfunctions mentioned.
Traditional architectures have been driven by functional boundaries that define
the various views (such as accounting, human resources, etc.) of an enterprise (Denna et
al. 1998). Since these views have overlaps and gaps, the AIS supporting them do as well.
The results of the views and systems often do not provide information that enables an
enterprise to manage its business processes. The REA architecture applies business rules,
designed by an enterprise, while the business event occurs and captures data about the
business event at the same time through what is called a business event processor. The
captured data is stored in a business data repository that allows all business data to be
integrated and accessible to all information stakeholders. A version of the REA model
has been used for similar purposes in proposing a more comprehensive schema for data
warehouses (O’Leary 1999).
In terms of supply chain management, the REA architecture can be thought of as
a semantic Web that can conceptually link economic events together across different
enterprises, industries, and countries. Due in large part to the advances in using the
Internet for various business purposes (ranging from internal reporting to e-commerce),
links in the REA-based AIS can take place event-to-event, agent-to-agent, or enterpriseto-enterprise. Thus, each individual in the supply chain can be directly linked to each
10
other, which makes the supply chain collaboration faster and more effective (Haugen and
McCarthy 2000).
In regards to knowledge-based models, Storey and Goldstein (1993) reviewed 12
knowledge-based computer-aided systems engineering (CASE) tools for database design
and found little evidence of enterprise knowledge use and strong domain independence,
consistent with a traditional architecture. CASE and other knowledge-based tools and
models used in analysis, design, and operation of data intensive AIS have reached an
advanced stage, but very few of these advances rely on the integrated use of either
enterprise models or specific enterprise knowledge (Geerts et al. 1996). An enterprise
model in the REA architecture would integrate different business functions analogous to
Porter’s (1995) concept of a value chain. Specifically, the duality relationships inherent
in a REA architecture would bind an enterprise’s economic events together, while the
stock-flow relationships weave the processes together into an enterprise value chain
(Geerts and McCarthy 1994). However, as Geerts et al. point out, no tools have been
developed yet that fully support this type of model relying on REA domain knowledge.3
Thus, the question remains, “Why not?”
The potential answer to the question lies in two trains of thought – one of
generality and one specific to the conceptual nature of REA systems. The general train of
thought refers to obstacles facing all event-driven systems, not just REA-based systems.
Walker and Denna (1997) document the obstacles as: requirement of new hardware,
software, and people to administer the system; if the system fails, data entry into the
system stops for everyone and data entered incorrectly affect all users of the data;
accountants’ distrust of a non-double-entry system; and the traditionally functional
11
culture of business enterprises. The author is unaware of “guaranteed” tools for nonsystems failure. But, continuous preventative maintenance on an AIS should help
preserve the system, as well as the data integrity within it to some extent.
The other train of thought relates to the conceptual nature of the REA
architecture. The same REA conceptual nature that creates the benefits through high
levels of abstraction discussed earlier also is its major criticism. Physically designing an
AIS using a Full-REA architecture is nearly impossible in a relational database
environment. REA lends itself to use in an object-oriented environment due to its
comprehensive focus on activities/events/objects of an enterprise. Technology is
catching up with this type of environment, but no research has extensively examined the
physical design problems of REA systems (McCarthy 1999).
In summary, conceptually, a REA-based AIS would appear to give enterprises
competitive advantages through integration, reusability, and interoperability. However,
the physical design of these systems has been relatively unexplored and apparently open
for suggestion. REA needs a technological tool in its physical design to help take
advantage of its benefits. That tool is XBRL.
XBRL
Background
XBRL is a freely (i.e., non-proprietary) available electronic language for business
reporting that makes computer systems compatible across a variety of hardware and
software technologies, including the Internet. XBRL is a language created in XML,
which provides users with a standards-based method, in an American Institute of
12
Certified Public Accountants (AICPA)-approved vocabulary, to reliably extract and
exchange important public company information in a variety of formats (Carey 2001).
As opposed to Hypertext Markup Language (HTML), which also uses tags to define data,
XBRL provides structure to the data between the tags allowing for interactive uses. The
data tags are defined by the World Wide Web Consortium (W3C), which is an
international group of companies, accounting firms and groups, and governmental entities
brought together in an attempt to provide universal semantics to accounting data.
The XBRL specification represents a framework for expressing financial facts and
associating those facts with financial concepts (Hoffman and Strand 2001). In order to
preserve industry uniqueness, each industry’s standard tags are commonly referred to as a
taxonomy. In July 2000, the first XBRL taxonomy (for Commercial and Industrial
entities) was released in the United States. Recent research (Bovee et al. 2002) has
indicated that on average, the taxonomy is a good fit with firms preferred reporting
practices, but still needs some revision. In October 2002, a public working draft of the
taxonomy framework was released. It is expected to be finalized in 2003. The W3C is
currently working on taxonomies for other industries as well.
Benefits
XBRL provides adopting enterprises with numerous benefits.4 XBRL represents
one common language for expressing business information. As such, it has been referred
to as the “digital language of business,” (Hoffman and Strand 2001, p. 11). The common
language allows reductions in developmental costs, sharing of the creation of intellectual
property, and agreement at a certain level on the semantics of the business information to
13
make it easier to exchange it across disparate languages, computer systems, applications,
and GAAP.
Besides the interoperability and decreased costs advantages, perhaps the most
significant benefit XBRL offers is that of increased efficiency. Business information
need only be entered once into an enterprise’s AIS (updates are fairly easy using XBRL)
and then disseminated to any number of information stakeholders. For example, without
XBRL, if an enterprise was to apply for a loan at a local bank, its information would need
to be formatted for the loan application, most likely requiring increased data entry within
the enterprise. Once the bank receives the information, it must again be reentered into
the bank’s analysis program in a readable format. With XBRL, the bank would receive
the information into its program (which is XML-enabled) and run its analysis of the loan
request in minutes. Thus, significant reduction in the mechanics of the loan process
reduces the time needed from days (and average loan request takes 1.75 days to process)
to minutes. Similar examples of efficiency benefits due to XBRL adoption could be cited
for SEC filings, IRS reporting, etc.5
In summary, XBRL has significant benefits for enterprises adopting its
technology now, but also will have more global benefits in the next few years. Exactly
how XBRL transfers information between parties is next discussed.
XBRL, Web Services, and Business Reporting
“XML Web services are the fundamental building blocks in the move to
distributed computing on the Internet,” (Wolter 2001, p. 1). Although potentially, there
are many explanations to what Web services potentially consist of, according to Wolter,
there are three dimensions that each of the explanations have in common. First, XML
14
Web services provide useful functionality to Web users through a standard Web protocol,
such as XML, HTTP, and TCP/IP. Typically, SOAP is the communications protocol for
Web services. SOAP is the specification that defines the XML format for a message,
such that it formalizes the XML in a way to pass data from one process to another. An
advantage of SOAP is that it is not transport specific. Thus, SOAP messages could be
sent over HTTP, SMTP, or an instant messaging protocol (Ewald 2002). XML combined
with SOAP, allows information to freely be exchanged from one application to another
over the Internet.
Second, Web services provide a way to describe their interfaces in sufficient
detail to allow a user to build an application for communication purposes. In essence,
Web services act like an email system between the computer systems of use. The
language used, Web Services Description Language (WSDL), specifies what a request
message must contain and look like in unambiguous notation (Wolter 2001). The
notation used is based on the XML Schema standard (XSD), which is standards-based
and language neutral, providing extensibility with a variety of applications. This is the
same schema that can be used in designing XBRL applications.
Finally, Web services are registered with Universal Discovery Description and
Integration (UDDI), allowing potential users to easily find them. UDDI is like the
“yellow pages” of Web services, containing descriptions of companies and services for
users to peruse in choosing the appropriate Web service (Wolter 2001). An entity is not
required to register a Web Service with UDDI, but it would risk insufficient exposure.
Perhaps the most significant benefit XML-based Web services provide is their
simplicity. They are more loosely coupled than the traditional distributed programming
15
models, which make it possible to build systems incrementally (Ewald 2002). Thus,
instead of requiring all pieces of an application to be deployed at once, an entity using
Web services can add clients and servers when needed.
Since XBRL is a subset of XML, it can easily operate in the XML-enabled world
of Web services (Hannon 2001a). Figure 2 graphically depicts how Company R would
be able to use a combination of XBRL and Web Services to meet its various information
stakeholders’ needs. The information is entered into Company R’s database (tagged in
XBRL) only once. Then, given appropriate authorization, the information is extracted by
the information systems of the information stakeholders, via Web services. Although
currently, the information extracted requires human intervention through the use of a
browser, future technology would bypass this requirement and have the system of the
information stakeholder automatically extract the information from Company R through
machine-only communication (Hoffman and Strand 2001).
[Insert Figure 2 about here]
What may not be readily apparent in Figure 2 is the frequency of the information
dissemination. Given an integrated enterprise architecture (discussed further in the next
section), an enterprise may be able to report various pieces of information in near realtime by using XBRL and Web Services. The recent accounting scandals, new
regulations, and demand of corporate information users for more timely business
information (FASB 2000; Hunton et al. 2002a), has shifted the “power” of reporting from
the preparers to the users. Enterprises too recognize this shift as over 80 percent of U.S.
public companies already voluntarily provide some form of financial disclosure on the
Internet (Hunton et al. 2002b). Similar percentages can also be found for European and
16
Australian public companies. Add the significant influx of individual day traders to the
marketplace, and information needs have gone from a relatively finite number (mainly
governmental entities, banks and current stockholders), to a significantly larger number
of users. Thus, another potential use of XBRL is to address this demand and provide a
mechanism for increased reporting frequency.
Recent advances in information technology have made near-continuous delivery
of reports possible through large-scale adoptions of enterprise-wide systems, wide-area
high-bandwidth networks, and XML (Hunton et al 2002b). Additionally, existing
technology has allowed for quick updates of XBRL-based information. Thus, financial
statement preparation need not be performed quarterly, but significantly sooner and more
frequently. At this point, it is not clear if providing real-time financial statements is of a
great benefit to an entity. Whereas, providing more timely financial and nonfinancial
(i.e., business in sum) disclosures than the competition could potentially lower an
enterprise’s cost of capital through perceived transparency, it may also provide an open
source for litigation. Until a reliable form of assurance can be provided on the reported
information, either users will rely on or trust the potentially inaccurate information,
opening the door for lawsuits, or, more likely given the recent scandals, users will not
rely on the information provided at all providing no benefit to the company.
In sum, XBRL and XML Web services are potentially useful technological tools
that could be used to gain efficiencies in a new, more frequent reporting global
environment. However, XML Web services depend on an open architecture for true data
integration and cross-functional analysis (Hannon 2001a). As such, the traditional,
disaggregated AIS architecture may not be efficient. Enter the REA architecture.
17
REA and XBRL: Together At Last
Physical Design Issues
Haugen and McCarthy (2000) examined the “fit” between REA and various other
current technologies. The author interpreted the purpose of the Haugen and McCarthy
paper as finding the best complementary technology that can be used with a REA
architecture in order to be integrated within the supply chain. Among their choices were
Advanced Planning and Scheduling systems (APS), Enterprise Application Integration
Systems (EAI), and XML-based systems. APS systems were deemed to be too singlecompany (i.e., low interoperability and compatibility), proprietary, and dependent on
legacy ERP systems for critical supply chain functions. EAI systems integrate other
applications, but do not do very much themselves and may not understand the
relationships between supply chain objects (i.e., stocks and flows). However, XML has
been widely adopted as a standard language for communication among distributed
software programs (Herring and Milosevic 2001; Sundaram and Shim 2001) due to its
flexibility, interactivity, and Internet-based architecture (Bae et al. 2003). Therefore,
Haugen and McCarthy determined that an XML-EDI model would most easily
accommodate a REA architecture.
The major problem with adopting an EDI system is the cost. Typically, only
some large enterprises can afford to install an EDI system. Although each individual
system is subject to its own costs in terms of implementation and training, it can be
estimated that traditional EDI systems have cost those few enterprises that have adopted
it a total of $3.8 billion. Additionally, some of the adopters may not even be using the
technology internally. For example, Wal-mart and its suppliers are connected via an EDI
18
system. Although an order may come in electronically to a supplier, the supplier will
typically print it out and continue through a series of manual processes, rather than using
the technology correctly. Thus, what may be a better and less costly scenario in the long
run is some sort of object-oriented AIS incorporating a REA-based architecture and an
XML-based computer language (e.g., XBRL). Zona Research forecasts 40% of
companies worldwide will be using XML by the end of 2003 (Editorial Staff 2002a).
At first thought, XBRL and REA appear to be two different concepts altogether.
XBRL is an information communication technology that can be used to represent
hierarchical information without regard to any particular model; whereas, REA can be
thought of as a system design semantic model intended to represent the relationships
between two different objects. Hierarchical data structure like XBRL and XML are very
useful for organizing data, because they have an unambiguous point of view that makes
their context very powerful (Feng et al. 2002). The REA model is a useful semantic
model, because it allows an enterprise to establish and express many different data
structures and relationships explicitly from the same data. In combination, transforming
a REA architecture into a hierarchical structure lets the enterprise create XBRL
documents from a semantic model automatically. Conversely, as Feng et al. point out,
parsers and programs can be written into the XBRL code to transparently move data back
and forth between the REA model and XBRL documents without losing or altering the
semantics associated with the data.
Feng et al.’s (2002) model incorporates a two-level design approach. At one
design level is the generic semantic network consisting of nodes, relationships between
the nodes, etc. The other level is the XML schema (also necessary in XBRL use), which
19
is mainly concerned with element (one piece of tagged datum) and attribute (multiple
tagged data) declarations, as well as simple or complex type definitions. A major
problem with this model is the lack of a consensus on what needs to be modeled. An
accepted and previously applied theoretical design (e.g., REA) should be used in order to
provide consistent modeling approaches either between enterprises or between an
enterprise and its value chain members.
If the REA model is used in the design process, each entity of REA (resource,
event, or agent) could be mapped to either an XBRL element or attribute. Further
definitions of the element or attribute could be dictated according to the appropriate
relationships and constraints between REA entities. Use of the XML schema allows
richer facilities for defining and constraining data when compared to using a prior
standard, document type definition (DTD). The mapping process and data movement
between levels is illustrated in figure 3.
[Insert figure 3 about here]
Synergies Between REA and XBRL
REA and XBRL share three common characteristics, giving the concepts a large
amount of synergy: a non-proprietary nature; compatibility with other systems; and
reusability of data produced. Thus, if REA and XBRL share similar characteristics and
can be used together to model supply chain management, enterprises should use this
synergy for an enterprise-wide AIS capable of all business functions.
When capturing business functions, one can begin with examining the synergy in
terms of external reporting. “REA specifically incorporates the semantics of economic
objects into a firm’s information architecture,” (Geerts and McCarthy 1999). Thus, for
20
this purpose, it would appear that a REA architecture would support a system that
embeds objects tagged in XBRL and communicated via SOAP. As described in the
previous section and displayed in figure 2, XBRL and SOAP appear to be efficient tools
for external exchanges of business information.
The more challenging synergy to describe comes internally. In almost all of the
existing literature, XBRL is described in terms of external financial reporting, with little
attention given to increasing the efficiencies from within the enterprise. According to
Geerts and McCarthy (1999), opportunities for complementary technological advances
with REA appear to be at the “task” level. This level is where most reengineering efforts
take place and provides for elements such as the data communication between
departments and the ordering of computer processes. What is important at this level is
that the information (financial or nonfinancial) disseminated between departments is
readable, even if the departments are using different hardware or software, in different
countries, and in different languages. Both traditional accounting information systems
and data written in an unstructured language like HTML have had troubles performing
this duty.
Thus, an opportunity exits for an XML-based tool to be used to integrate the
necessary internally communicated information for readability. One such tool is called
XBRL General Ledger (GL). “XBRL GL is an agreement on how to represent
accounting and after-the-fact operation information – anything that is found in a chart of
accounts, journal entries or historical transactions, financial and nonfinancial – and
transfer it to and from a data hub or communicate it in a data stream,” (www.XBRL.org).
21
The purpose is to bridge the gap between either off-site or outsourced systems and their
back office accounting and reporting systems.
XBRL GL is chart of accounts independent (i.e., it does not require a standardized
chart), reporting independent (i.e., it collects both general ledger and nonfinancial facts),
and system independent (i.e., any system can convert its information to XBRL GL
format). Additionally, XBRL GL’s extensibility would allow a universal audit trail
capable of sustaining continuous assurances and fits nicely with XBRL for tax purposes.
Several business disciplines are currently working on their own XML-based
systems to make the exchange of information between their systems and AIS using
XBRL GL even more efficient. HRXML is the XML-based system currently being
developed in human resources. If an entity has a REA-based architecture with HRXML,
XBRL GL, and Web services, information exchange, especially nonfinancial data usually
neglected in traditional accounting information systems, could occur almost simultaneous
from anywhere in the world. Take the example of a business event whereby an
enterprise’s human resources department in Hong Kong wants to extract accounting
performance information from a branch in France in order to make a potential pay
increase decision. The combination of XML technology and REA architecture would
make this process routine. Without XML, the process would take significantly longer
and be more costly, even with email or a form of extranet technology. This is an example
of a nonfinancial business process that traditional accounting information systems have
typically had difficulty in efficiently producing and communicating the requested
information. The accounting department would have to retype the information to make it
22
readable by human resources. Then, human resources, if it uses a separate application,
would have to again retype the information so it may be readable by its application.
The example above could involve any two or more departments. The concepts
are synonymous. Figure 4 displays the internal business processes of an entity given a
purchase of raw materials, whereby the accounting functions are located in the United
States, but the receiving department and manufacturing plant is in China. Notice that by
using a REA architecture, the Internet and XML technology, the transaction information
is captured and processed only once, even though the same information is being
transmitted multiple times across the entity.
[Insert Figure 4 about here]
The current paper has incorporated nonfinancial information, because it has
become increasingly important in both performance measurement and investor strategies.
Various groups have called for greater disclosure of nonfinancial information by
corporations (AICPA 1994; Lev 2001). These groups argue that “traditional financial
measures have diminished relevance due to changes in business models said to reflect the
‘new economy’” (Maines et al. 2002, p. 353). The demand for external reporting of
nonfinancial performance measures has also been driven by companies’ adoption of
internal performance evaluations, such as the Balanced Scorecard (Kaplan and Norton
1996). In turn, investors have requested enterprises to include performance evaluation
metrics used internally in their external reporting.
Researchers investigating potential market effects of nonfinancial information
argue that these measures create a view of the future of an enterprise, as opposed to the
historical focus of financial measures (Amir and Lev 1996; Hughes 2000; Ittner and
23
Larcker 1998). In sum, research suggests that investors’ ability to use nonfinancial and
financial information consistently across enterprises and time is impaired by
noncomparability in measures or formats (Maines et al. 2002). Such noncomparability
likely reduces the value of the nonfinancial performance measures sought out by
investors. As previously stated, traditional accounting systems have had trouble
integrating and reporting many types of nonfinancial information in an efficient manner.
This problem is exacerbated when disparate systems are used. Thus, it would appear that
a combined REA-XBRL AIS would be of great benefit in this area.
Software Support for a REA-XBRL Marriage
Examples of current and future REA-based software packages were indicated in
the previous REA section. As Hannon (2001b) points out, there are also significant
XBRL software packages available to enterprises. The following examples are but a
sample of what is currently available. The ACCPAC Advantage Series is available for
mid-market enterprises that desire comprehensive, integrated business solutions. It is
highly adaptable to XML technology and does include a feature for exporting XBRLproduced financials. The Case Ware Working Papers imports necessary data, maps it to
XBRL tags and generates XBRL documents and reports. In 2000, Navision Software
released its product, called “XBRL Solution”, in which an enterprise will have an XMLbased financial reporting language that allows an open exchange of reporting data across
all software and technologies. Finally, Microsoft is releasing an XBRL add-in in
conjunction with its Office 11 software package expected to release in the summer of
24
2003. This may be the most significant XBRL software support, given the widespread
use of Microsoft Office products.
Although all of the “Big 4” CPA firms are involved in the W3C, KPMG and
PriceWaterhouseCoopers (PWC) have been leaders in producing usable XBRL software.
For reporting purposes, KPMG has produced the “Columbus”, which is an ASP used for
delivering interactive Internet applications to support continuous business performance
improvement (Hannon 2001b). Columbus was scheduled to be XBRL-enabled by
October 2001. At a recent symposium6, KPMG stated it has realized there is an ongoing
change in business reporting methodology from transaction-based to events based. The
universal adoptions of REA-based architectures, in combination with their Columbus
product, would help support this change.
PWC has combined their efforts with Microsoft and the NASDAQ Stock
Exchange to produce a working demo of 21 public companies (traded on the NASDAQ)
whose partial annual report data is coded in XBRL and loaded in an Excel Analyzer
program. The purpose of this pilot is to demonstrate the speed and efficiency of
gathering financial statement, key ratio, and even footnote information written in XBRL
via the Internet. The New York Stock Exchange is considering a similar pilot.
In summary, software currently exists that will create a REA architecture for
capturing business information and create an object-oriented AIS with some code written
in XBRL. The problem is, these two features are currently used in isolation, not taking
advantage of the synergies between them. At the symposium, major software providers,
some of whom already produce some REA-based software, indicated their willingness to
provide packages that are XML-enabled (in addition to the examples listed previously).
25
It is up to enterprises across the world to take advantage of the opportunities a REAXBRL marriage would provide.
Conclusions
This paper has attempted to build on Feng et al.’s (2002) model by presenting
both a review of REA and XBRL, discussing the importance of having an AIS capable of
efficiently capturing and communicating key nonfinancial performance measures, and
indicating an initial list of benefits provided by combining the two concepts in an
enterprise-wide AIS. “Once a firm fully implements an integrated enterprise-wide
information system, it is already capable of capturing and processing financial and
nonfinancial in ‘near’ real-time; therefore, such firms need only to develop a method of
rapid reporting to the public” (Hunton et al. 2003, p. 8). However, if an enterprise
operates a group of disparate application that do not easily communicate with each other
(often referred to as legacy systems), considerable time lags between the capturing,
processing, and reporting of information could occur. An enterprise-wide REA AIS
operating on the Internet incorporating XBRL, Web services, and SOAP, could
potentially provide semantic, efficiency, and interoperability gains that would provide
early adopters a competitive advantage in their industry, more frequent disclosures of
business information, which could then reduce their cost of capital.
All is not bliss by adopting such a system. For an alternative (i.e., not traditional
debit/credit system) AIS to be adopted, the incremental benefits must exceed incremental
costs (Hunton et al. 2003). Exact estimates could vary greatly, but besides the cost of the
technology and its implementation, adopting enterprises would have to bear costs
26
involved with training their employees how to use the system and continued technology
support from the vendor, in addition to several other incremental costs. This paper does
not wish to ignore the potentially large costs involved with the adoption of the new
technology. They can be substantial, especially if you consider other technology
adoptions like ERP and EDI. Rather, recognition of their existence and estimates of their
amounts would allow enterprise executives to perform cost/benefit analyses and
comparisons to traditional ERP and EDI systems.
More research is needed examining such a cost/benefit scenario. Although
difficult to quantify business process efficiencies and interoperability possibilities, those
cost savings combined with lower data entry costs (those due to human error and
otherwise) and a lower cost of capital, could provide for positive future cash flows after
proper consideration of the necessary costs. Thus, at least conceptually, an enterprise
adopting a REA-architecture and an object-oriented AIS incorporating XBRL and XML
Web services, would appear to be fiscally rewarded in the long term.
27
Appendix A
Examples of Specific XBRL Usage







Morgan Stanley Dean Witter has filed its 2001 and 2002 SEC filings in XBRL.
Besides Morgan Stanley, two other U.S. companies (most notably Microsoft)
have externally reported financial information in XBRL.
General Electric has announced it will use XBRL to simplify and speed its tax
reporting processes (Editorial Staff 2002b).
EDGAR Online has converted the whole SEC database (approximately 20,000
companies) into XBRL based on the recent draft release of the U.S. GAAP
taxonomy (Accounting Education Using Computers and Multimedia Listserve
2002).
The IRS is currently involved in a XML-related tax filing initiative (similar to
XBRL). A similar U.K. pilot will be conducted later in 2003.
The Core Financial System Requirements report filed in November 2001 by the
Joint Financial Improvement Program recommends that U.S. governmental
agencies use XBRL (Hannon 2002).
As of January 1, 2003, all public companies in Australia were required to
participate in the Direct to APRA (Australian Prudential Regulatory Authority)
program in which material information is continuously on the Web (although
XBRL was not specifically required to be used, its use was encouraged).
28
References
Accounting Education Using Computers and Multimedia Listserve. 2002.
American Institute of Certified Public Accountants (AICPA). Improving business
reporting – a customer focus. New York, NY: AICPA, 1994.
Amir E., Lev B. Value relevance of nonfinancial information: The wireless
communication industry. Journal of Accounting and Economics 1996; 22: 3-30.
Bae K., Kim J., Huh S. Federated process framework in a virtual enterprise using an
object-oriented database and extensible markup language. Journal of Database
Management 2003; 14 (1): 27-48.
Bovee M., Ettredge M.L., Srivastava R.P., Vasarhelyi M.A. Does the year 2000 XBRL
taxonomy accommodate current business financial-reporting practice? Journal of
Information Systems 2002; 16 (2): 165-82.
Carey A. Networking; Insight; XBRL; XBRL Rated. Accountancy Age 2001: 26.
Chen N., O’Leary D., McLeod D. Schema evolution for object-based accounting
database systems. Expert Systems with Applications 1995; 9 (4): 491-502.
Chen P.P. The entity-relationship model – toward a unified view of data. ACM
Transactions on Database Systems 1976: 9-36.
Codd E.F. A relational model of data for large shared data banks. Communications of
the ACM 1970: 377-87.
Denna E.L., Perry L.T., Jasperson J. Reengineering and REAL business
process modeling. In M. Khosrowpour and J. Travers, eds. Business Process
Change: Reengineering Concepts, Methods and Technologies. Hershey, PA: Idea
Group Publishing, 1998: 350-375.
Editorial Staff. How XBRL GL will help you manage your general ledger. Managing
the General Ledger 2002a: 1-2.
-----------------. The CPA Letter. 2002b; 82 (4): 1.
Ewald T. Understanding XML web services the web services idea.
MSDN.Microsoft.com 2002: 4 pages.
Feng L., Chang E., Dillon T. A semantic network-based design methodology for XML
documents. ACM Transactions on Information Systems 2002; 20 (4): 390-421.
29
Financial Accounting Standards Board (FASB). Electronic distribution of business
reporting information. Steering Committee Report Series. Business Reporting
Research Project 2000.
Geerts G.L., W.E. McCarthy. 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, 2002: 321-332.
---------------------------------------. The economic and strategic structure of REA
accounting systems. Working paper presented to the 300th anniversary program,
Martin Luther University, Halle-Wittenberg, Germany 1994.
---------------------------------------. Modeling business enterprises as value-added
process hierarchies with resource-event-agent object templates. In: J. Sutherland
and D. Patel, eds. Business Object Design and Implementation. Springer Verlag,
1997: 94-113.
---------------------------------------. An accounting object infrastructure for
knowledge-based enterprise models. IEEE Intelligent Systems and their
Applications 1999; 14 (4): 89-94.
Geerts G.L., McCarthy W.E., Rockwell S.R. Automated integration of enterprise
accounting models throughout the systems development life cycle.
Intelligent Systems in Accounting, Finance, and Management 1996; 5: 113-128.
Hannon N. Web services and XBRL. Strategic Finance 2001a; 83 (6): 59-60.
-------------. XBRL vendor list. Strategic Finance 2001b; 82 (12): 70.
-------------. XBRL enters a new phase. Strategic Finance 2002; 83 (10): 61-2.
Haugen R., McCarthy W.E. REA: A semantic model for Internet supply chain
collaboration. Working paper presented at OOPSLA, Minneapolis, MN 2000.
Herring C., Milosevic Z. Implementing B2B contracts using BizTalk. In proceedings of
the 34th Hawaii International Conference on System Sciences, Hawaii, USA 2001:
4078-4087.
Hoffman C., Strand C. XBRL Essentials. New York: AICPA, 2001.
Hollander A.S., Denna E.L., Cherrington J.O. Accounting, Information
Technology and Business Solutions. Burr Ridge, IL: Irwin/McGraw Hill, 1995.
Hughes K.E. The value relevance of nonfinancial measures of air pollution in the electric
utility industry. The Accounting Review 2000; 75: 209-228.
30
Hunton J.E., Wright A., Wright S. Assessing the impact of more frequent external
financial statement reporting and independent auditor assurance on quality of
earnings and stock market effects. Working paper presented at the 5th Annual
Continuous Audit Conference, Newark, New Jersey 2002a: 1-37.
----------------, Reck J.L., Pinsker R.E. Investigating the reaction of relatively
unsophisticated investors to audit assurance on firm-released news
announcements. Working paper presented at the 5th Annual Continuous Audit
Conference, Newark, New Jersey 2002b: 1-42.
----------------, Wright A., Wright S. The supply and demand for continuous reporting.
In: S. J. Roohani ed. Trust and data assurances in capital markets: The role of
technology solutions. Smithfield (RI): research monograph funded by
PricewaterhouseCoopers LLP, 2003: 7-16.
Ijiri Y. Theory of Accounting Management. American Accounting Association, 1975.
Ittner C.D., Larcker D.F. Are non-financial measures leading indicators of financial
performance? An analysis of customer satisfaction. Journal of Accounting
Research 1998; 36 (Supplement): 1-36.
Kaplan R., Norton D. The balanced scorecard. Boston: Harvard Business Press, 1996.
Lev B. Intangibles – management, measurement, and reporting. Washington D.C.:
Brookings Institution Press, 2001.
Maines L.A., Bartov E., Fairfield P.M., Hirst D.E., Iannaconi T.E., Mallett R., Schrand
C.M., Skinner D.J., Vincent L. Recommendations on disclosure of nonfinancial
performance measures. Accounting Horizons 2002; 16 (4): 353-362.
McCarthy W.E. An entity-relationship view of accounting models. The
Accounting Review 1979; 54 (4): 667-86.
--------------------. The REA accounting model: A generalized framework for accounting
systems in a shared data environment. The Accounting Review 1982; 57 (3): 55478.
--------------------. Semantic modeling in accounting education, practice, and research:
Some progress and impediments. In: P.P. Chen, J. Akoka, H. Kangassalo, B.
Thalheim, eds. Conceptual Modeling: Current Issues and Future Directions.
Springer Verlag, Berlin and Heidelberg, 1999: 144-53.
-----------------------, David J.S., Sommer B.S. The evolution of enterprise information
systems – from sticks and jars past journals and ledgers toward
interorganizational webs of business objects and beyond. Working paper
presented at OOPSLA, San Jose, CA 1996.
31
O’ Leary D.E. REAL-D: A schema for data warehouses. Journal of Information Systems
1999; 13 (1): 49-62.
Porter M.E. Competitive advantage. New York: The Free Press, 1995.
Rockwell S.R. The conceptual modeling and automated use of reconstructive accounting
domain knowledge. Unpublished dissertation, Michigan State University 1992.
Storey V.C., Goldstein R.C. Knowledge-based approaches to database design. MIS
Quarterly 1993: 25-46.
Sundaram M., Shim S.S.Y. Infrastructure for B2B exchanges with RosettaNet. In
proceedings of the International Workshop on Advance Issues of E-Commerce
and Web-Based Information Systems (WECWIS), California, USA 2001: 110119.
Walker K.B., Denna E. Arrivederci, Pacioli? A new accounting system is emerging.
Management Accountant 1997: 22-30.
Wolter R. XML web services basics. MSDN.Microsoft.com 2001: 5 pages.
WWW.XBRL.org.
32
Figure 1
Generic REA Template
Inside
Agent
Stock Flow
Control
Resource
Event (-)
Outside
Agent
Duality
Inside
Agent
Stock Flow
Resource
Event (+)
Control
Outside
Agent
Adapted from McCarthy 1982
33
Figure 2
Example of XBRL and External Reporting
Business information/data
collected by Company R
Governmental
Entity (i.e., IRS,
SEC, etc.)
Company R
enters and tags
the information
in XBRL once
(with updates as
necessary)
SOAP
Internet
SOAP
Web
services
Digital
controls are
set specifying
external
access
Web services
Investors
Web
services
SOAP
SOAP
Banks
Through the Internet, Web services, and SOAP, information
stakeholders receive reported information from Company R.
The stakeholders can immediately use the tagged information
for analysis with no re-entering of data.
34
Figure 3
The Mapping of Data and Flow Between the REA Model and XML Schema
This figure simplistically displays how a general example of a REA-based system of
capturing raw data with sample constraints (left side of figure) would map the data
captured to various XML elements and attributes contained in the XML Schema (right
side of figure). Conversely, the figure also displays the reverse data flow. Specifically,
with programs and parsers written in to the XBRL code, the new, parsed data could then
be sent back to each REA entity for analysis or reporting purposes.
Resource
(0,1)
Raw Data
Parsed
Data
XML
Schema
(1,1)
Raw Data
Raw Data
Mapping
Process
Event
(1,1)
Parsed
Data
Parsed
Data
Elements,
Attributes
Programs,
Parsers
Raw Data
(0,1)
Agent
Parsed
Data
Adapted from Feng et al. (2002)
35
Figure 4
Example of XBRL and REA Internal Processing - Company R Purchasing Raw
Materials in China
R’s
Buyer
Cash
Raw
materials
Seller’s
shipping
departmt.
Receive
raw
materials
R’s
receiving
departmt.
(China)
Duality
External
salesperson
Purchase
Notifies
Accesses record
R’s
mfg.
dept.
(China)
Records event data
using XBRL GL
Uses data for
decisions and
reporting
R’s
acctg.
dept.
(U.S.)
Accesses record
All departments
can access & read the data
R’s
hr
dept.
R’s
mktg.
dept.
R’s
finance
dept.
36
It does not matter where in the
world, which language, or
which department needs the
information with XBRL GL.
Footnotes
For a more thorough discussion of REA basics, see McCarthy (1979, 1982) and Geerts and
McCarthy (1997).
2
For a more thorough discussion of GENEVA, see Walker and Denna (1997).
3
Geerts et al. (1996) list 3 CASE tools that have the REA model embedded: REAVIEWS
(Rockwell 1992), CREASY (Geerts and McCarthy 1992), and REAtool (Chen et al.
1995).
Due to XBRL’s evolving nature, the discussion in this paper is not intended on
representing an exhaustive description of current and future benefits.
4
5
Please see Appendix A for examples of specific XBRL usages.
6
The 5th Annual Continuous Audit Symposium held at Rutgers University.
37