Is XBRL Useful?

So what do I think.

Is XBRL useful? I would say it depends on the stakeholder. For agencies who receive reports, XBRL is certainly useful. Document receiving agencies like the SEC and the FDIC have a lot to gain by making all their constituents supply them with documents in a standardized form. It is no wonder such government regulators were among the first to support and talk-up XBRL.

For corporations and organizations who must submit reports, I would say XBRL can be useful if technology and resources are in place to create documents in XBRL. As long as reporting in XBRL does not become a burden, which it hopefully shouldn't for large corporations with large IT departments, XBRL could streamline the process of business reporting required by the big regulators like the SEC. For example, much of the data that is required for particular reports may be spread out in various documents in different formats throughout an organization. Implementing XBRL organization-wide would allow a corporation to pull out those items necessary for a particular reporting document and repackage them in the appropriate format for the SEC, FDIC, etc., hence saving time. Of course, XBRL would also be helpful in organizing, extracting and analyzing a company's internal data and information for business intelligence purposes. This is the ideal.

What about the public, or the shareholders of the corporations doing the reporting? In an ideal world XBRL will help them extract relevant data and information from reporting documents. XBRL is supposed to help with information overload; rather than wading through pages and pages of a company's 10-K, shareholders with appropriate XBRL parsing software could pull out exactly what they need. But, many SEC filing products currently on the market such as 10K Wizard do this already. Perhaps in the area of SEC filings XBRL does not offer any new service to the public.

As we discussed in the last class, like it or not, metadata is the wave of the future. Like METS, XBRL is a specialized, elaborate, technical and complex metadata framework. XBRL is meant to improve business reporting and the business process in general. But XBRL has not reached critical mass yet. Time will tell if more widespread adoption of XBRL will reveal new uses and show us the true power of using metadata to describe financial information.

For more information...

The following list provides a introductory set of articles, websites and other resources that significantly discuss XBRL:

Articles
Starr, J. (2003). Metadata use in the commercial banking industry. Bulletin of the American Society for Information Science and Technology, August/September, 13-16.

Williams, S. P., Scifleet, P. A., & Hardy, C. A. (2006). Online business reporting: An information management perspective. International Journal of Information Management, 26(2), 91-101.

KPMG. (2003). Understanding XBRL: The use of Xlink. Retrieved November 17, from http://www.kpmg.com/xbrl/XBRL_WP_020204_A_10_22.pdf

Stuart, A. N. (2006). XBR-What? CFO, August, 60-64.

Perera, D. (2006). Meta-Mania. Government Executive, 38(3), 69-70.

Websites
Official XBRL International Website
http://www.xbrl.org/Home/

Information about the 14th International XBRL Conference
http://conference.xbrl.org/about

KPMG's XBRL Information on XBRL
http://www.kpmg.com/xbrl/XBRL_Home.asp

Cover Pages entry on XBRL (see the list of articles near the bottom of the page)
http://xml.coverpages.org/xbrl.html

Wikipedia Entry
http://en.wikipedia.org/wiki/XBRL

Books
A perhaps not so surprising abundance of books have been published on the subject of XBRL. The two books listed below are the most recent and best texts on the subject. And what do you know, LC has a subject heading for it too: XBRL (Document markup language).

Essentials of XBRL: Financial Reporting in the 21st Century
Bryan P. Bergeron
Hoboken, NJ: Wiley, 2003. 220 pages.

XBRL Essentials: A Nontechnical Introduction to eXtensible Business Reporting Language (XBRL), the digital language of Business Reporting
Charles Hoffman and Carolyn Strand
New York: American Institute of Certified Public Accountants, 2001

Discussions, Listservs and Blogs
Interestingly enough, my blog is the first one that pops up on a Google Blog Search. Unfortunately, the key listservs and discussion groups are for "members only" via the XBRL website. I did find a XBRL Yahoo Group that was supposed to be available to all, but the link was broken. Alas.

XBRL Projects

There are a number of XBRL projects underway all over the world. Both the XBRL website and the Wikipedia entry on XBRL list a number of such projects.

