Digital Financial Reporting

I have had several posts relating to what I call the "interactive information hypercube": here, here, here. The idea of interactive information hypercube grew from prototyping I was doing while testing ideas which I wanted to get into the US GAAP Taxonomy Architecture.  I was successful with many, not as successful with others. Frankly, I learned a great deal from the experience of working on the US GAAP Taxonomy Architecture group. (Go look at the authors of the document, those are XBRL heavyweights!)

I took what I learned from helping to create the US GAAP Taxonomy Architecture and took that to the next level and created what I called XBRLS with another XBRL heavyweight. Those ideas where summarized in the document XBRLS: How a simpler XBRL can be a better XBRL. In that document I called what evolved into the interactive information hypercube idea "neutral format tables".  These have also been referred to as "generic tables" and "general table format" among other things.

For my State Fact Book Prototype I created yet another iteration. This one actually works to a degree. You can get to that prototype from that State Fact Book Prototype link or this is a direct link to the prototype created in Excel. Here is documentation which walks you through the prototype.

Two other influences on this interactive information hypercube is the Interoperable Taxonomy Architecture (ITA) work I am doing with the XBRL International Taxonomy Architecture Working Group toward expressing a logical model for financial reporting. This UML model and mind map of the financial reporting domain are my input to that group.

I came up with the term interactive information hypercube in the following way:

• Interactive came from the SEC. I admit I stole that idea, it is a good one.  The SEC coined the term "interactive data". Heck, like Picasso said, "Good artists copy, great artists steal." But I did not agree with their use of the term data.
• I chose to use the term information rather than data because the hypercube are really about information, not data.  See this white paper Data, Information, Knowledge, and Wisdom to understand the difference.
• The term "cube" is used by the OLAP people, but hypercube is really a better term. A cube is three dimensional whereas a hypercube is n-dimensinal (any number of dimensions). Fundamentally, the flexibility of multidimensional model is what is important.  The ADAPT model and the OLAP Council White Paper. OLAP gets in the way as its focus is on aggregating numbers.  The interactive information hypercube can aggregate, but it does not have to.  Also, the interactive information hypercube handles text.  Most OLAP applications have a very difficult time handing text. In my view this is a limitation of business intelligence tools.

Keep all this in the back of your mind and use your imagination when you have a look at the prototype/demo. This is not a truly functional application, I took some short cuts which are explained in the documentation. I get more and more convinced that this is a good idea the more I fiddle with it.

If you look at a business report, such as a financial report, they are really a bunch of hypercubes strung together.  Here is an example of that I put together in 2007, stringing pivot tables together: PDF of a financial, same financial as Excel pivot tables.

You can achieve this today give the right XBRL taxonomy architecture.  The US GAAP Taxonomy is a big step in that direction but is still a little too inconsistent in the way it is built.  XBRLS provides better discipline in terms of how to structure your XBRL taxonomy.  Given the right architecture, rending seems both easy and it provides the "interactive information", the ability for the consumer to reconfigure the information and have it their way.

I mentioned in another blog post that I was creating a prototype State Fact book and using that to compare and contrast XML, XBRL, and RDF. This expands on my brainstorming in another blog post where I was trying to figure out which of the three (XML, XBRL, RDF) were "best".  I expanded that to also include XHTML and iXBRL.

Most of the "raw data" for this comparison is located on this page, the State Fact Book Index.  On this page there are 8 different sets of information.  Each of those sets are made available in XHTML so you can easily see what the data looks like.  I also made each available in XML.  Three sets are available in XBRL (but those three sets contain 100% of the information for the other sets).  The first set also contains an iXBRL (inline XBRL) example and an RDF example. I may, or may not, build out RDF, XBRL, and iXBRL for each set but I really don't need to because I am seeing the things I need to see.

The Story of the Three Bears

Remember the Story of the Three Bears? I am seeing a similar story when I compare and contrast XML, XBRL, and RDF.  Let me leave XHTML and iXBRL for later.

This is what I am seeing: 

