For those that have followed CLOUD for the last several months, you already know that our vision is not only bold, but that it is blessed by some “bright lights” in the XBRL community. From my college friend and the the Sr. Advisor to former Chairman Cox at the SEC, Paul Wilkinson, who is our Chief Strategy Officer, to Charlie Hoffman, the “father of XBRL,” who is a member of our strategic advisory board, CLOUD is fortunate to share some common blood lines with the eXtensible Business Reporting Language. As I sit here on my flight to Philadelphia for the XBRL US conference, I am getting excited about being knee deep in the topic and the community for the next few days. As I make the trip, however, I have not been able to shake this nagging question that I’ve had since I first picked up Charlie and Liv’s book, “XBRL for Dummies.” Is the full potential and future success of XBRL trapped by its name?Now, after ten years and a lot of taxonomies (including most recently China), the last thing I am proposing here is to change the name! But, even with the same name, a new perspective might unleash this very important standard to achieve an even bolder and more pervasive future. It seems to me that because of XBRL’s name, it is stuck between two challenges, when and where it is used. I know I’m going to learn a lot more about the ins and outs and daily use of XBRL while I’m in Philadelphia, but it seems to me that “tagging” the business information at the point of reporting misses the point. During Sibos (SWIFT’s global financial services conference) in Amsterdam two weeks ago, I was exposed to a lot of really great thinkers on the topic of the semantic web. One of the issues with the semantic web is well… how to make it semantic, and that means, of course, tags.
So, the issue is when, where and how do you start the tag stream? And, like the placement centers at our universities, does it make sense to put either at the “end” of the process. Placement centers would be far more useful during our freshman year, so as to help guide the courses we might take the next four years, while we can still change things. It seems as if XBRL is plagued by the same issue. Do we start using it too late in the process? What would happen if XBRL tagging occurred at the moment that information was “created.” Would new possibilities be unlocked for the newly semantically-tagged information and would the heavy lifting required to get our financial reports tucked neatly into XBRL and the appropriate taxonomies change complexion as a result of this new paradigm?
As I commented a few months ago in “When Standards Interact: A CLOUD-Inspired Future for XBRL,” the verbs we use to describe the process for XBRL filings belies the fact that we are using 21st century technology in decidedly paper-based ways. I will be expanding on this concept in an upcoming book, “The End of Linearity: How the Shift From Paper to the Internet is Bigger than the Shift from Scrolls to the Gutenberg Press.” At a basic level, the very geography of our business reports changes in the electronic world. The reports are no longer trapped by the geography of paper and the ways in which this two-dimensional framework forces us to construct data sets. And, that is, of course, all a financial report is. It is a data set compiled in a specific way, using a specific language (taxonomy) to communicate a specific set of information to a fairly narrow community of users for that information.
I would conted that the power of XBRL has not yet been fully unleashed, and there are at least two vectors by which it can begin to expand its influence. By developing into these new arenas, I would also argue that it can take on more of the characteristics of HTML as a standard, as opposed to the more laborious adoption curve it has experienced to date. No one asks how to put together a web page anymore. It is assumed that if you are creating a window into the Internet for presentation of information, then you have likely “tagged” it in HTML. There may be debate at the edges, like the recent one between Adobe and Apple over Flash versus HTML5, but notice that HTML was still part of the debate. Of course, the recent announcements by China regarding its taxonomy certainly adds a large number of people and companies to the equation in XBRL’s favor! But, it can go further.
The first vector for XBRL’s expansion is to simply have more data tagged in the language. The recent elections may actually do more for government transparency than any other area. As I tweeted recently, it is ironic that we needed this election to achieve this goal in light of the 2008 election that ushered in the most transparent administration in history. However, this is not a political debate. We shouldn’t have to elect anyone to have transparent information. With S 303 and HR 6038 capable of being passed even before the new Congress convenes in January, the first vector for XBRL can be achieved, making “reams of information” (to use a paper-based term) capable of being tagged with XBRL. With all of the effort to have information that is inbound to government (i.e. SEC filings) tagged in XBRL, this will be an interesting inflection point to have the equation reversed. These bills would make outbound information equally transparent.
The second vector for XBRL’s expansion would be to break the tagging process free of its use at the end of information’s life. The point after which it has already been aggregated in a report simply does not seem like a logical spot for the tagging. As I commented during several corporate actions and XBRL panels at Sibos
, “the Internet is not an electronic courier service for documents.” A financial report or an electronic health record are not data sources but are instead presentation layers by which data is consumed. The most logical spot to tag is at the exact moment information is created. Just like the Mississippi River, our tag streams must start at the source. This new perspective on XBRL would not only radically change the work flows but change the whole paradigm. As the diagram on this page makes clear, just because data may be consumed in a financial report or an investment portfolio doesn’t mean we have to replicate the data to see it in different contexts. It also doesn’t mean I have to move the data into one unique silo or discrete silos so these contexts can be managed. The only time you have a data syncing or scrubbing problem is when you have more than one database with the same data. Having multiple primary sources of information is an entirely different discussion than the one about backups.
The opportunity that both of these vectors represent is the opportunity to have both more information tagged in XBRL, while simultaneously making it more efficient to tag this data in the first place. From there, it is a consumption question. One path for the data would be its aggregation for reporting to the SEC. However, the same data (as seen in the diagram above) could be consumed by someone compiling an investment report on a particular industry. Based on an appropriate context (and rights layer) like the one envisioned by CLOUD, this same data could also be accessed by trading partners in an industry value chain. For example, Dell, based in Round Rock, Texas, offers its large corporate customers asset management services, for the many pieces of technology they purchase from Dell. At the point that the purchase orders are instantiated, this information could be tagged in XBRL, making the information accessible not only to Dell’s internal business management (and ultimate SEC filings) but also making it accessible to their customers’ IT departments.
I believe the future of XBRL is bright. By thinking more about the ways in which we consume and share information, we can break both XBRL, the standard, and its management free of the geography of our 2-dimesional world and enable the very hypercubes that make the multi-dimensional world of the Internet so interesting in the first place. In the process, we can make XBRL about business and not just reporting.