Finally, Business Talks the Same Language… XBRL

Just as English is the universal language of commercial pilots, so XBRL soon will be the lingua franca for all business reporting—from issuing financial statements to banks and shareholders to uploading business information onto a Web site. The development surely will revolutionize how business data are reported, used and calculated.

The good news is that, in most cases, you won’t have to learn anything to be able to “read” or “write” XBRL—which stands for extensible business reporting language—because it will be built into most, if not all, accounting and financial reporting software. Once added to the software, it will automatically and transparently translate all the business information you choose—numbers and words—so each segment of data is identified when viewed by a Web browser or sent to a spreadsheet application for calculation or examination. Even better news is XBRL won’t require extra attention from CPAs and other financial managers and will make their work easier to perform and more effective: improving access to and the usability of financial data no matter whether the information is from a business or an association or whether the entity is large or small, public, private or nonprofit. Additionally, XBRL will reduce the cost of processing, calculating and formatting financial information because, once the data are created and formatted the first time, they never have to be keyed in a second time or reformatted for any special presentations.

The bottom line is that XBRL will expand professional opportunities for CPAs and other financial executives and add value to financial information for all users: auditors, preparers, bankers, shareholders—in short, anyone who creates, uses or accesses an organization’s business data.

AND IT’S FREE

If all this sounds like incredible hype—and even a modern-day challenge to the biblical story of the Tower of Babel (see “XBRL: Rebuilding a Tower of Babel”)—consider this: Soon after the idea for the concept was floated in 1999, software giants such as Microsoft and IBM immediately grasped its potential and recognized that the only way a common standard could be developed was if the software and financial communities agreed to cooperate in establishing a standard rather than seeking to compete with their proprietary versions of the program. And agree they did—and quickly.

The best news is that XBRL is free. And that’s despite the fact that many organizations are investing a great deal of money and time on the work. As a result, software companies will not have to pay to include the XBRL code in their software, and each new edition—and there will be many because the program is sure to be continually updated—and extension developed for specific industries will be available free for downloading off the Internet.

Why would these organizations invest in the development of XBRL, and why would they not expect to be reimbursed for their investments by charging for the product?

XBRL: Rebuilding a Tower of Babel In many ways, XML is a modern-day challenge to the biblical story of the Tower of Babel. According to Genesis 11:1-9, the descendants of Noah “had one language and the same words.” In an effort to strengthen their unity, they took advantage of their common language and together began to build a mighty city, called Babel, which contained a tower. This work, according to the Hebrew Testament, did not please the Lord, who exclaimed: “Look…they have all one language; and this is only the beginning of what they will do; nothing that they propose to do will now be impossible for them. Come, let us go down and confuse their language there, so that they will not understand one another’s speech.” Which, according to Genesis, is what happened.

REAPING BENEFITS

The fact is the developers will be repaid many times over, but not by charging a fee for the program; instead, they will be reimbursed by reaping its many benefits when everyone uses the same business reporting language. The most immediate benefit: Distributing financial information will be fast and easy. Further, XBRL will eliminate the need for rewrites of financial reports to accommodate incompatible accounting systems.

(For more on the technical aspects of XBRL, go to www.xbrl.org, where visitors can test sample data and offer comments and suggestions for improving the program.)

Additional advantages of XBRL include the following:

• Fast, accurate searches. Because all the data in an XBRL-formatted file are tagged and related information is linked—say, fixed assets to balance sheet and depreciation—more than half the job of conducting a search for specific information is already done. For example, if you search the Internet for information about General Motors’ fixed assets, you likely will end up with thousands of sites to explore, and that’s even with the best search tools. But with XBRL-tagged data, the search is immediately narrowed to your specific target data—fixed assets as they relate specifically to balance sheets and depreciation.

  In fact, if you’re collecting fixed-asset data to compare one company’s operation with others’, you can tailor the search for multiple companies’ data and export the collected information easily into a spreadsheet for further analysis; since each piece of information is identified with a tag, comparisons and calculations can be automated.

