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