Digital Financial Reporting

Well, first of; this really is not a dilemma.  It is a misperception, a trap that many people fall into. The bottom line of what I am trying to show with this blog post is this: If you create an accurate data model, then rendering (any rendering format) is not that challenging.  But if you create a poor data model based on presentation, you go down a non-scalable, ever ending slipperly slope.

Let me explain. But first, let me stay that the seemingly never ending argument about whether to use a document centric approach to modeling a taxonomy or a data centric approach to modeling a taxonomy will end when good software exists which shows that if you have an accurate data model than any presentation is possible. Further, once people see what you can get from a computer application in terms of viewing financial information they will ditch their two dimensional paper centric view of the world.

I feel as though I have created example after example to make this point. I have created yet another example specific to SEC XBRL filings and the US GAAP taxonomy.  It shows the issues better, but it is still to hard for people who don't have a skill for reading XBRL syntax well to see. But it is better.  I am using the SEC XBRL renderings to help make the points I want accountants to see.

To make my point, first look at the statement of financial condition, classified, commercial and industrial companies from the US GAAP Taxonomy.  I have provided an HTML rendering of that network here. If you look closely within the equity section which starts at line 419you will see that the facts which show up as line items on the balance sheet are intermingled with the information relating to classes of common stock, preferred stock, and treasury shares which is typically disclosed within the labels of the line items. In particular look at line 450 through 480.  There are other issues, but lets focus on the common stock and preferred stock information.

The first step toward seeing the issue is to remodel the balance sheet correctly.  I did this in my XBRL Trends and Techniques prototype. Specifically, go to my remodeled balance sheet template. You can see my remodeled template for the balance sheet here. In you scroll down to about line 439 you can see that I separated the balance sheet line items and the class of stock information relating to common stock, preferred stock, and treasury shares.  (I also removed the partnership line items from this template because no company is both a partnership and a corporation and most (all) of the SEC filers I am working on are corporations. I also fixed the [Axis].)

The key concepts to look at are these three concepts: Common Stock, Value, Issued (Line 412 and 450); Preferred Stock, Value, Issued (Line 410 and 473); and Treasury Stock, Value (Line 420 and 495).

The reason those three concepts are so important is because they are the intersection between the balance sheet line items and the class of stock breakdowns.  You can see this clearly in the validation results for the business rules for the XBRL instance. The business rules make sure the total amounts for the classes of stock add up to the balance sheet.

This is where the dilemma comes up. Under US GAAP financial reporting, few (and maybe no) companies show the total dollar amount for all classes of common stock or preferred stock on their balance sheets.  They show the amounts for each class of stock as the line items.

Now, that is no big deal to model and make render correctly.  You simply create a concept "Common Stock, Value, Issued, Class A" and "Common Stock, Value, Issued, Class B". Then the balance sheet will add up correctly and the rendering will look as one desires.  But if you do that, then you will have to create duplicate concepts for the "Common Stock, Value, Issued" which breaks out the detailed information for the class which you do have to provide.  So this is really not a dilemma, you can do it.

But the problem is those duplicate concepts.  Duplicate anything causes problems for computers and potential for error.

In the long run, I suspect (hope) that accountants will realize two things.  First, the right way to model this information is based on the characteristics of the information, not how that information is presented.  Second, if the information is modeled correctly, it is very possible to create a rendering engine which has a rather simple algorithm to show not the total concepts for common and preferred stock, but rather the values for each class.  There are only a few components of equity which would ever need adjusting in this way.

The bigger issue is that there are other balance sheet line items which act this way. If some concept is important it needs to be "presented on the face of the financial statements".  But an XBRL instance has no face.  And, XBRL allows you to use a computer applcation to move detailed information and summary information together, drilling down (or up) to move from summary to detail or detail to summary. Basically, "presented on the face of the financial statements" is an obsolete notion in our digital world.

But today, "presented on the face..." is the law.  It has to be dealt with. You can do this by creating an accurate data model which models the reality of the underlying data.  You may need to create some duplicate concepts to do this for now and a few business rules to ensure that the duplicated items are correctly in sync.  But modeling the information only for presentation, disregarding the reality of the information and the reality that computer systems are going to have to read and use this information and provide it to analysts is not an appropriate solution.

There are many areas where you have detailed and summary information in the US GAAP Taxonomy and SEC XBRL filings. Understanding how this works is the first step to properly modeling this information. Good tools which allow accountants to see the impact of their modeling decisions will move us a long way to understanding and solving this issue.