Digital Financial Reporting

Over the past several days I have been undertaking a fascinating review of a set of 5525 SEC XBRL financial filings for the purposes of (a) better understanding the semantic model of financial reports and (b) to see how SEC XBRL filings adhere to that model.

This is what I have found for those 5525, all 10-Q and 10-K SEC XBRL filings:

• 5,525 of the set (100%) report the concept dei:EntityRegistrantName.
• 1,166 of the set (21%) report the concept dei:TradingSymbol, which means that this concept is really not that useful, because some have it, some don't.
• 5,525 of the set (100%) report the concept dei:DocumentPeriodEndDate; however, about 20 filers report the wrong value (i.e. not the balance sheet date, looks like they are using the submission date or something). All the others report this properly and this concept makes finding the current period balance sheet a cake walk.
• 5,382 of the set (97%) report the concept us-gaap:Assets.
• 5,384 of the set (97%) report the concept us-gaap:LiabilitiesAndStockholdersEquity or us-gaap:LiabilitiesAndPartnersCapital. (Personally, I belive the US GAAP Taxonony should have only one concept, which would be us-gaap:LiabilitiesAndEquity.)
• 5,382 of this set (97%) have the concept for Assets and the concept for LiabilitiesAndEquity being equal.  What was really interesting is that I saw 5 filings where the balance sheet did not balance (i.e. these two numbers did NOT agree) in either the HTML filing or in the XBRL filing.
• 5,312 of the set (96%) report one of four concepts which represents Equity: us-gaap:StockholdersEquityIncludingPortionAttributableToNoncontrollingInterest, us-gaap:StockholdersEquity, us-gaap:PartnersCapitalIncludingPortionAttributableToNoncontrollingInterest, us-gaap:PartnersCapital. Further, there is inconsistent use of these equity concepts, but you can figure out the value of Equity for each of these filers. (Personally, I believe there should only be two concepts: us-gaap:Equity and us-gaap:EquityOfParent).
• 3,691 of the set (67%) report components of Liabilities and Equity which I can confirm add up to the total of Liabilities and Equity.  What I mean by this is that Liabilities and Equity = Liabilities + Commitments and Contingencies + Redeemable Noncontrolling Interest + Redeemable Preferred Stock + Equity.  Now this is interesting because I did not think you could provide a value for commitments and contingencies, so I learned something.  This is probably the hairiest thing to figure out other than Revenues.  There are more that probably got this correct, but I cannot compute the values correctly because of the goofy way different classes of redeemable preferred stock are handled.  But this goofy approach is consistent with the goofy approach multiple classes of normal preferred and common stock are handled.
• 5,304 of the set (96%) reported net cash flow on the cash flow statement using the concept: us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease or us-gaap:CashPeriodIncreaseDecrease. (Personally, it seems to me that only one concept is needed here for the US GAAP Taxonomy).
• 5390 of the set (98%) reported one of three concepts to express what amounts to Net Income (Loss): us-gaap:ProfitLoss, us-gaap:NetIncomeLoss, us-gaap:NetIncomeLossAvailableToCommonStockholdersBasic.  Now, what I am saying is that the US GAAP term "Net Income (Loss)" is being reported using three DIFFERENT concepts.  Basically, there is ambiguity as to which of the three of those concepts to use in different reporting scenarios.  I think I have the right algorithm for detecting the correct concept but I cannot be sure as I have not tied out the income statement like I have tied out the upper level of the balance sheet which proves my balance sheet numbers are correct.
• 4,641 of the set (84%) reported one of 10 different concepts which represents some variation of the notion of Revenue.
• 5,299 of the set (96%) used one of 10 concepts to report what amounts to Organization, Consolidation, Basis of Reporting, Nature of Business, or other information related to the presentation of financial statements.

Now, what is even more interesting is that 3,170 (57%) have a combination of all of the characteristics which I was looking for in that bulleted list!  There were 21 different "generators" of this set of SEC XBRL financial filings.

What does this mean?  Well, to me it means a few things.  First, for where we are in the SEC XBRL reporting game, this is pretty impressive in terms of quality particularly considering the large group of those creating this XBRL. If all 3,170 of these were from one source that would be significantly different than from this much larger source of these filings.  Second, while my models were simpler, the model is expanding in complexity but not by a lot really.  Third, there is definitely a leveragable semantic model peering out from that set of 5,525 SEC financial filings.

