Digital Financial Reporting

The XBRL-based financial information in US SEC XBRL financial filings offers many clues which are helpful when figuring out how to architect your XBRL-based system. This blog post helps you see some of those clues.  Playing around with the XBRL information in the SEC EDGAR system offers even more.

It is helpful to read two prior blog posts which provide background information.  First this thought experiment (also in chapter 18, page 330 of XBRL for Dummies) helps you see issues related to financial oriented information. Second, the sample code on in the Dow Jones Industrial Average prototype can be helpful in creating pieces of your prototypes.

So let's walk through some of the steps which need to be worked through when working with a set of XBRL-based information.

• Locate the XBRL insances: The first thing you will need to do is locate the XBRL instances which contain the information. For the SEC XBRL information, the SEC provides an RSS feed. But that RSS feed has only the last 100 filings which the SEC has received.  Another resource is provided by XBRL Cloud, the Edgar Dashboard. While that dashboard relates to validation information about XBRL filings, there is an XML file which contains information and helps you identify filings.  The down side is that this feed is not official. In your system, you will want to be sure you have all the filings you want to work with.  Note that neither the SEC RSS feed nor the Edgar Dashboard provided by XBRL CLoud are standards and not an XBRL format.
• Cross XBRL instance queries: Try a simple query as shown in the Dow Jones Industrial Average prototype and you will quickly realize a significant downside of working with XBRL instances directly; they take a long time to load.  Try running the sample code and you will see that it takes about 5 minutes to iterate through only 30 files with no XBRL related processing taking place.  Now, imagine trying to glean information from thousands of XBRL instances.  S.....L.....O.....W.  Perhaps not always, but in many cases you will want to load your XBRL-based information into some sort of database.
• XBRL format: In addition to the issues with all those XBRL instances mentioned in the issue above, XBRL is a great global standard, but not a great format to work with in doing queries.  You will want to either put your information into some database as mentioned above or create some other format. This is the infoset format which I came up with.
• Grabbing sets of information: When working with information you will commonly want to grab a set of information at times.  For example with financial information you might want a balance sheet, income statement, cash flow statement, accounting policies, or some specific disclosure. In SEC XBRL filings this can be problematic as there are no "handles" to grab. This issue is discussed in this blog post. Basically, because ever SEC filer creates their own networks and because [Table]s are polymorphic (can have more than one meaning), there are no high level "handles" to grab. This can be overcome by applying prototype theory and identifying components by their components. In building your system, keep this difference in mind.
• Dealing with metadata inconsistencies: The US GAAP taxonomy has some metadata issues which helps you see problems which can be created by inconsistencies in your metadata. Four of these inconsistencies are explained in this blog post. Testing and proper documentation can help you identify and eliminate these sorts of issues. Metadata inconsistencies can make it extremely difficult to query information.  Algorithms can generally be written to correct many types of inconsistencies.  But, the more you have and the higher the level of variability which exists, the more costly it will be to create these correction mechanisms.  It is better, and less costly, to not have such inconsistencies in the first place.
• Adding additional helpful metadata: Adding additional metadata can be very helpful in working with XBRL-based information.  For example, in SEC XBRL filings the SIC code is very helpful in allowing for classification of entities by industry.  Yet the SIC code is not contained within the actual SEC filings in many cases.  Your system will need to add these types of helpful metadata and maintain that metadata.  The best thing to do in many cases is not not separate the sets of metadata; for example the SEC could simply have just required the SIC code in every SEC XBRL financial filing. Note that the SEC has that information somewhere, XBRL Cloud has this information in the Edgar Dashboard.
• Dealing with periods: The difference between a fiscal period and a calendar period points out an issue in working with periods.  First off, XML Schema data types has no notion of the "quarter". Financial reporting makes heavy use of the quarter.  Secondly, not ever company's year end is December 31.  Many companies have other year ends (i.e. that is what a fiscal period is, something other than a calendar period). Some companies have what is called a 52/53 week fiscal period, particularly companies in the retail industry.

These are just a few of the realities which exist when working with a set of XBRL-based information.  SEC financial filings are used as an example as you can experiment with them, learning what to do and what to avoid when you implement your XBRL-based system.  Each system has its own unique challenges.  Not realizing this can cause architectural problems which could have been avoided.

In order to test the extraction of information from SEC XBRL financial filings and to provide an example of such extraction I created this prototype. The code used to achieve this aggregation of the Dow Jones Industrials 30 stocks is provided, not as an example of good code, but rather as example of how to extract information directly from an XBRL instance.

Dow Jones Industrial Average Mashup (Prototype)

No XBRL processor is used to grab information from the 30 SEC XBRL financial filings.  I am not promoting this technique, I just want to provide a broadly usable example.  While as you can see data can be grabbed using this approach (i.e. this works), building a robust, scalable, reliable, repeatable, and accurate system will definitely take more that what I have shown.

I checked each of the assets and net cash flows numbers against the actual filings to be sure that I got this correct. As far as I can see, the information is accurate.

Think about what this means.  How long would it take you to get just these two pieces of information manually?  It takes the prototype application about 5 minutes or so. The biggest constraint is the file download time.  Imagine running this routine (or a more reliable one) against every SEC XBRL finacial filing and be able to get the total assets and net cash flows of all public companies.  That is actually my next step in testing this code.

Don't have time at the moment, but in another post I will describe issues involved with grabbing these two data points and how to overcome them. For example, getting a list of the files containing the information, having to go file to file rather than getting the information from a database, different period end dates and fiscal periods, and other such idiosyncrasiesof the information. Because of the nature of the information, the SEC XBRL financial filings is a tough dataset to use.  The modeling of filings is a separate issue, that can be easily adjusted.  Adjusting financial filing rules is a totally different matter all together. 

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