Digital Financial Reporting

This is interesting.  I stumbled across my book, Financial Reporting Using XBRL, on Amazon.com selling for $89 and $189 as after market copies.  So here is a business opportunity for you.  Go to Lulu, buy the book for about $19, and then make a healthy margin selling it on Amazon.com!

Seems like the market for things XBRL is pretty good!

Here is another demo of using the information the SEC is providing in XBRL.

Information about the public float of an SEC filer is provided in its XBRL filing, sometimes.  I am not sure what the rules are about this.  But, the RSS feed of the filings which I used yielded this information (these are best viewed in Microsoft Internet Explorer, Safari does not show the XML very well):

• In HTML (Humans can read)
• In HTML (Another approach to using HTML; used XML data islands, might require Microsoft Internet Explorer)
• The XML (Computer can easily read)
• The Stylesheet (used to change the XML into more readable HTML)

Basically, I used my Microsoft Access database to read the RSS feed.  The RSS feed pointed to the filings.  I read the filing information, grabbing the fact value for the concept "dei:EntityPublicFloat" where it existed.  (Sometimes it did not exist, not sure what the reporting rules are).

There are various forms which can be used to make the information available (the bulleted list above).  Some formats are easier for computers to read, some are easier for humans to read.

The more consistently the information is provided, the more useful the information. What is made available is determined by the rules an SEC filer has to follow.

This isn't much, I am just goofing around.  But think about this.  Let's say you wanted to know the public float of every public company who files with the SEC.

• Old way: Dig through the filings manually.  Approximate time, about what, say 5 minutes for each filing, let's say you would do this for the 100 filings listed on the EDGAR XBRL RSS feed, so 500 minutes.
• New way: Query the database.  Approximate time, about 1 hour to write the code, 2 minutes to run the code and put the information into Microsoft Access.

The result in: PDF Excel.

Granted, this is a very simple query of information, I am not a programmer, and it does not include all filers.  Like I said, I am just goofing around.  I can grab the 100 XBRL filings made available by the SEC.  Eventually, when you can grab all the filings (i.e. when the RSS feed covers all filings not just the top 100, and when more filers file using XBRL), this may be more useful.  Further, there is a lot of interesting information in those filings.

Some observations

Take a look at the data. I don't understand why only about half of the filers actually provide this information.  I am not sure if it is required by the EDGAR Filing Manual or not.  It is funky how different filers round the information in different ways.  From rounded to billions, to showing information to the dollar, all the way to Keycorp which rounds to the penny.

Fact is, my little application grabs the fact values for all 100 filings in the RSS feed. It was very easy to grab the individual fact values.  Now I am trying to figure out good ways to grab meaningful information and put that information into meaningful presentations.  The more that people do this sort of thing, it seems, the more information which can get back to the SEC about what might be helpful (i.e. like making the RSS feed cover all documents) to enable other sorts of queries, taxonomy adjustments which may be advantageous, etc.

Now, realize that I am not a programmer. This is what I was able to do with the filings to the SEC's Next-Generation EDGAR system.

Goal/Result: The goal was to get a list of the extension concepts filers were creating and using in their filings.  There is no particular purpose for this, only to do it because it is interesting and not that hard to do. Here is the result of what I was able to create.  (This is the Excel spreadsheet which contains the macros, VBA that is, put into a ZIP file which you can use to see how this works.)

First off, I cheated a little.  I used information made available by Cliff Binstock on his XBRL Cloud. And I actually did not use that file which is a human readable version; I used this file, which is an XML version of this same information. You can find a link to that file on the top of the human readable version.

Next, I created a simple Excel macro. Again, this spreadsheet contains those. Pretty basic, I know.  Again, I am a CPA.  Working with the XML is so easy and fun.  The hard part is getting the information you want to work with.  For example, I wanted the extension concepts.  I could have grabbed these from the XBRL instance or from the XBRL taxonomy submitted with the filing.  I also wanted the labels for the concept and the documentation provided by the filer so I could understand what the concept was meant to be for.  Cliff made the list of concepts, their labels, and their documentation available in one location.  I assumed he used his XBRL processor to put these pieces together.  You could put these pieces together using plane old XML.  But, it is too much work when you can simply use an XBRL processor or the pre-processed information.

I loaded the XBRL information about the extensions into the Excel spreadsheet.  This information is in one spreadsheet.  I looked through the information a little, highlighting a few things.  I can see that filers were adding concepts such as "IncomeTax" which I would never have expected to be added. Further, particularly with that concept, there is no documentation explaining the concept.

If you understand Excel macros, but have never used XML, the code samples show you how to do this. It is really amazing how easy working with XML is.  Again, the hard part are having the pieces organized in a way you would use them, NOT in the XBRL physical syntax which is too hard to work with.  That is where an XBRL processor is helpful.

If you endeavor to try and create something interesting, let me know about it; I would love to see what others come up with.

Spreadmarts seem to be another way to explain what some people call "spreadsheet hell".  This article, Reeling In Spreadmarts, by Wayne Eckerson, Director of Research, TDWI, explains the problems caused by spreadsheets and how to solve that problem.

In the article spreadmarts are defined as

renegade spreadsheets and desktop databases that are wreaking havoc on organizations.