Digital Financial Reporting

Most processes used to generate SEC XBRL financial filings are additional processes which are bolted on to an existing financial reporting process and don't consider the entire financial reporting life cycle. Therefore, those using such processes to generate their SEC XBRL financial filings don't see much value from XBRL; or rather, accountants and auditors involved in these processes see XBRL as more of a nuance than as something of value.

Part of the reason the value of XBRL is hard to see is that currently there are few software solutions or products which leverage the benefits enabled by XBRL and therefore the financial reporting life cycle is held together using expensive human resources.

As such, many of the benefits offered by XBRL are seen as burdens or obstacles which must be overcome. Consider validation of information within an SEC XBRL filing as an example. Many of those creating SEC XBRL financial filings see things like the XBRL US consistency checks and other XBRL validation services as unnecessary obstacles which simply cause them additional work. Nothing could be further from the truth.

The reason things like the XBRL US consistency checks and other XBRL based validation services are not valued is because the SEC submission process does not consider these sorts of business rules. Two things to keep in the back of your mind about this: (1) it is US GAAP and other reporting rules which specify these validation constraints, not SEC XBRL submission and (2) eventually the SEC will specify such validation rules, I predict.

Consider a very simple example to make my point.  Clearly in a financial report the number of common shares outstanding needs to be greater than the number of common shares authorized. The same is true for issued shares.  Accountants and auditors are used to checking to be sure that within a financial report the authorized shares are greater than the outstanding and issued shares by looking at the printed financial report.

But because XBRL articulates information in a manner that a computer can read these three pieces of information (authorized, issued, outstanding shares) and compare them; the computer can take over this mundane validation process. It is trivial for a computer to verify this information and a computer will never get tired or otherwise make a mistake.

There are literally thousands of such business rules.  I heard that the COREP taxonomy which is used for bank solvency and liquidity reporting has 36,000 business rules.  FINREP which is used for bank financial reporting has 7,500. The FDIC taxonomy has a less impressive number of rules, between 1,800 to 3,500 business rules (I have heard both numbers).

How many business rules does the US GAAP Taxonomy provide? Zero.  Really, zero.  Does that mean that US GAAP has fewer rules?  Certainly not. It simply means that the FASB has yet to provide those rules in a form that XBRL software can use. Those familiar with US GAAP and the power of XBRL Formula for expressing those rules realize the potential. Does the fact that they don't exist today mean that you don't need to create correct SEC XBRL financial filings?

You might look at it this way if your only objective is to get your SEC XBRL financial filing submitted.  However, if you want to maximize the quality of your financial reports and minimize their cost; these business rules can help automate many aspects of your financial reporting life cycle.

Some organizations are creating in-house systems or custom solutions to easily enable the use of business rules within their processes. Eventually, this type of functionality will exist within off the shelf products.

If you really think about it and consider the characteristics of a quality financial statement, it is rather easy to make the case for using XBRL and leveraging its benefits whether you need to report in an XBRL format to some regulator or not.

It is with these enablers offered by XBRL that the last mile of finance is being repaved.

In past blog posts I have discussed the characteristics of a quality SEC XBRL financial filing and how to achieve that quality effectively and efficiently by focusing on meaning rather than the XBRL syntax.

In this blog post I want to tune those target characteristics from what I have learned from my analysis of 5525 SEC XBRL filings.

Keeping the end goal in mind is the best perspective to evaluate what you need from an SEC XBRL financial filing to consider it a quality product:

