Digital Financial Reporting

For almost a year I was poking and prodding SEC XBRL financial filings at the primary financial statement level mostly in order to understand those SEC filings.

I am not using the techniques which I have perfected to dive into the disclosures.  Many people think that the disclosures are more complicated than the primary financial statements.  Personally, I don't think that is true.  There is more variety in the disclosures. There are a larger number of disclosures than primary financial statements.  But if you understand Digital Financial Reporting Principles; those same principles apply to the primary financial statements and to the disclosures.

Let me walk you through one disclosure. I will take something which is rather straight forward and a large number of SEC filers have. One of the first things to understand about the disclosures (if you are not an accountant, accountants know this) is that most disclosures are provided if you only have specific types of transactions, events, or other circumstances.

This disclosure relates to share based payment awards of equity instruments other than options, restricted stock, and stock units to share-based compensation arrangements. This is a very specific disclosure.  The terms (jargon) are very precise and important.  The simple explanation is that the disclosure is about stock options.  I will provide an overview of 5 different representation approaches used.  Don't focus on the accounting here though. 

Approach 1: This is not bad.  Notice how readable and understandable this is.  The units and values are shown separately.

Click for larger image

Approach 2: This approach is not bad either, but I think the first approach is better because of the headings provided.

Click for larger image

Approach 3: This approach is less desirable in my view because it mixes the units and values (i.e. weighted average price) together.  This is hard to read.

Click for larger image

Approach 4: This is somewhat of a disaster in my view.  Can you read this?  I cannot.

Click for larger image

Approach 5: I like this approach which is similar to approach 1 in that it has the headings which break up the information; this also adds the "[Roll Forward]" to the label which helps a reader of the information that it is a reconciliation between two periods.  But this has a problem.  The second roll forward is not really a roll forward.  It is information about the balances within the roll forward, but in actually the second "[Roll Forward]" does not really roll forward.  Get out your calculators and check it out.

Click for larger image

My vote for the best approach?  #1 is the best.  That could have been improved by adding the "[Roll Forward]" to indicate that it was in fact a roll forward. But, you can tell because of the beginning and ending balances. 

A question you may have is how do I discover all this stuff?  The answer: software.  All this information is structured.  I am not using XBRL to grab this information, at least not directly. Sure, if the information was not structured (in this case in XBRL) this sort of analysis would not be possible.  But, the information is structured.  So, I can write software to do magical sorts of things.

Here is the interface of the application I created:

Click for larger image

I can extract information for any of 1000 disclosures. How? Well, I mapped the each disclosure to the US GAAP XBRL Taxonomy (actually a remodel version of that).  I then use prototye theory to figure out where the disclosure I am looking for is.

Once I locate the pieces that have the disclosures, I use the XBRL Cloud Edgar Report Information web service to provide the renderings.  In my application it looks like this:

Click for larger image

So that is how I get at all this disclosure information.

This is starting to get really useful.  The information structured in XBRL is helpful in understanding the HTML financial reports.  The HTML and the XBRL must be consistent per SEC filing rules. Researching financial reports is a snap leveraging the information structured using XBRL.

More and more people seem to be understanding the potential of software agentssuch as what the media has dubbed the SEC's "RoboCop". For example, "Robocop" on the Beat: What the SEC's New Financial Reporting and AQM Initiative May Mean for Public Companiesexplains what RobCop is and offers the following prudent advice for staying off of RoboCop's radar:

• Get your XBRL reporting right the first time. There are many reports that public companies are continuing to make numerous XBRL coding mistakes. It is likely the AQM will not be able to identify an innocent coding mistake. Such mistakes, however, may land a company on the top of SEC's "Needs Further Review" list. Though the audit firms have apparently steered away from giving advice on XBLR, there are numerous experts and boutique firms that can help provide guidance to registrants. Making errors in this area, even if innocent, is simply not an option in this new era.
• Consider all of your financial disclosures. The AQM focuses on identifying outliers. One easy way to become an outlier is to be opaque with disclosures where other companies are transparent. Take a fresh look at your financial disclosures for transparency and comparability across your industry.
• Listen to the SEC's guidance. As we have noted above there are a number of new SEC programs and initiatives focused on detecting financial reporting irregularities. Stay current on SEC activity to avoid surprises.
• It is not just the SEC. XBRL is available to the public. As a greater library of XBRL financial statement data is created, analysts, investors, other government agencies, media outlets and others will build their own versions of the AQM. Be prepared for greater scrutiny and inquiries from these groups.
• Be conscious of red flags. For example, a change in auditor is thought to be a significant red flag that might warrant further attention from the SEC.

Sure, I think those five key points are very good advice. But don't miss the real message here: business opportunity.

Ask yourself, how will RoboCop and other similar software agents work?  What makes them work? There are two key things that I am trying to get people to see here.

1. Software: Sure, software algorithms make these software agents work.  So yes, you need software. It is not the type of software which most business users are generally accustom to such as, say, Excel.  Excel is actually pretty dumb in terms of understanding the information that is represented in Excel. What I am talking about is software which DOES understand the information it is working with.
2. Metadata: If you have the right type of software but you don't have the metadata you need that software will not be able to do much.  If you articulate knowledge in books or even web pages that computers cannot read and therefore they cannot possibly understand; then you don't get much either.  However, if you properly connect the right metadata or domain knowledge with the right software applications then "magic" will occur.  It is not really magic, it will just seem like magic to those using the software.