• Drill-down feature. If you prepare a search query properly, you can drill down to the data source and even to the related authoritative literature that supports the data, such as Accounting Trends and Techniques. This feature also will be available in XBRL-tagged financial statements.
• Less need to reenter data. In most cases, financial information will need to be keyed in only once, reducing the risk of data-entry error. Also, because the information already is XBRL-formatted, users won’t need to reformat it when preparing it for any number of presentations—such as to print a financial statement, to create an HTML document for a company’s Web site, to ready an EDGAR document for filing with the SEC or other specialized reporting formats such as credit reports and loan documents. Such a benefit not only reduces preparation costs and reduces rekeying errors but it also improves investor or analyst access to information.
• Users’ choice for disclosures. An organization using XBRL will not be required to report more information than it wishes. Users will still control what they report. Nor must they make a change to existing accounting standards. And because the templates are scripted to follow U.S. GAAP, users will find the XBRL templates helpful in complying with existing standards.

HOW IT WORKS

XBRL is a computer programming add-on that tags each segment of computerized business information with an identification code or marker. In most cases, accounting software will insert the tags automatically. If your accounting system lacks the XBRL feature, you can still add the tags using a free add-on program or customized software tagging tools. For more details on this, see “Run XBRL Right Now” below.

The ID markers remain with the data when they are moved or changed. Thus, no matter how you (or, more precisely, your browser or your application software, such as a spreadsheet or a word processor) format or rearrange the information, the markers stay glued to it. Thus a number identified as representing, say, profit in U.S. dollars always will be recognized that way. Typical labels include financial IDs such as assets, current assets and receivables. If the XBRL program doesn’t contain ID markers that meet the needs of your business, you can easily create your own markers and add them because the program is fully customizable—or extensible (with ex as the X in XBRL).

Users will not see these markers when the business data are called to the screen or printed, because they are embedded inside the information along with other invisible formatting tags that typically define what any computer character looks like—its shape, size and color. Exhibit 1 is a screen shot representing a typical XBRL structure, which is called a schema—the template that defines the tags and describes how data are interrelated. This particular schema is AICPA US GAAP C&I Taxonomy 1.0; translation—it includes U.S. GAAP for commercial and industrial companies and its template design edition (or taxonomy) is 1.0.

The XBRL working group, made up of industry and professional representatives, just finished the schema that will be available for commercial and industrial organizations. If an enterprise has special needs, the schema can be adjusted—by adding new elements, eliminating some or editing existing ones. For example, part of the C&I schema includes the elements shown in exhibit 2.

IN THE BEGINNING…

Work on the basic idea of a common business language for computers started in the 1990s, when a relatively unknown software engineer recognized that HTML (hypertext markup language), the standard programming script that defines what Web content looks like, did not go far enough. Although HTML is effective for describing Web content’s appearance—size, shape and color—it can’t describe the content itself. For example, HTML defines the font style of text transmitted over the Internet, but it can’t tell what a character represents—a price, a profit, the age of an asset, an ingredient for an apple pie recipe or a baseball player’s batting average.

The engineer, Jon Bosak, envisioned a language that could turn the Internet into an “industrial-strength infrastructure.” He pestered the World Wide Web Consortium (more commonly known as the W3C, the organization that oversees Web technology standards) to support its development, and the body eventually sanctioned the work. In just a few months, Bosak and two other software engineers who had joined him on the project unveiled a programming language they called XML—extensible markup language—a generalized script for tagging any Internet data with ID markers. Exhibit 3 is a representation of a typical XML format.

Shortly thereafter, in 1998, Charles Hoffman, a CPA with the CPA firm Knight Vale & Gregory in Tacoma, Washington, recognized that XML, as good as it was, didn’t quite address the specific needs of the business reporting community. (See Hoffman’s sub-article “Run XBRL Now.” at the bottom) He recognized that XML’s repertoire had to be expanded to include a more definitive business reporting script that not only identified each piece of data but also told the computer how each should be handled, how each related to other tagged information, where each should be linked and what elements each comprised as it related to business information.

He set to work on XML-formatted financial statements and audit schedules. Although the work was promising, it clearly needed more effort. Hoffman sought help from Wayne Harding, chairman of the AICPA high tech task force and one of the authors of this article; in short order the Institute, along with Hoffman’s firm, agreed to fund the creation of a prototype set of financial statements in XML. When other organizations heard of their work, recognizing its universal value, they, too, contributed to the joint venture.

NEXT STEPS

