Digital Financial Reporting

I have been struggling and struggling trying to figure out the best way to communicate some things I have been trying to communicate and have settled on a number of model SEC XBRL filings to articulate the message.  You can find the first model SEC XBRL filing here. (If the site is slow, check back; the hosting people are doing an upgrade or something and the site has been slow.)

The key thing that I am trying to achieve is to show CPAs how to correctly model an SEC XBRL filing from an information model integrity perspective. The message is that:

• the balance sheet, income statement, cash flow statement, statement of changes in equity are tightly intertwined
• the policies and disclosures provided details which sometimes are stand alone, but sometimes are details of the aggregated summaries on those primary financials
• properly expressing these relationships from an information modeling perspective allows for features such as "drill down" and moving from one area of the statement to another area
• paper-based and document centric notions such as "presented on the face of the financials" get in the way of getting the most from XBRL

We are rapidly moving from the two dimensional medium of paper and electronic paper to a more feature rich model which leverages things like the multidimensional model. I have heard a few people use the term "model driven reporting".

What I am trying to do is point to specific issues in order to highlight the issues so CPAs and others in the financial reporting supply chain can figure out the best way to apply XBRL to financial reporting.  How XBRL is used is a choice. Information about the possibilities helps get to the appropriate answers, all things considered.

So, I am creating a series of model SEC XBRL financial filings to point out some things. I am starting with a "semi well modelled XBRL SEC filing" to make some specific points.  That is the model above.

This PDF file describes the model SEC XBRL filing.  It provides a narrative which shows how things are tied together and certain choices which must be made by SEC XBRL filing creators.  I submitted the model to the SEC Previewer which shows the resulting renderings.

You can make your own way through the model, here are some suggestions on getting the most of the model and the key points I want to articulate:

• The financials are intertwined.  This XBRL formulas validation report results shows how interrelated. You can go look at the XBRL formulas themselves, but they can be hard to read without a good application.
• Look at the financial as the interrelated fact tablesthat they are. The meta data of one fact table needs to correctly relate to other fact tables in order for the validation report to show no errors.  Every SEC XBRL filing needs to be properly articulated for the information in the filing to be useful.
• Properly articulated information results in properly rendered SEC XBRL filings. Walk through this Excel spreadsheet to see how a fact table is turned into a human readable rendering.
• These relations will be much easier to see when good software exists for viewing and comparing SEC XBRL filings.  By looking at these details you can see the impact.  If you are not comfortable at the detail level of XBRL, try and use the Firefox XBRL viewer addon to read the XBRL instance. It does not render the model very well, but it does show you some of the drill down capabilities and how a financial report will be more dynamic in the future.
• Go grab the ZIP file (line "I") from the model's home page and run it through the SEC previewer yourself.  Edit the XBRL taxonomy and XBRL instance and see how the SEC previewer rendering changes. Notice how the rendering is better if you have many small pieces rather then fewer larger pieces.

(Note that this model consciously points to some label linkbases where others should be used for an actual SEC filing.  I have to do this due to the taxonomy editing software I am using.  That causes one EFM validation error, I realize that. The final version will have that adjusted to use the proper label linkbase files.)

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.

Since about June 2010 I have been fiddling with, testing, tweaking and otherwise experimenting with a set of about 53 XBRL instances and XBRL taxonomies. The purpose of the experimentation was to figure out the best approach to using XBRL. As a result of this experimentation, I have reached a number of conclusions about using XBRL. They are summarized below.

This is the set of 53 XBRL instances organized within an RSS feed. Why the RSS feed? Because it provides both a quick way to access the XBRL instances and the related taxonomies manually and using a software application. You can find documentation for this set of XBRL instances and XBRL taxonomies here on my Learning about XBRL page of my blog. See the section Samples/Examples; you should be able to reconcile the RSS feed documents and the documentation. I will create easier to follow documentation at some point.

Two goals of the experimentation were to test the Business Reporting Logical Model / Financial Reporting Logical Model and figure out the best approach to creating SEC XBRL filings.

Conclusions

This is a summary of the conclusions which I have reached:

