Distance Software takes on a very wide variety of projects. That's part of the fun of being a consulting company, and a major reason why I decided to start a business. In our work, we often become very knowledgeable about certain applications, tools, libraries, and specifications. As many of these are niche items, do not receive the same level of discussion and review that bigger technologies enjoy, I am starting up a new feature here on Shouting Distance called "Technology Focus" to help broaden the coverage of these items.

The technology in focus today is XBRL, the eXtensible Business Reporting Language. XBRL is at its core, a set of specifications for the encoding of enterprise data in XML format. XBRL can used to describe two main things:

1. Concept Taxonomies - An encoding of a set of business concepts along with significant additional metadata for describing the presentation, validation, and source of the concepts. For instance, the taxonomy might contain a concept like "Cash and Cash Equivalents" with metadata indicating that it is an instantaneous measurement, i.e. it represents a value at a point in time, not a change over a period of time, and that it must be represented by a number.
2. Instance Documents - An encoding of a certain set of data for a particular business that refers to a particular taxonomy. For instance, The instance document using the taxonomy described above might have an entry for the "Cash and Cash Equivalents" concept with a value of 100, with unit information indicating that the number is in millions of USD, and context information indicating that the number represents the period ending March 31, 2008. The document is an "instantiation" of the concepts described in the taxonomy, hence the name Instance Document.

XBRL got a major boost recently when the SEC mandated that all companies with a market capitalization of more than $5B would be required to file their financial disclosures using XBRL starting in 2009, with the remaining companies required to comply by 2011 (See this Gartner article for more information). The SEC spent a long time creating their own taxonomy explicitly for this purpose, the US GAAP Taxonomy (UGT). The SEC filing system has been updated to accept XBRL instance document submissions that are built using the UGT, and under a voluntary XBRL program, filers could attach an additional XBRL document (not considered part of the "real" filing) to their standard filing to test the new system. However, starting very shortly, XBRL submissions will be the standard.

The XBRL specification itself is fairly complex. While it makes use of standard XML concepts, such as that each taxonomy is a valid XML Schema Document, it also uses other standards such as XLink and XPointer to allow a taxonomy to be dynamically composed. Using an initial taxonomy document as a jumping off point, a valid XBRL schema processor must follow the various linkages and pointers to grab all of the directly and indirectly referenced documents and concepts to produce what is referred to as the Discoverable Taxonomy Set (DTS). The specification and the rules for generating the DTS can be found at xbrl.org, the international XBRL organization.

This can all seem overly complex at first glance, but ultimately, it needed to equal the complexity of the representation problem, which is only all possible financial data. Consider the following challenges, XBRL needs to:

1. Allow for the representation of data across many types of reports, from simple balance sheets and cash flow statements to the risk/return information in a mutual fund prospectus.
2. Support taxonomies that are generally useful, such that a large number of companies can all report on a similar set of concepts in a consistent way, but at the same time, be flexible enough to allow an individual company to represent additional data that is generally acknowledge but optional, down to concepts that are totally idiosyncratic to a single company's operations.
3. Work for financial reporting concepts around the world. It can't just work for GAAP-based accounting, but it must work for IFRS reporting, the British system, the Australian system, the Dutch system, the Japanese system, and so on. While these different accounting systems share many common features, they each have a unique set of standards and concepts that must be supported.
4. Be able to adapt as the standards change. Not only must it function across all financial reporting systems, but those standards change over time, often extremely rapidly.

As much as I appreciate simple, elegant standards, the world of financial reporting is neither simple nor elegant and it requires a solution that can meet these and many other challenges.

Tomorrow: Part II - What XBRL can do, and a few Caveats