However, here in the United States, the most prominent XBRL project has been undertaken by the SEC. Currently, the SEC has set up a program where corporations can voluntarily submit required reports in XBRL. For a list of XBRL marked-up SEC documents, visit the SEC's website. The SEC has also set up an RSS feed to notify those interested when new XBRL SEC documents become available.

The FDIC (Federal Deposit Insurance Corporation), another United States government finance organization, now requires banks to submit required documentation such as balance sheets and call reports in XBRL.

XBRL elements

What elements are included in XBRL?

One of the best ways to get to know a new metadata scheme is to dive in and look at the specific elements. XBRL is simply not that simple. XBRL is more than just a metadata scheme. It is a framework for developing standardized taxonomies that can be used to create metadata for specific business reporting needs. So before we look at elements, we have to understand the basic structure of XBRL.

XBRL consists of the following:
-Instance document. This is the actual XBRL marked-up document.
-Taxonomies. Basically, a document of concept definitions, or a dictionary. In terms of metadata terminology we used in class, the taxonomy document provides the semantics for a particular XBRL instance document. The taxonomies also define hierarchies of concepts. If necessary, a taxonomy could describe one item in more than one language. The taxonomy itself is extensible, that is, a user can split one item into two different items (i.e., instead of just "sales," “equipment sales” and “consumables sales” could be used).
-Linkbases. Unlike the taxonomies which define the elements (called "items" in XBRL), linkbases are documents that define various relationship between items. The five types of linkbases are reference, label, definition, calculation, and presentation.
The instant document, taxonomies and linkbases are all connected using an XML linking standard called xlink.

XBRL was developed primarily by accountants as a way of standardizing business reporting. As such, GAAP (generally accepted accounting principles) are the standard types of elements we find in XBRL taxonomies. Let's look at an example of XBRL. The following excerpt comes from the 8-K (a "current report" companies must file to announce to shareholders any major event or change between the quarterly and annual reports) SEC filing of Comcast Corp:

[Note: spaces have been added around the brackets to show the code]
< unit id="USD" >
< measure>iso4217:USD
< /unit >
< !--Tuple Section-- >
< usfr-pte:TreasuryStock >
< usfr-pte:TreasuryStockDescription contextRef="Context3" >
Treasury stock, 243,640,500 Class A common shares and 47,289,843 Class A Special common shares
< /usfr-pte:TreasuryStockDescription >
< usfr-pte:TreasuryStockValue contextRef="Context3" unitRef="USD" decimals="INF" >-7517000000< /usfr-pte:TreasuryStockValue >
< /usfr-pte:TreasuryStock >
< usfr-pte:TreasuryStock >
< usfr-pte:TreasuryStockDescription contextRef="Context6" >
Treasury stock, 243,640,500 Class A common shares and 47,289,843 Class A Special common shares
< /usfr-pte:TreasuryStockDescription >
< usfr-pte:TreasuryStockValue contextRef="Context6" unitRef="USD" decimals="INF" >-7517000000< /usfr-pte:TreasuryStockValue >
< /usfr-pte:TreasuryStock >
< usfr-pte:PreferredStock >
< usfr-pte:PreferredStockDescription contextRef="Context3" >
Preferred stock authorized 20,000,000 shares; issued, zero
< /usfr-pte:PreferredStockDescription >
< usfr-pte:PreferredStockValue contextRef="Context3" unitRef="USD" decimals="INF">0
< usfr-pte:PreferredStockSharesAuthorized contextRef="Context3" unitRef="Shares" decimals="INF">20000000
< usfr-pte:PreferredStockSharesIssued contextRef="Context3" unitRef="Shares" decimals="INF">0
< /usfr-pte:PreferredStock >

Some things to point out. First of all, the term "tuple" refers to a set of items that are grouped together. In this case, the tuple refers to a number of different Treasury Stocks. Also, notice how XBRL allows references to international standards. In this case, US currency is used and the ISO4217 is the value for the "measure" attribute. Additional elements in this example include "Preferred Stock," "Preferred Stock Description," "Preferred Stock Shares Issued," etc. We can see from this small example how specific XBRL can be in terms of elements used. If we were to look instead at an XBRL instance document for a cash-flow statement or some other financial statement we would see an entirely different set of elements (i.e. revenue, EBITDA). One key element that we do not see in this particular example is reporting period, usually two date values. Time period for financial information is essential and a key element in XBRL.

