Digital Financial Reporting

Inline XBRL is not a panacea or other "magic bullet" which will make all problems related to XBRL go away.  Some people seem to believe that it is some universal solution for all that ails XBRL implementations.

This is the way I see the moving pieces related to using Inline XBRL.  First off, it is really not a question of "Inline XBRL" (some people call it iXBRL) or not.  There seem to be the following factions applying XBRL to financial reporting. You have your:

1. Inline XBRL camp
2. Datapoint Model camp (includes Table Linkbase)
3. Global Filer Manual camp (this includes the SEC and US GAAP Taxonomy implementation of XBRL, used for SEC XBRL financial filings)
4. "Go it alone" camp, they just ignore what everyone else is doing

Are these seen as alternatives which are 100% interoperable?  XBRL is a "global standard", why would these not be interoperable? Camp #4 means less than 100% interoperability. So, throwing out option 4, will there ever be one global approach to creating a digital financial report?  Well, that really boils down to whether there will be a world with only IFRS or whether there will be a world with both IFRS and US GAAP. So say we are looking for one and only one approach.  Which is best?  Or, does it matter; are all three approaches interoperable/interchangeable?

So that begs two questions: (a) What does each approach offer? (b) What common issues do all three approaches share?

There is an issue which Inline XBRL, Data Point Model, and the Global Filer manual camps share.  I will give you an example of that issue in a moment.  But first, let me decouple that issue from another issue which many people confuse as the only issue.

The issue is obtaining a human readable rendering of information communicated by XBRL.  Both Inline XBRL and the Data Point Model try and solve this rendering issue.  It is my view that both the Data Point Model and Inline XBRL are both trying to solve something that I am not 100% sure is even a problem.  But, it could be a problem.

The problem is commonly seen as "viewing the information."  I am 100% certain that Inline XBRL solves that problem to the extent that HTML can solve that problem because (a) Inline XBRL uses HTML and (b) HTML does a pretty good job with getting very close to "pixel perfect rendering". 

I am pretty sure that the Data Point Model, which uses the lesser understood table Linkbase, gets very close to what HTML can do if not 100% at the same as HTML and therefor does the same thing as Inline XBRL.  I can believe that from this "viewing the information" perspective, Inline XBRL and the Data Point Model (with the table linkbase) are equivalent.

So from that perspective, let us just say that the two are equivalent.  If they are not, then the specific differences should be quantifiable.

While the Global Filer Manual (of which SEC XBRL financial filings is a subset) are rather poorly rendered by the SEC Interactive Data Viewer and most other software in many cases (and therefore does not seem like an adequate solution); there are generally two reasons for most or at least many rendering problems:  (1) poorly modeled information and (2) rendering engines which do not leverage known information semantics.

And so what I am saying is that it might be possible for an "adequate" rendering could be achieved by simply improving modelings and leveraging information, patterns, within those models.

If it is the case that a rendering engine understands information semantics, and if it is the case models are constructed correctly and consistently; then it is in the realm  of possibility that a rending engine can create an understandable and useful rendering.

Now, that rendering will not be "pixel perfect" or exactly as every person would want to see it because there are so many DIFFERENT ways people might want to see this information.  But, would be a usable rendering?  I am about 98% sure that such a rendering is possible, but because I have not seen such a rendering for 100% of all use cases I cannot say for certain that I am 100% sure.

So, the REAL questions are: (a) what is the target rendering the market needs, "pixel perfect" or "usable" and (b) is it possible to hit that target leveraging what exists in the XBRL instance and XBRL taxonomy plus know and agreed upon semantics and patterns in those semantics of the information.

And so those two questions (what is the target and can that target be achieved) is different than the real thing which ails XBRL.

This issue will NEVER be solved by Inline XBRL nor by the Data Point Model as far as I can tell.  This issue can likewise be broken down into two parts: (a) do domains express enough metadata so that interchangeable models can be created and (b) does XBRL have enough expressive power verification capabilities to verify that good models are being created?

In my view, this is the REAL issue.  XBRL cannot capture enough of the semantics which are necessary in a global-standard way to build high-quality, interoperable financial information which can be effectively exchanged.  Just to remind you again, neither Inline XBRL nor the Data Point Model address this issue.  Also, just packing the XBRL definition linkbase with "stuff" will not solve the problem.

If you look at this visualization of an ontology for a financial report that I am creating you will start to understand what I mean:

http://xbrl.squarespace.com/journal/2013/1/18/financial-report-ontology-draft.html

Like I said, this problem has two moving pieces:  First, many times the semantics are not defined by reporting standards and second, XBRL has no agreed upon way to express the semantics. 

While pretty much anything can be expressed using the XBRL definition linkbase (such as how XBRL Dimensions uses the XBRL definition linkbase to express and then validate multidimensional information); the important point is "agreed upon way to express the information". 

