Digital Financial Reporting

I posted a comment to the XBRL-Public mailing list relating to the UK's Financial Reporting Council calling for financial reporting to move from paper to the Web (which I also posted to my blog). My post led to a number of comments from others and a very good discussion relating to using the Web for distribution of financial reports. (If you are not on the XBRL-Public mailing list I would encourage you to join the list.)

During that discussion someone made the statement:

I actually think that iXBRL will eventually "take over the world" of XBRL reporting, simply because it supports what humans do - consume information through their eyes.

While I have not always been that hot on Inline XBRL (some people refer to it as iXBRL) because I have been convinced that it is a red herring trying to solve a problem that did not exist and because of the potential abuses of Inline XBRL to work around bad data modeling within an XBRL taxonomy. However, I am changing my mind and realizing that Inline XBRL, if properly used, could be of substantial benefit in ways which had not occurred to me before.

Here is why I am changing my mind and going as far as predicting that the US SEC may follow the lead of the UK and move to Inline XBRL and encouraging others to both be aware of this possibility and consider the Inline XBRL option when and if they implement XBRL:

• Document of record. Inline XBRL offers the possibility of having a "document of record" which is readable by both humans (i.e. the HTML aspect of Inline XBRL) and computers (i.e. the XBRL aspect of Inline XBRL). One does need to be careful to ensure that the information communicated and viewed as HTML is identical to the information a computer application reads, both should be in sync. But that does not seem that challenging and it is certainly easier than what SEC XBRL filers have to do which is keep separate HTML and XBRL documents in sync.
• Evolutionary path. Inline XBRL seems to offer a nice evolutionary path which a lot of people seem to need.  Personally, I am very confident that most people will eventually never use that HTML rendering in favor of the dynamic or "interactive" aspects of XBRL. For example, consider what I call the "hypercube jumping" (really has more to do with dimensions) and discuss in this blog post. But Inline XBRL does not take away the possibility of these dynamic features, they are still there to use, even if the XBRL is buried in an HTML document.
• Decouples presentation and data model. Using Inline XBRL allows for the "decoupling" of two things which, when dealt with together, cause problems. Inline XBRL allows the HTML aspect to deal with presentation, and therefore the creator of the data model is free to create a good data model and not try and get the presentation they are seeking by using the XBRL taxonomy. For example, SEC XBRL filers seek a certain presentation and to get that they leverage the only thing they think they have at their disposal with is the XBRL taxonomy. Using Inline XBRL for the presentation gives one precise control of the presentation. Not having to worry about the differences in presentation and presentation nuances allows for more "freedom" in creating a sound data model.
• Zero difference between XBRL and Inline XBRL. To a computer application trying to read the information, there is zero difference between a plain ole XBRL instance and an Inline XBRL document (instance, not sure what to call it). From the computer's perspective, they are 100%
  interchangeable. Now, I am sure that there are probably interoperability issues and bugs which might need working through, but that is all part of the process of getting things to work on a global scale.

So those are the positive aspects of Inline XBRL.  What about the downside? One thing which could be considered a downside is the fact that the software vendors who are building software to support creation of SEC XBRL filings are already going down a certain path.  Will they want to change that path, moving from supporting plain ole XBRL to also support Inline XBRL?  Well, the UK is already using Inline XBRL so software already exists for that.  This could provide an advantage for software vendors who are supporting Inline XBRL for the UK and a disadvantage for current software vendors supporting the SEC. Not sure how this dynamic will come into play.

Another dynamic which I am even less clear about is the actual creating the HTML and XBRL.  It is hard enough to put in the XBRL information.  How is creating both the HTML and the XBRL at the same time going to work out?  Again, I think the UK will provide some clues.  They are already doing this.

Finally, Inline XBRL is specific to supported rendering formats.  Currently Inline XBRL only works with HTML 4.  HTML 5 is really picking up steam.  The SEC uses an older version of HTML.  Not sure how the version of HTML plays into this or if there is a better rendering format than HTML, maybe PDF via XSL-FO.

Who knows how all this will turn out, but it seems to me that the advantages of Inline XBRL are significant enough that those working with SEC XBRL filings need to be aware of this and keep this possibility on their radar screens.

What do you think about the probability that the SEC might move to Inline XBRL? I cannot imagine that the SEC would do this any time soon.