My next step is to drill into the cash flow statement one more level, which will be rather easy.  After that I will tackle the income statement which be more of a challenge as there is very little consistent upper level structure to leverage.  Or said better, it may be that there is more variety so it is harder to detect the patterns.  Or another way of looking at it is that a bottom up approach may be superior to a top down approach.  We shall see.

The individual disclosures are a bit of a different story, but how to handle them is beginning to reveal itself.

One approach to working with XBRL is to break the problem into two pieces: (a) creating easier to use infosets and then (b) working with those infosets.  An example of this can be seen in trying to render information from an XBRL based digital business report.

This working database application (Microsoft Access 2003 format) shows how this can work. It is also a call to any programmers who might want to tackle the rendering problem.  At the risk of being laughed at, I make this code (remember, I am a CPA, not a developer) available. That function has two specific issues which I have not tackled due to my limited programming skills:

• It does not leverage the information model when it formats the information.
• It works with only one [Axis] in columns or rows.

Solve those two issues, I believe that an automated rendering using only information provided in the XBRL instance and XBRL taxonomy and the characteristics of these information model metapatterns which is very usable by business people can be created.

Basically, that database works against infosets generated by an XBRL processor.  The functions you run set up the application to run against these pre-generated infosets for any of the metapatterns, business use cases, or comprehensive example.  Here are the infosets of one of the business use cases:

• Relations infoset (human readable)
• Fact tables infoset (human readable)
• Report elements infoset (human readable)

The ultimate goal or target is to be able to render the information of a business report such as a financial statement, improving upon my best attempt here. (This is what a printed version of this might look like. That is the comprehensive example which is all the metapatterns and business use cases combined.)

Again, I am not trying to attack the "interactive" features of a model-based digital business report, or the "jumping around, navigation features within a report"; only get a usable, static HTML rendering.  I have seen the characteristics that I am looking for within existing combined set of rendering tools.  However, no one tool supports all that is needed.  For example, the SEC interactive data application renders a few of the metapatterns well (roll up, roll forward, and a few others); but it does not do all of them.  The Firefox XBRL Viewer Add on is wonderfully interactive and supports jumping around in the report; but it does not understand the information model patterns and does not leverage them.  Other rendering tools do other things well.

My rendering code has only about 300 lines.  I figure that the two things which need to be dealt with might double, maybe quadruple what I already have.  OK, so 1200 lines of code. This seems like a pretty basic tree structure problem.

Have a look, even try to modify the rendering code to make it work against all my test cases.  If you come up with something I would really like to see it.

These are targets (i.e. correct examples):

• Hierarchy: http://www.xbrlsite.com/DigitalFinancialReporting/Metapatterns/2011-07-15/01-Hierarchy/All_Renderings.html
• Roll up: http://www.xbrlsite.com/DigitalFinancialReporting/Metapatterns/2011-07-15/02-RollUp/All_Renderings.html
• Roll Forward: http://www.xbrlsite.com/DigitalFinancialReporting/Metapatterns/2011-07-15/03-RollForward/All_Renderings.html
• Compound Fact: http://www.xbrlsite.com/DigitalFinancialReporting/Metapatterns/2011-07-15/04-CompoundFact/Index.html
• Adjustment: http://www.xbrlsite.com/DigitalFinancialReporting/Metapatterns/2011-07-15/05-Adjustment/All_Renderings.html
• Variance: http://www.xbrlsite.com/DigitalFinancialReporting/Metapatterns/2011-07-15/06-Variance/All_Renderings.html
• Complex Computation: http://www.xbrlsite.com/DigitalFinancialReporting/Metapatterns/2011-07-15/07-ComplexComputation/All_Renderings.html
• Text Block: http://www.xbrlsite.com/DigitalFinancialReporting/Metapatterns/2011-07-15/08-TextBlock/All_Renderings.html
• Grid: http://www.xbrlsite.com/DigitalFinancialReporting/Metapatterns/2011-07-15/09-Grid/All_Renderings.html

Someone pointed me to a  BBC documentary Six Degrees of Separation which discusses network theory.  This is very insightful. Here is the video in its parts. The total running time is about 1 hour and worth watching.  (I got this from this URL which someone sent me.)

1. Part 1
2. Part 2
3. Part 3
4. Part 4
5. Part 5

