Digital Financial Reporting

One of the most frustrating things in my life is getting a treeview control to do what I want in Excel.  Treeview controls seem very illogical to me in VBA.  Now, in VB.Net this is a different story, they make far more sense.

And because of all the trees or hierarchies you have to deal with when working with XBRL, this adds to the frustration.

I can point to two resources which help semi-technical people trying to work with treeviews:

• This is an article which explains the fundamentals of using a treeview control.
• This is an Excel workbook which has a treeview control in it. Someone gave me this code seven or eight years ago and I have used it over, and over, and over.  I modified it slightly to make it easier to use, but it is good code which can be reverse engineered.
• ADDED: Someone sent me this great tutorial on using the treeview control in Micorosoft Access.
• ADDED: Another person sent me this set of tips which is also very helpful.
• ADDED: Another good reference http://mytreeviewblog.blogspot.com/
• ADDED: MSDN http://msdn.microsoft.com/en-us/library/aa443492(VS.60).aspx

If you run across any documentation which explains working with treeview controls in non-technical terms I would really like to have that documentation.

I created a prototype or a concept model of something which has been thrown around for years by CPAs in the XBRL community.  I call it XBRL Trends and Techniques. As you look at this, remember that this is a prototype; use your imagination as you consider what this might offer SEC XBRL filers.

The idea comes from a very popular publication of the AICPA: Accounting Trends and Techniques. That web page says that version is its 63rd year of publication. The publication is basically a survey of about 600 companies create their financial statements.  The survey looks at what is disclosed, how it is disclosed, terminology, etc.

My XBRL Trends and Techniques is a similar idea, only it uses XBRL instead of paper or PDF or DVD.

Imagine what amounts to a searchable database of templates which one could use to create their SEC XBRL filing.  It would work like this.

• Step 1: The templates are created (I will get back to this key step in a moment). OK, so some accountant who understands both financial reporting and XBRL puts together high quality XBRL instances, XBRL taxonomies, business rules (XBRL Formulas), and all the other things one needs.
• Step 2: All the templates are organized into an RSS feed.  Here is my prototype RSS feed. I would likely expand the fields in that feed, modeling it after the iTunes format which is becoming a well accepted standard which is well documented and supported. So, this page is just for looks really. The template library is intended to be read by computer applications, such as SEC XBRL filing software.
• Step 3: SEC XBRL filing software reads this RSS feed. It uses the "Title", "Description", "Keywords" within the software application to help the user find what they need. This supplements the complete US GAAP Taxonomy, it does not replace it.
• Step 4: The SEC filer starts with the template(s) of their liking to create their SEC XBRL filing. They could start with a complete model financial statement, or they could pull together pieces.  They could already have a filing and just need another piece from one or two templates for a new disclosure they need to make.
• Step 5: They complete their SEC XBRL filing.

This is somewhat of a no-brainer idea. Accountants can even make money creating templates for complex areas of financial reporting and sell them.  Heck, there could be a marketplace created to connect those who know how to create templates with those who need them.

I said I would get back to how templates are created.  Remember how I said Accounting Trends and Techniques did a survey of 600 financial statements? Why do they limit the survey to 600?  Well, this is because the survey is done by hand and all the pieces are put together by hand.

You know what the best database of these templates is?  Actual SEC XBRL filings. The templates are good because someone has actually used them. This is how financials are created today, using existing SEC filings to see how someone else approached a disclosure scenario.  Both accountants and attorneys who participate in creating filings do this, but they use the HTML versions or even worse, paper.

A great application which has been discussed for years is an interface into the SEC XBRL database of filings, organized by industry, type of disclosure, filing characteristics, etc.  When filers start seeing this sort of functionality within SEC XBRL filing creation software, then they will start to "get" what XBRL is really all about and see some of what is in it for them.