• All formats convey the same message/meaning: Financial reports are submitted to the SEC in both HTML and XBRL formats. Both formats have the same information and both formats should obviously communicate the same message. While the format may change, the meaning of the information must not change.
• Integrity: A financial statement rendered on paper foots, cross casts, and otherwise "ticks and ties".  The same will be true of an SEC XBRL financial filing. An interesting aspect of an SEC XBRL financial filings is that because of its structured nature, computer software can help the process of making sure everything "ticks and ties". This type of automated quality checking is impossible with an unstructured format such as PDF or HTML as computer software cannot read these formats and derive understand of what it is looking at.  Further, while each component of your financial report must "tick and tie", it is also the case that each of the components need to properly fit together correctly.
• Rendering: One benefit of SEC XBRL financial filings is that many different software applications can read that standard format.  As such, you will want each software application presenting that information to users of the information in a consistent form.  If certain applications unintentionally render information inconsistently, information may be obfuscated in some way and your information may be misinterpreted. Most users of SEC XBRL financial information are unlikely to be using the SEC XBRL interactive data viewer.  If users want to read the information they will simply use the HTML version.
• Justifiable extension concepts: Extension concepts and other metadata added to an SEC XBRL financial filing should be justifiable. You determine the uniqueness of your company, which needs to be balanced with using standard metadata appropriately. Core financial integrity should be intact and sets a foundation upon which you build.
• Consistency with peer group: Extension concepts and other metadata added to an SEC XBRL financial filing should be as similar to your peer groups as you desire. Again, you determine the uniqueness of your company, which needs to be balanced with using standard metadata provided appropriately.
• Consistency between periods: Likewise, your SEC XBRL financial filing should be consistent between periods. Changes will obviously occur within your SEC XBRL filing between periods. But something reported in one filing period would generally be the same in the next filing period.
• Clear business meaning: The business meaning of your SEC XBRL financial filing should be clear to you and clear to users of your financial information, preferably interpreting that meaning in the same way that you as its creator intended.  The more explicit you are in creating the information, the less users of that information will need to imply.  So, always be explicit where you can.  Another way to say this is that it is far better to be explicit than to leave readers to imply meaning which they may imply incorrectly.
• Usable for analysis: The bottom line is how usable is your SEC XBRL financial information for analysis. If it is useful, then you most likely did a good job in creating your SEC XBRL financial filing.

Quality may not be a high priority now, but as the legal liability exemption terminates, more and more filers will focus on quality. Thinking even further down the road, there is a high probability that the SEC will end up requiring only those XBRL filings, the HTML will go away. Now, software will need to improve significantly to make this happen, but it will happen eventually.  Then, the XBRL will be the only format.

Now is the time to zero in on quality.

If you have been following my blog you will recall that I did an analysis of 5525 SEC XBRL financial filings. As a result of that analysis, I recognized that a high percentage of SEC XBRL filers all have the same core financial integrity. I both predicted this because clearly US GAAP has these financial reporting semantics and was pleased to see that a high percentage of filers followed these core financial reporting rules.

I took the queries I was using and put them into an Excel spreadsheet application which I built, put in pointers to SEC XBRL financial filings, and now you can (a) look at the financial integrity of these SEC XBRL financial flings for yourself and (b) look at the code to see how this information was derived.

You can get this working prototype financial integrity analyzer tool here.

The financial integrity report looks like this:

Clearly this is only a subset of information and only for the consolidated entity.  But, if this information is not correct, what is the chance of the rest of the information which details this information is correct?  So, this core financial information provides insight as to the semantic integrity of of the overall filing.

Again, keep in mind that this is a prototype, but it does work in most cases.  This is not totally perfected and I actually left a lot of the rougher stuff out.  If you reverse engineer the code you will realize that I am not even using an XBRL processor to grab this information.  Look at the algorithm closely and you can see how it works.

Also, recognize that you can look at any of the groups of filings I have provided (the Dow, the 10-Ks, the top 100 filers, top 1000, or the complete list of 5525 filings).  You could modify the code to look at any SEC filing; past, present, or future; and this application should work for you.

Accountants and auditors will soon recognize that working at the XBRL syntax level to create or verify SEC XBRL financial filings is not the right approach, the semantics is where all the action is.  Hopefully this working prototype will help them realize this sooner.

Here is a screen shot of the form in the prototype which lets you pick the SEC XBRL filing that you want to look at:

I created a handy little tool which can be used to grab taxonomy information.  You can download the tool here. This is an Excel spreadsheet which has some macros.

The tool connects together lots of different sets of taxonomies which it will then load into either a tree view so you can look at the taxonomy or you can load the taxonomy information into the Excel spreadsheet.

These are the lists of taxonomies which the application points to:

• US GAAP Taxonomy "Master" (i.e. as modeled and released by the FASB, 56 commonly used networks)
• US GAAP Taxonomy "Optimized" (i.e. reorganized into a more logical form which is easier to use, total of 58 networks)
• Taxonomies of the 30 companies which make up the Dow Industrials
• Taxonomies of the top 100 SEC filers by total assets
• Taxonomies of the top 1000 SEC filers by total assets
• Taxonomies for all 10-Ks filed by the top 1000 companies (about 63 filings)
• Taxonomies for 9 "exemplars" (examples) for different forms of a balance sheet, income statement, and cash flow statement

This is just experimentation. The primary point I am trying to make is why have only one list of taxonomies when you could have many, many different lists which serve different purposes.

This application can be reverse engineered and modified to your heart's content. If you do fiddle with it and you create some interesting modified version of this, please send me a copy so I can check out your handy work.

Here is some pretty basic information helpful in understanding how to compare SEC XBRL financial filings. This exercise also helps you see how constructing a taxonomy makes things easier, or harder, to compare.

Consider this list of the 30 Dow Industrial Companies. You could look through those filings one by one, reviewing the "Document Information" section for each of the 30 companies.  But what I did was put all the document information sections for all 30 companies into one single file, which you can see here.

I will assume that you  have some list of companies which you might want to compare.  So lets start at the level of the section that you want to compare.  Here we will focus on the "Document Information" section because it is simple, it is actually rather easy to compare, but it does point out the issues.

The first thing you will need to do is determine what level you want to do a comparison.  Do you want to compare networks, tables, concepts, or some other "level"?  I don't want to get into a discussion about levels right now, so let us just assume that we want to compare networks.  So no problem, we just go get the network name of the section we want to compare.  Right?

Well, not so fast.  If you scan throught the list you will notice that every company created a unique network for its document information section.  They did this because SEC filing rules tell them that they need to do this.  It could have been the case that one specific network URI was used to identify document information for everyone such as the URI used by the DEI taxonomy which is (you can see it in the DEI presentation linkbase here):

http://xbrl.sec.gov/dei/role/document/DocumentInformation

But one unique document information network was not used, so you have to try something else.

OK, so try something else.  The SEC requires that the document information be marked with the category "Document" (as compared to "Statement" and "Disclosure").  Well, that won't work either as Travelers (number 26) used the category "Statement" category, as opposed to "Document".

But the good news is that every one of the 30 DOW Industrials used the term "Document and Entity Information".  So, we can use that, as I did, to identify the document information section.  Will that same technique work for all SEC XBRL filings?  I doubt it, may need to adjust the algorithm.

The next thing you will note is that of the 30 companies, every one extended the root node, there is no "dei:DocumentInformationAbstract" concept, every filer created their own extension concept.  One, again Travelers, did an utterly strange thing.  They used a [Domain] (dei:EntityDomain) as the root of that section. That clearly should not be allowed.

Next you will note that of the 30 companies, 6 companies used [Table]s and 24 companies did not use [Table]s.  Of the 6which did use [Table]s; all used the "Legal Entity [Axis]" and the "Entity [Domain]" to indicate that the information of the document information relates to the consolidated entity as opposed to a parent holding company.  As such, SEC EFM rules kick in and you need to imply that the other 24 are consolidated entities, rather than parent holding companies.

If you scan through the concept names you will see that no filer created extension concepts.  (This does not include that root abstract element which would never report information, it is only there to help organize the section.  So while each filer reported different concepts, this information is quite easy to compare.

There are no real relations between the concepts other than the information is document or entity information.  As such, there are no business rules we need to make sure are valid.

This same general approach can be utilized for comparing any information in SEC XBRL financial filings:

1. Get your list (in this case, my list was the 30 Dow Industrials companies)
2. Decide what section you want to compare (in my case I chose the document information network)
3. Resolve the differences between the structure of information (if there is not an explicit [Table], there is an implied table with the legal entity [Axis] which has the value of dei:EntityDomain or consolidated entity)
4. Compare concepts (in our case this was easy as there were no extension concepts)
5. Compare business rules (in our case there were no business rules to deal with as there were no computation type relations)

Easy enough steps, harder to apply because of inconsistencies in SEC XBRL financial filings, but quite doable.  To make this easier, reduce the inconsistencies in the system.