To understand what I am saying all you really need to do is look at the expressive power of something like UML (Unified Modeling Language) which is a modeling tool and how you can have different types of relations (associations, aggregations, etc.) and how UML can express those use cases.  Or, if you look at RDF/RDFS/OWL and the expressiveness of those tools and then if you think of how you would express the same information using XBRL, you then begin to realize the limitations of XBRL for expressing needed information.

A specific example of XBRL's limitations is XBRL Dimension's expression of meaning of the relationships between the members of a domain.  All you can do is basically express that there is a relation, which is unlike UML or RDF/OWL which lets you express the type of relation.

Another example of this is how one would express the relations between the components of a reporting entity.  The 2013 US GAAP Guide, published by Wiley, provides an excellent example of both an inadequate expression of the semantics of the components of a reporting entity by US GAAP (this is NOT a problem of XBRL, it is a problem within the domain of financial reporting) and exactly the type of relations which need to be expressed. 

US GAAP defines terms used to describe these sorts of entity components differently in different places within US GAAP.  It also uses different names and does not even define some terms which relate to expressing the components of a reporting entity.

This includes such terms as parent holding company, consolidated entity, reporting unit, asset group, disposal group, subsidiary, business segment, geographic area, business unit, legal entity, operating segment.  (I am NOT saying that some of these terms are not defined.  Some are.  What I am saying is that some of these terms are not defined, some are defined ambiguously in GAAP, some are defined in multiple ways but mean exactly the same thing.)

If you try and model information about the relations between the components of a reporting entity then you begin to understand what is necessary from XBRL to make information expressed using XBRL truly interchangeable between business users (i.e. no ambiguity).  Further, you gain additional insight if you look at the current set of SEC XBRL financial filings.  If you do so you get an even better understanding of the limitations of XBRL and the needs of any reporting scheme or system making use of XBRL appropriately to make the information usable.

Like I said, neither Inline XBRL nor the Data Point Model (with the table linkbase) solves this problem.  And therefore, if one moves to Inline XBRL or the Data Point model, one will be disappointed that the move did not get you where you really wanted to be.

Another thing which is related to this is that I now understand the problem which some people had with XBRL Dimensions.  Its expressiveness is missing certain key pieces. 

This is a work in progress, so stay tuned!  I have created a financial report ontology. The "things" used in the financial report ontology will be defined in human readable terms here. A visual representation of the "things" can be found here.

Still to come is a UML (Unified modeling language) representation and an RDF/RDFS/OWL (Semantic Web Technologies) representation.

Why am I doing this?  See here and here.

If you want to participate and learn a lot, please contact me and I will get you dialed in.

I mentioned this comparison utility tool in a prior blog post, but it is worth elaborating on a bit more.

This comparison utility tool was created by me in collaboration with Cirrus and XBRL Cloud.  I use the XML infosets of an SEC XBRL financial report provided by XBRL Cloud and ideas from Cirrus and wrote an Excel application which generates the comparison that you see below (click on the image to see a bigger image, click here to download the Excel spreasheet):

Comparison of Costco and Wal Mart Income StatementsOn the left you see the Costco income statement.  On the right you see the Wal Mart income statement.  Between the two you see red cells and green cells.  The green cells have the row number of the matching report element within the other financial report component being compared.  Yellow highlighting indicates no matching report element, white rows indicate that there was a match. Downloading the Excel spreadsheet and looking at it makes it more clear how this works.

The Excel spreadsheet has the income statement and balance sheet comparisons.  But, you can compare any two components from any SEC XBRL financial filing.  While this is helpful for looking at the primary financial statements, it is even more helpful in analyzing the many disclosures. You can also use this comparison tool to look at changes between the 2012 and 2013 US GAAP Taxonomy.

This comparison is useful because how other reporting entities model a component of a financial report is good information which can be used to be sure you are modeling your financial report appropriately.  This is particularly true if the other reporting entity is in your peer group.

If you are interested in using this comparison utility please contact Cirrus, XBRL Cloud, or send me an email.

I build a lot of my own utility tools for working with SEC XBRL financial filings myself using Microsoft Access.  Generally, I don't put nice interfaces on the tools, I just use the database information and if I need to make something look better, I move the information into Excel and do that there.

But, I took the time to create some user friendly interfaces on some of the utility tools which I have built.  They are limited by my programming skills, but you can see these interfaces, which I think are useful to accountants, here.

User interface screenshots

The best way to take a look at the screen shots is to follow the link and just watch a slide show of the images. Take time and really look at what you see.

You may ask yourself, "How is he organizing the financial report disclosures and/or the entities the way they are organized."  The answer is metadata.  See how helpful that metadata can be.

The screen shots are pretty much self explanatory.  If you have any other ideas, let me know what they are.  I want to get software vendors interested in creating utility tools useful to accountants.