• XBRL has a logical semantic model. While that model is not well communicated or explicitly communicated, if you dig deeply enough, it is there. What makes it so confusing to see are the many different XBRL syntax options. If you look at the Fact Group and Measure Relations Info sets provided with the examples, you can see the logical semantic model.
• Inconsistency within an XBRL taxonomy causes confusion. If you create an XBRL taxonomy and the definition linkbase, presentation linkbase, and calculation linkbase are inconsistent; then you cannot expect a software application to correctly interpret the XBRL instance information. Said another way, consistent XBRL taxonomies enable clear XBRL instance information.
• Good semantic models can be reconciled to one another; bad semantic models cannot. Even if software vendors don't implement precisely the same semantic model within their software, if the models are good models you will be able to reconcile the models to one another.
• The Business Reporting Logical Model can be helpful in creating a consistent XBRL taxonomy and XBRL instances; but it is not required.  As I started this journey I had been told that there is a logical semantic model buried within XBRL but did not believe it. Now I do believe it. I thought that you needed to have something like the Business Reporting Logical Model to create a good taxonomy.  But that was a mistake.  It helps, but as long as you end up with a good XBRL taxonomy; you don't necessarily have a documented model. I don't think COREP and FINREP have a documented model, other than a good XBRL logical model.
• Consistent extensions lead to usable XBRL instances. There is no difference between a base XBRL taxonomy and an extension XBRL taxonomy. A taxonomy is a taxonomy. Inconsistency between a base and an extension causes precisely the same problems as inconsistencies within an XBRL taxonomy.
• Throwing away pieces of XBRL is not the solution to the inconsistency issues. I had erroneously thought that the path to XBRL nirvana was to get rid of typed members, tuples, custom segments and scenarios.  That is unnecessary.  Each of the different pieces provides a needed feature. If you understand what the different pieces of XBRL syntax provide and use them correctly and consistently things will work out fine.  That said, most people don't need every feature. The only thing I would get rid of in XBRL is the precision attribute, using only the decimals attribute on an XBRL instance fact.

The bottom line: be consistent and clear when you create an XBRL taxonomy. Work at the logical semantic level, not the syntax level. While agreeing on the logical semantic model makes cross XBRL taxonomy interoperability vastly more efficient; as long as you are consistent and clear in your XBRL taxonomy, then XBRL will work for you within your system.  Something like the Business Reporting Logical Model can help you achieve the needed consistency, it is not required and can be achieved using other means.

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?

I started my career the summer that my office of Price Waterhouse, as the international public accountancy firm was called back in 1982, received its first IBM personal computer. Quite a lot has changed since then.  We used these huge paper spreadsheets for audits which provided me with lots of motivation to learn first Visicalc (the first electronic spreadsheet I had seen) and then Lotus 1-2-3. The benefits of electronic spreadsheets were pretty clear to me and I used them, other accountants took years to make the shift. So it goes.

If you are looking at the SEC XBRL filings that you have to create as a nusiance that the government regulators has thrust upon you, you are missing a trend which has been picking up steam.

Between 1982 and about 1998 what I did for work amounted to applying technologies to the financial reporting process to make those processes easier.  My technologies were Excel, Access, the Internet when that became available and in 1998 a thing called XML.  My understanding of XML led to XBRL. The SEC and others thought this was a good idea, the SEC mandated it, and now people bolt on another step to their processes to generate the XBRL so they can give it to the SEC.

My techniques worked in the 1980s and 1990s, but today there are more robust solutions and the problems and their solutions have been given names:

• Business Intelligence
• Performance Management
• B2B Automation
• Business Process Automation
• Enterprise Information Management
• Enterprise Search
• Customer Facing Buiness Intelligence

There are lots of other terms, that is only some of them.  These terms can be hard to get your head around, but Information Builders, a vendor of such solutions, has provided a nice summary of 2 minute videos which explains both the problems and their solutions to the problems.

Information Builders is a partner of the company I work with, UBmatrix. We have other partners, three other stand outs are Oracle, IBM, and SAP.

My point here is that the bolt on processes used today are a short-term solution in the evolution to the longer term solution to not only SEC XBRL filings, but to financial reporting and business reporting in general.  If you are a CPA, this is a great opportunity to figure out what financial reporting is going to look like five to ten years from now.  And I am not talking about just public companies reporting to the SEC, I am talking about financial reporting in general.

Watch the videos I mentioned above. Consider the pain points the videos show. Think about whether you have any of these pain points.  I specualte that you probably do.  Everyone does pretty much.

See SEC XBRL filings as something you may want to consider paying attention to whether you are an SEC filer or not.  There is much to be learned from those SEC XBRL filings should one look.