Consider smaller SEC filers, private companies, auditors or accountants who are creating a financial within an industry they do not have a lot of experience with, etc.  These templates can come from anywhere on the Internet.  This is the way iTunes works.  iTunes is an aggregator.  It pulls all the pieces together into a very useful database of music, video, and other media.  Anyone can create an RSS and submit something which will show up in iTunes.  I have done this.  Why can't the same thing be done for XBRL templates for taxonomies, business rules, etc?  After all, it is all in a standard format, XBRL!

Do you have any ideas for how XBRL can be used in the process of creating financial statements?

This is yet another iteration of the interactive information hypercube viewer that I keep fiddling with.  See this blog post for information on prior iterations.

This version is a major step forward because it actually works!  You can grab information about this prototype here. Read that overview document to understand what is going on.

Note that this version implements the financial reporting logical model (draft) that the XBRL International Taxonomy Architecture Working Group is working on.  The point of the prototype is to test that logical model so that I can provide input to that group.

I would encourage you to grab the Excel prototype application and check it out.  See that overview page for a link to a ZIP file which contains the prototype. If you fiddle with the application what I am hoping that you see is that the XBRL instance information renders quite nicely and is definitely very readable by humans. The rendering is driven by two things: the XBRL instance/XBRL taxonomy DTS (discoverable taxonomy set) information and logic in the Excel application which takes advantage of the financial reporting logical model.

This works even better than I had anticipated. I always thought the rendering would be 98% of what one might want, the user would have to do 2% of the work to adjust the slicers, rows, and columns.  But, I was able to get 100% of what I wanted automatically.  The roll forward is not quite what I desire but I know how to fix that without too much effort.

Don't be fooled by what might appear as the simplicity of what you see.  This is not a simplistic implementation of XBRL. In fact, it is quite robust. The US GAAP Taxonomy and SEC XBRL reporting can follow this model. The model is simple, not simplistic.  That is the idea: make it simple and easy to use.

I am getting more and more evidence and insight into what an XBRL application for financial reporting can and should look like. I am seeing that it is very possible to hide XBRL in the background.

The XBRL International Taxonomy Architecture Working Group is looking for software vendors to experiment with the financial reporting logical model.  If you are interested, send me an email or contact XBRL International for more information.  This is a great opportunity to not only experiment and learn more about XBRL.

I added an additional data set to the State Fact Book prototype I am creating. That data set, which is Set-08, has population trends for the US states and the District of Columbia between 2000 and 2009.

Here is a walk through of how this was done. Hopefully this will give you an appreciation for some of the things XBRL (and other XML syntaxes) can provide. If you take the time to walk through this, you might be able to see some value which XBRL brings to the table.

I am using data from this US Census web site which provides population estimate information. I am using the "National population dataset".  That data set is explained by this PDF file (File Layout).  This is the actual data file (CSV File).

The first thing to note is that the information which describes the data (i.e. the PDF file) is not reference by or connected to the data itself.  When people say XML is "self describing", part of what that means is that the XML both contains the data and describes the data.  XBRL does this also.  The XBRL instance is the data, the XBRL taxonomy describes the data.

Another think to notice about the data is that it is "flat".  CSV shows rows and columns.  You cannot really model complex relations.  If you wanted to relate this data file to another data file, you can do it, but there is no way to validate that you got the relations correct, unless you build tools to check the relations between two different CSV files.  XML and XBRL can connect the data and the information which describes the data (which is referred to as metadata).

I grabbed the CSV, got it into Microsoft Excel which is very easy, then got the Excel into Microsoft Access, again very easy.  I put the information into Access because Access is vastly easier to use to do some things I need to do.  What, Access easier than Excel?  Yes, I need the relational database functionality of Access.  You can do this in Excel, but again, you have to build your own relations.  Why do that when Access can do it for you better.

I used Access to generate XHTML, XML, and XBRLversions of this data. Now, all these formats are "XML".  They are just different syntaxes of XML.  The each has semantics expressed, but each expresses the semantics in different ways, sometimes explicitly, sometimes implicitly.