Several interesting links were referred to in this documentary and which I stumbled across as a result of watching this documentary:

• Oracle of Bacon
• Oracle of Baseball
• Network Theory
• Small world Networks
• Map of the World Wide Web
• Disease Gene Map
• Disease Gene Map 2 (New York Times)
• Tree Structure
• SQL graph tree processing (Google Search)
• Modeling Trees in SQL

My first question when I saw this was the difference between network theory and graph theory. Network theory seem to try and explain that many things exist as networks.  Graph theory seems to be an approach to explain a network.  I could be wrong.

The comprehensive exampledigital financial report provides a good opportunity to better understand what an infoset is and how it is useful. What I will show here is that these intermediate infosets break the XBRL problem into two separate and distinct problems.

Here is a summary of the infosets I generate for the comprehensive example.  Provided are an HTML human readable rendering so you can see what the info set looks like, an SEC style infoset which uses the SEC logical model terminology, and a Business Reporting Logical Model (BRLM) style infoset which uses different terminology.

• Fact tables: Human readable (HTML), SEC style infoset (XML), BRLM style infoset (XML)
• Relations: Human readable (HTML), SEC style infoset (XML), BRLM style infoset (XML)
• Report elements: Human readable (HTML), SEC style infoset (XML), BRLM style infoset (not available)
• Business rules: Human readable (HTML), SEC style infoset (Coming soon), BRLM style infoset (not available)

From these infosets I created this Recap/examination utility. That recap/examination utility is nothing more than a reorganzation of the information within those infosets.  Well, I guess there are a couple other things I use.  I do use a valiation output report for calculations validation, business rules validation, and XBRL syntax validation. So, perhaps one might include those in the infoset.

Where do these infosets come from? They are generated by an XBRL processor.  Now, these infosets are not generated directly from an XBRL processor.  What I do is take the XBRL processor generated infoset which is rather technical in nature, not organized as I wish, and otherwise not what I desire; and I reorganize what the XBRL processor generates using XSLT.  This is a daunting task, and you definitely need an XBRL processor to do this correctly.

But once you have the infosets, the "problems" that you need to solve to make this information useful has nothing to do with XBRL any longer, it is a totally different problem and you don't need an XBRL processor at all.

For example, this is my rather lame attempt at rendering the information contained within the digital business report: rendering. This is what the information might look like in a printed document. That printed version is my target.  Not the "bold" or different sized fonts or other helpful formatting, but rather the formatting of the meaning of the information.  One needs a minimal amount of rendering to put in fact table into a usable, workable form.  Doing this has nothing to to with XBRL, it is all about recognizing the infoset.

In generating that rendering, I did not use XBRL at all.  Never had to touch anything related to XBRL.  It is all about organizing that fact table info set using the fact table, the relations, and the report elements.

My next step with that recap/examination utility is to solve the balance of the rendering issues.  There are two things I am not taking into account correctly because they are beyond my current programming skill level.  The first is leveraging the information model in the generation of the rendering.  You can see how the different information models should be rendered by looking at these metapatterns and business use caserenderings. I could probably figure this out, but I think I am going to seek out someone with programming skills to help me.  The second thing I need to do is deal with multiple [Axis] on columns and rows correctly.  If you look close at the renderings of the comprehensive example, there is only one [Axis] on each column and one on each row.  This is not the case with the metapatterns and business use cases.  Correcting these two issues will provide me with the renderings I am looking for.

I am not going to undertake the "interactive" piece of the rendering puzzle, making it so you can pivot the rendering like an Excel pivot table or how the Firefox add on pivots the rendering.  I will leave that up to people who really know what they are doing, too hard for me to.

So there you have it, the power of infosets.

An updated comprehensive example is available. While this is "feature complete" and makes the primary points necessary, I am going to enhance certain aspects and create this in the style of an SEC XBRL financial filing.

The primary attribute of an XBRL report which this comprehensive example shows is the proper integrity of the different pieces of a business report.  The metapatterns and business use casesshow small, isolated examples which focus on a specific area.  The comprehensive examples pulls things together and focuses on the integrity of the pieces.

The best place to see the integrity is in the XBRL formulas validation results and in the navigation between components within a software application which supports such navigation. The Firefox XBRL add on is such a software application.

Stay tuned, lots of improvements are in store.