Only domain experts can create the correct metadata.  Only domain experts understand what the correct metadata is.  Until one understands what the correct metadata is, the correct software cannot be built.  Now, there are some general tools out there which generally solve problems but because these are general tools they are extremely hard to use.  In other words, they are not practical.

The business opportunity is to put these two pieces together correctly: software and metadata.  It will take both technical professionals and business professionals working on this together to build the correct software.  Once the software exists, then business professionals will construct and configure metadata to make the software act the way they want.  THAT is what will drive software agents such as RoboCop.  Metadata created by business users.

Most business users don't understand what metadata is though.  Nor do they understand why it is important.  But it is.  Understanding what metadata will drive software such as RoboCop and how that software works is a business opportunity.  Understanding RoboCop and creating counter measures to make sure a companies report stays off the RoboCop radar is also a business opportunity.

If you think about the digital financial reporting paradigm and are bound too strongly to the current paper-based financial reporting paradigm, you won't understand this.

Paradigm shift.

Take a good look at that bullet list from the blog post referenced in the first paragraph.  That is a good starting point.  Take a look at this blog post related to detecting accounting anomalies. This is not about XBRL errors, this is about accounting anomalies.  The structured nature of the information enables the paradigm shift.

While financial reporting may be leading other business domains, this paradigm shift is not limited to financial reporting.

Of the 1262 SEC XBRL financial filings in my set of 7160 SEC filings who report equity attributable to noncontrolling interest on their balance sheet, 1226 (or 97%) use the following US GAAP XBRL Taxonomy concepts to report:

• Equity attributle to parent: us-gaap:StockholdersEquity
• Equity attributle to noncontrolling interest: us-gaap:MinorityInterest
• Total equity: us-gaap:StockholdersEquityIncludingPortionAttributableToNoncontrollingInterest

That is like this SEC filer does and as can be seen in the screen shots below:

Equity attributable to parent:

Total equity:

On the other hand, 36 (or 3%) SEC XBRL financial filings do exactly the opposite and use the following concepts:

• Equity attributle to parent: us-gaap:StockholdersEquityIncludingPortionAttributable ToNoncontrollingInterest
• Equity attributle to noncontrolling interest: us-gaap:MinorityInterest
• Total equity: us-gaap:StockholdersEquity

Here is an example of using that approach which can be seen in the screen shots below:

Equity attributable to parent:

Total equity:

Now, it does not make sense to me to have both approaches deemed correct. So which approach is correct?  The approach used by the majority? Well, if one reads the 2013 US GAAP XBRL Taxonomy labels and definitions it is pretty clear that the first example shown, the majority, has this correct.

The vast majority of SEC XBRL financial filers get the fiscal period focus, fiscal year focus, document period end date, current balance sheet date, and what the SEC EFM calls the "required context" correct. A handful don't synchronize these correctly.

Take the fiscal year.  First of, of 7160 SEC filers, 6999 (or 97.7%) identify the fiscal period focus as fiscal year correctly using "FY".  But there are 152 who incorrectly using "Q4" or "Q3", "Q2", "CY", and "T2".  Using FY is the only correct option for a 10-K.

In terms of the fiscal year focus, 6987 (or 97.5%) properly syncronize the fiscal year focus and the current balance sheet date.  But there are 173 (or 2.5%) who do not.  Here is an example of an error to help you understand this:

Consider this document information:

Click to go to the SEC interactive viewer for this filing

Here is the balance sheet for the same submission:

Notice how the current balance sheet period "Dec 31, 2011", the Document Period End Date in the document information of "Dec 31, 2011" and the end date of the context for the column with the document period end date in it of "Dec 31, 2011" are all the same.  That is the way that information works in the vast majority of SEC XBRL financial filings.

But look at the fiscal year focus in the document information which has a value of "2012".  Also see that the current fiscal year end date is --12-31 (although it is partially obscured by the red circle).

Clearly something is wrong here.  All the dates would indicate that the fiscal year is 2011 and not the 2012 reported by this filer.

Also consider the Edgar Filer Manual section 6.5.19:

Click for a larger image

If you read that section you can see that you have some other dates to deal with.  While the dei:DocumentPeriodEndDate specifies the current balance sheet date, so does the end date of the context of what the SEC refers to as the "Required Context".  The fact which reports the dei:DocumentPeriodEndDate will have that required context.  The end date of that required context will match (a) the dei:DocumentPeriodEndDate and (b) the current balance sheet date.  This is what that looks like in the form of XML:

If you look close, the end date matches.  Now, of 7160 SEC filings, 7100 (or 99.1%) this does match and for 60 filings it does NOT match.

For the income statement same deal. There were roughly the same number of filings where the income statement dates matched that required context start date and end date.  However, this is a little more complicated to check because developing stage companies report additional periods.  So, I cannot give a precise number.

Getting these dates correct and correctly synchronized is important because it is these dates which are used to identify the correct information from within a filing and for extract information from the SEC XBRL financial filing.