One piece of the semantics which is not explicitly expressed in the CSV or XML or HTML is that the numbers are supposed to add up.  Each state plus the District of Columbia adds up to the total US population.  XBRL can express this.  In this case, the population trends XBRL taxonomy information which consists of two things, a definition linkbase and a formula linkbase expresses this information. Those two pieces, combined with the general XBRL taxonomies used by the state fact book information gives me this report when run through an XBRL processor which supports XBRL formula.  This report shows that the information adds up correctly.  You can run the XBRL through any XBRL application and you will get the same results because XBRL, a global standard, specifies the rules of how XBRL works, and different software vendors implement those rules.

Validating that the numbers add up does two things as explained in this blog post.  First, it documents what should add up.  Second, it proves that it does add up.  A lot of people first don't realize how big a deal this is.  They think, "Well, I do validation in my application to check to see if things add up."  You have to build that validation and you cannot exchange it with anyone else, because it is proprietary.  With XBRL the validation rules can be exchanged and they are rules engine based and can be used many times, not just once in your system.

A final point I want to make is that the population trends information, the general information, and the financial information can all easily be hooked together.  Those three data sets use the same base metadata which is expressed in the XBRL taxonomy each uses.  Grab the XBRL from the index page (the blue image which says "XBRL" on it).  Try the following:

• Hook the financial information and population information together.
• Separate the population information by "red", "blue" and "purple" state.
• Create your own data set and connect it to one of the data sets from above.

You can actually do this with XML, XBRL, or RDF.  Each syntax has its pros and cons.  I will be discussing those pros and cons in future blog posts.

I used to think that there were two models for extension of XBRL taxonomies for reporting using XBRL: static and dynamic.  Now I think there are at least three. Let me summarize the three XBRL taxonomy extension models one might make use of for reporting:

• Static: By static I mean that the extension of your XBRL taxonomy is not allowed at all. This reporting model is what amounts to a form.  Tax forms is one example.  Basically the user fills in all the boxes on the form.  This type of reporting is easy to implement in XBRL as you don't have users making modifications to the XBRL taxonomy so users there is less for them to learn.  Also, because the report is a form software applications are easier to build.
• Dynamic: By dynamic I mean that extension of your XBRL taxonomy is allowed.  This reporting model is more like SEC reporting by public companies.  Users can extend existing relations and concepts or add entirely new relations and concepts.  What users add in terms of an extension needs to be consistent with the XBRL taxonomy they are extending.
• Leaf level extension: I don't quite know what to call this yet, so for now I will call it "leaf level extension". What I mean by that is rather than giving those that report to you the ability to add new relation structures, they can only add new relations and concepts to existing structures.  Extension is allowed but there is less that the business users need to understand about XBRL taxonomies.  Users are not allowed to add new structures, only add things to existing structures.  What can be added can be more easily controlled by software as the existing XBRL taxonomy serves as a guide to adding the new leaf relations and concepts.

I am not making any judgements here about which XBRL extension model one should use in any specific case, this is more about pointing out the spectrum of options which you have. I can see scenarios where say a regulator did not allow extension within their reporting model (i.e. static reporting, a form) but really would like to allow business users to do some extension as it would improve the reporting scheme or system.  Allowing leaf level extension provides some additional flexibility, but not increasing complexity to the degree that complete dynamic reporting would entail.

And it is not that these three models need to be used in isolation.  For example, if you look at say SEC XBRL reporting using the US GAAP taxonomy, there are areas of the XBRL taxonomy which you would want to work like a form (i.e. the user cannot change those areas at all), there are some areas where you want the users to be able to add leafs to existing relations and concepts and finally there are certain occasions where the user will need to add entirely new relations and concepts, providing complete flexibility to the business user.

It is up to the business domain to determine the needs of their reporting scheme.  Just realize that you have options and that each option brings a basket of characteristics to the table.  You have to mix and match what you need with how you implement XBRL taxonomies within your system.