When President Obama talked about electronic health records the other day, I had no idea how complicated those HL7 records could be. And when I read in this morning's newspaper that the SEC said it would "require the 500 largest U.S. companies to file their financial statements using an interactive format by April 13 in a move aimed at bringing more transparency to U.S. capital markets," I had no idea of the complexity of XBRL (extensible business reporting language), an XML-based format. (This has been brewing for five years, so none of the companies affected should be surprised.)
I was disabused of any notions of simplicity in these areas this morning when Alexander Falk, CEO; Liz Andrews, Product Marketing Manager; and Tara Lefave, PR Manager of Altova visited me and gave me a demo of MissionKit 2009.
For now, let's stick with XBRL, which is plenty to talk about. It's not like XBRL is a simple XML schema. That would unfortunately not be able to capture the complexity of standard financial reports, much less the individualized extensions that most companies make to the standards to reflect their own charts of accounts.
If you look in the overview section of the screen shot above (click on it to open it full size in another window), you'll see that there are about ten different files feeding into one XBRL document. Most of them are us-gaap and XBRL standards that companies never touch; only a few are company-specific extensions. However, the overall complexity is daunting, given that an "item" can be a whole reporting hypercube, as you can see near the lower left.
Given all that complexity, how could a company ever comply with the XBRL reporting mandate? According to Falk, some of his competitors provide tools for adding tags to PDF files to generate XBRL from existing reports. Altova takes the opposite approach: it provides tools for generating XBRL from the accounting database, and also for generating formatted reports in PDF and several other formats from the XBRL.
The screen shot above shows how you would map a database schema to XBRL for a fictional company called Nanonull. It's complicated when you look at the whole thing at once, but setting up the individual mappings is fairly straightforward. This looks to me, at least at first glance, like a much better long-term solution than the alternatives.
Is this important beyond compliance with SEC requirements? W. David Stephenson, who is writing a book about data transparency, says that access to real-time data through a format such as XBRL "changes everything" in terms of business intelligence. Stephenson points to the Netherlands, which has been a pioneer in the use of XBRL, where companies have the option of filing one XBRL report instead of separate written reports to 30-40 different agencies. The Dutch government is projecting enormous savings from this report consolidation; there's also a tremendous additional advantage that the required data elements have been consolidated from 200,000 to 8,000.
Stephenson adds that, according to Saeed Roohani of Bryant University, if ubiquitous real-time reporting were in effect in the last couple of years, all those bad real-estate loans that have brought down our financial system would never have been made.