Just one final word about taxonomies, as they are the key extensible item in XBRL that individual companies can use to create an appropriate XBRL instance documents. The whole point of XBRL is to standardize reporting. If everyone went off willy-nilly creating their taxonomies, the standardization would not work. So "XBRL International" has established "approved taxonomies" that comply with XBRL guidelines for that type of taxonomy, as well as with the XBRL specification itself. "Acknowledged taxonomies" also exist, but only comply with the XBRL specification, not the guidelines established for that kind of taxonomy. When creating a taxonomy, a user may want to consult the official guide to the XBRL Taxonomy Recognition process.

A new focus on XBRL

I am shifting the focus of this blog to XBRL--eXtensible Business Reporting Language. XBRL is a metadata schema for business and financial data developed by an international consortium of approximately 450 companies and agencies. The idea behind XBRL is to leverage metadata to get more out of business and financial data generated by organizations. An example of business and financial data are SEC filings (all those pesky documents the federal government requires from public companies).

Why create XBRL? Metadata makes business and financial data machine readable--data can be manipulated, analyzed, compared, stored and exchanged very easily when each element is tagged and defined. This is good for the bottom line. (More benefits of using XBRL will be described in this blog, but as all benefits ultimately relate to the bottom line, l will stick to that explanation for now.)

As the story goes, XBRL was conceived in 1998 by American CPA, Charles Hoffman. Hoffman imagined the potential of using XML for financial reporting and took his idea to the High Tech Task Force of the AICPA (American Institute of Certified Public Accountants) a few months later. The AICPA gets behind his idea and the project moves forward, eventually spawning a multi-organizational steering committee. One should note that XBRL began in the United States and has grown over the past 8 years to encompass global stakeholders as well.

The people who develop and update XBRL today are high ranking members of the 450 organizations that make up the consortium. Finance, accounting and information technology are the expertise represented in the XBRL Steering Committee. (Not a librarian in the bunch, not surprisingly due to the financial and business subject expertise XBRL requires.)

For more information straight from the source, check out the XBRL official website:

http://www.xbrl.org/Home/

Business Metadata in Context (or what a year in a law firm taught me about the power of metadata)

As a start, I thought I'd explain my first experience with metadata at work.

Like many lay people, I used metadata before I knew it had a name. I used metadata to get my job done, unaware of any underlying concept of information organization.

My first job after graduating from a small liberal arts university with a major in Music was as a Legal Assistant in a large corporate law firm. I worked in transactional law--I worked with documents, lots of 'em with different versions, authors, names editors, dates, client-matter numbers and countless other bits of associated information. All of the firms documents were stored and managed by a software application that required a user to input much of this "associated information" before saving a new document. Anyone within the firm could then search for and pull up desired documents using that input information.

Once I began to do the tasks required of me, I never questioned why the firm would implement such a system. I learned quickly how to leverage the system to answer the following typical requests and questions made by my supervising attorney :

-Who edited document X before we emailed it to the client?
-Can you find document Y Joe created for the client a few months ago?
-Has Jane created any documents for this client matter?
-Find me a template of document Z so we can use parts of it for our client.

I searched and even created the "associated information" myself for documents I saved to the system, and became aware of the problems caused by unguided, individual metadata input. But that's another story.

In the case of the law firm, metadata was used in conjunction with a document management system to facilitate sharing of documents across the firm--a knowledge management initiative of sorts. In this blog, all aspects of enterprise metadata use will be explored, including KM programs, to understand the variety of situations metadata can be used to improve enterprise function and, of course, the bottom line.

Welcome!

Welcome! This blog will explore metadata in business contexts as part of on an ongoing project for LIS 524 (Metadata for Information Professionals, Dr. Sherry Vellucci, Rutgers SCILS, Fall 2006).