While work on XBRL never really will be finished because many users will want to customize templates to suit their own needs, the XBRL working group soon will start on other business reporting industries (such as software, media and entertainment and financial services organizations). The group next will focus on other aspects of business reporting—regulatory filings, tags for audit schedules and processes and tax filings. At some point, the working group envisions using XBRL in balanced scorecards—a business technique in which the metrics of a company are assembled and compared in various ways to measure how well or poorly it is performing.

Meanwhile, parallel efforts are under way with the AICPA’s counterparts in other countries. Australia, Canada, England, Germany, Taiwan and Wales, along with the International Accounting Standards Committee, are involved in the XBRL working group. Other countries also are showing shown strong interest.

XBRL is being embraced worldwide by the business community, which sees the development changing the way it communicates and conducts business.

Run XBRL Right Now BY CHARLES HOFFMAN If your accounting software doesn’t include XBRL—and few, if any, products have it now—it doesn’t mean you can’t start applying the feature immediately. I’ve created a method that gives you the opportunity to try XBRL now. Once you understand the process, you can use it with your own accounting software until XBRL is added eventually to your system. Many software vendors are working to incorporate XBRL. For example, SAP will include ready-to-use XBRL templates for reporting, financial consolidation, modeling, simulation and planning and budgeting. FRx Software, financial accounting/reporting software that works with some 50 accounting packages, will incorporate the function later this year. And 11 major accounting software vendors are members of the XBRL working group—a further indication of the industry’s interest in XBRL. DO IT NOW To see how XBRL works, go to http://www.xbrl.org/demos/demos.htm. You can download the demo or run it off the Web site. You will need Microsoft Access 2000. The demo shows you how to publish your general ledger trial balance in XBRL. Here’s a summary of the steps: Step 1. Get a copy of your chart of accounts. Note that although this demo (see exhibit 1) was prepared at the account level, you can present information in more detail, such as the type of transaction (invoice, payment, credit, debit entries to accounts receivable), or at a more summarized level, such as a financial statement line item. Step 2. Get a copy of the appropriate XBRL taxonomy (template), which in this case is on the XBRL Web site. Note that this demo already includes the commercial and industrial taxonomy within the Access database table. Step 3. Create a database table and map (assign or cross-reference) each general ledger account to the appropriate XBRL taxonomy element. If no available XBRL tag (technically called an element) meets your need, simply type in your own. It’s the ability to customize that makes the program extensible—capable of being extended to your individual needs. Again, the demo Access application provides this functionality, as you can see in exhibit 2, and exhibit 3. Step 4. Summarize your trial balance by the general ledger account for the period you wish. This provides you with an account number and a total by account for a given period, as shown in exhibit 4. Step 5. Apply the map to the trial balance. What the map says, in effect, is: “When I use this GL account, replace it with this XBRL element.” Note exhibit 2, which shows the map, and exhibit 5, which shows the result of the mapping. Also note that the general ledger account is assigned to the “id” attribute (as shown in exhibit 2). This is done only in the demo to help you see what is going on; it isn’t required. Exhibit 6 shows the XML file called an XBRL instance document. That’s all there is to it. Once the XBRL function is added to your software, these steps will occur automatically. But the fact that your accounting software isn’t XBRL-complaint yet should not dissuade you from manually doing the job in the interim. It’s going to take a little knowledge about databases or, if you’re more comfortable in Excel, it can be done with that application, too. Although this demonstration shows how to transform general ledger trial balance information into XBRL, the concept applies to literally any data—trial balance, other accounting system data and even nonaccounting system data. Some things to note: If the available taxonomies don’t work for you, you can easily modify a taxonomy or create your own. The data in the XBRL document you created are accessible from any of the most popular office productivity tools: Excel, Access, Word, PowerPoint. XBRL still will work accurately if someone adds additional information to the document without your knowledge. It’s as if someone added a row of data to an Excel spreadsheet: It does not affect your spreadsheet.

STANLEY ZAROWIN is a senior editor on AICPA's Journal of Accountancy. WAYNE E. HARDING, CPA, is a vice-president of Great Plains Software, Fargo, North Dakota. He is a member of the IT executive committee and XBRL working group. His e-mail address is wharding@GreatPlains.com.

Mr. Zarowin is an employee of the AICPA and his views, as expressed in this article, do not necessarily reflect the views of the AICPA. Official positions are determined through certain specific committee procedures, due process and deliberation.