• XML is general purpose.  You can use XML for many, many different types of information exchange needs. When you use XML though, you generally start from scratch unless you create some sort of framework to work within. I talk about how, for example, NIEM building an XML framework in this blog post.  The framework helps you be more efficient and effective. That is a good thing.
• RDF powerful, can become complex and is general purpose.  You can do anything with RDF also. RDF is for doing something different than XML.  RDF is for expressing semantic meaning which is way more powerful that XML which is a syntax.  RDF is also somewhat of a least common denominator.  If you wanted to get all the information in the world to be able to work together, you would use RDF to do that.  In fact, that is pretty much the goal of the Semantic Web. Like I said, RDF is extremely powerful and once you start getting into making use of that power, it can become complex.  RDF tools are not really usable by the typical business user.
• XBRL seems like a compromise between XML and RDF. XBRL is a general purpose language also, but its "general purpose" is does not mean everything, the focus of XBRL is on business reporting.  So, it is more of a general purpose business reporting tool.  XBRL can become complex like RDF because it is quite powerful. It is not powerful in the same way that RDF is powerful.  Again, you can do anything with RDF.  XBRL is for business reporting, it is optimized for that scope.  Software which works with XBRL at the syntax level is easier to use than RDF software, but in my view it will still be over the heads of the typical business user. But, it is possible for business users to use XBRL tools to build quite sophisticated solutions using XBRL.  It would be hard for me to believe that these same business users can figure out RDF tools.  Personally, I struggle with RDF and RDF tools.

Making XBRL Less General Makes it Easier to Use

Like I said, XBRL is a general purpose tool for business reporting.  Business reporting is a broad category and XBRL has features or many different business reporting use cases.  But each use case will not need to leverage all the power of XBRL in all areas, different domains and use cases will need different pieces of XBRL.  And making XBRL less general makes it easier to use.  This is where application profiles are helpful.

While the average business user would never be able to use an XBRL tool which operates at the XBRL syntax level, applications build for more specific purposes can be very usable by the average business user.  For example, from what I have heard business users tend to struggle with XBRL software for reporting to the US Security and Exchange Commission in XBRL.  Extending the US GAAP Taxonomy can be challenging for business users. Building the XBRL instance can be challenging.  A lot of companies outsource the entire process to third parties, thus loosing the real value that XBRL could provide.  For this reason, people see XBRL as a regulatory mandate, not for what it really is.  I anticipate that this situation will come to an end when software applications are built specifically for US GAAP financial reporting using XBRL.  That is all they do, these will not be general XBRL tools.  But because they are more focused, they will be easier to use.

So, you can get what I see as an order of magnitude increase in usefulness by turning general XBRL into one or more specific XBRL profiles and building specific applications for each profile. This can happen for two reasons. First, some of these domains are quite large.  For example, US GAAP financial reporting is huge.  The SEC filers number about 20,000.  That is plenty large. Non SEC filers who use US GAAP is somewhere between 8 million and 16 million private companies (these are the estimates I have heard).

The second reason is leverage.  XBRL is an XML framework.  For the same reason you would build an XML framework if you are making use of different forms of XML; you will get leverage when you use XBRL as a framework.  XBRL does have well defined boundaries.  Tools can stay inside those boundaries and provide good bases of functionality.  Complexity can be absorbed by applications by really smart business users or technical users who understand a business domain building profiles other less skilled business users can make use of. This is done by the profile constraining the base application.

Not Either/Or

RDF is also an XML framework.  There are may different RDF syntaxes, but there is one in XML.  But the fact of the matter is that the syntax does not even matter.  There are many things that business reporting needs from RDF which XBRL cannot provide and XBRL should never provide.  There are things which XBRL has today that will eventually be built for RDF such as rules.  XBRL has business rules via XBRL Formula.  RDF is known to need this and things like RuleML, the W3C has an initiative to create a rules language.

Semantic "Haves" and "Have nots"

I think the bottom line here is that if you believe that Web 3.0, the Semantic Web, will exist and from what I can see the evidence is mounting that it will and this will be very useful technology; then you will want to be someone who can use this new power.

XML isn't really a solution, it is more part of the problem because XML is really is about syntax, not semantics. You can make XML "semantic" in many cases, that is what RDF is for.  RDF is quite powerful and there will be many very sophisticated things created using RDF for business users.  Most will not be created by business users themselves.

XBRL is a nice compromise.  It enables a business person to leverage these new  semantic technologies in ways they choose.  It is somewhat like the personal computer and the electronic spreadsheet empowered business users, setting them free from the IT department.

It is possible for a business user to use general XBRL. I can, I am a business user.  I know others who can. Most business users will interact with XBRL and harness the power of semantic technologies via application profiles for more specific use cases making things easier and therefore useful. These applications will likely combine XML, XBRL, RDF, and other technologies.

Semantic Web utopia may never be realized, I think it is a vision, something to be strived for.  But the Semantic Web is coming.  In fact, it is already here and ramping up.  Do you want to be a semantic have or semantic have not?

#######################

Second Coming of XML