BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.

Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.

Entries from December 1, 2013 - December 7, 2013

Detecting Accounting Anomalies in HTML SEC Submissions by Leveraging XBRL

What I am noticing is that one can detect accounting anomalies in the HTML versions of SEC financial filings by leveraging XBRL.  This document, Detecting Accounting Anomalies Using Structured Information, summarizes a handful of accounting anomalies.  These are not XBRL errors, these are accounting anomalies (some would say errors) in the HTML version of SEC financial filings.

Don't make the mistake of thinking that these are obvious or simplistic flaws or typos.  What this shows is the tip of the iceberg.  These issues are just scratching the surface of the real value which structured information, such as XBRL, provides to accountants creating financial reports.  I am keeping this basic and as uncontroversial as possible to help see what structured information such as XBRL really offers.

Here is a quick summary of the accounting anomalies which I detected in HTML SEC filings by public companies:

  • Balance sheets that don't balance: 41 cases.
  • Improperly created classified balance sheets where current assets is reported, but current liabilities are not clearly indicated: about 185 cases.
  • Equity attributable to parent not reported when a noncontrolling interest is reported: about 120 cases.
  • Noncontrolling interest reported at the temporary equity level rather than within equity: 1 case.
  • Two different approaches to computing net cash flow; one where exchange gains/losses are part of net cash flow, another where they are not: why are their two ways of doing this?  This is odd and some accountants say this is an error.

In addition to these accounting anomalies (and remember, this is just the tip of a much bigger iceberg) the document above points out some things to consider in this age of digital financial reporting.

Analysts using software have to grab this information from the digital financial filing, in the case here we I am grabbing SEC XBRL financial filings from the EDGAR system.  Automated reuse of this information by software should not be a guessing game.  Software should be able to clearly identify and extract fundamental accounting concepts.  If this is not straight forward, different software will provide different answers to exactly the same question.  That cannot be a good thing.

Additionally, there are safe ways to report information, and there are unsafe ways to report information.  Being explicit and unambiguous is a good thing if you want software to use your financial information in with the meaning that you intended when the information was created. Providing key totals rather than forcing software developers to spend time creating sophisticated software programs, and potentially software programs which act in different ways, is not really want is needed to make digital financial reporting work the way it needs to work.

So, how am I gathering all this information?  Well, I build a software application in Microsoft Access which does most of the work, but then I use the XBRL Cloud Edgar Report Information web service to retrieve human readable renderings of the financial information.  Below is a screen shot of the form which filters the reporting entities in the ways that I need:

Click image for a larger view

Here is a YouTube video which shows this digital financial report analysis tool in action. Clearly this won't win any design awards, but it will give you an idea of things to come.

Software vendors, something to think about: If I can detect these errors after the fact, why is it that you cannot detect them during the financial report creation process and keep accountants from making accounting mistakes in the first place?  Note that I did not say XBRL errors.  I said accounting mistakes.  That is the value proposition which will get accountants to value structured information and your products.

Imagine a Big 4 public accounting firm which has a policy that certain transactions, events, or other circumstances should be handled in certain specific ways.  Imagine, for example, that a firm believes that balance sheets do in fact balance or that exchange gains and losses are always part of net cash flow or that noncontrolling interest is always part of equity.  If a firm wanted to do that, they could establish a business rule and enforce that rule.  If there are exceptions to that rule for any client, that fact would stand out.

Each public accounting term might have slightly different interpretations of the accounting rules.  These are not random interpretations and there are not endless interpretations. For example, there are two interpretations as to where exchange gains and losses would be placed.  Not 8 interpretations, only two.  How do I know?  Because 100% of SEC public company filings use one of two different approaches.

Is one approach wrong for where exchange gains and losses is placed the cash flow statement?  Maybe.  Why are two approaches necessary?  Some accountants say one of the approaches are wrong.  Other accountants say that US GAAP can be interpreted to include either approach.  Is that a bug in US GAAP?  Maybe.  The ability to analyze digital financial reports will enable discussions like this to occur because anomalies such as this can easily be discovered.  US GAAP will likely be tuned as a result.

There are thousands and thousands of little issues such as this. Like I said, what I am showing is only the tip of the iceberg.

Looking into Balance Sheet Contents and Extensions

For the 7160 SEC XBRL financial filings I have been analyzing, all 10-Ks, I did an analysis of the line items of different sections of the balance sheet.

First off, let me say that this analysis is not perfect just yet.  For one, I am only able to get to the 91% of filers who provided calculation relations for their Assets and Liabilities and Equity roll ups.  (i.e. 9% did not provide XBRL calculation relations for the roll ups and I am not reading those because I am using the calculation relations to find the children.)

Second, I realized that a better assessment would come from separating the filers who have classified balance sheets from those who do NOT have classified balance sheets.

Given the above, this is what I see:

Click image for larger view

You can get the raw data from this Excel spreadsheet if you desire.

Consider the column "Current Assets".  There were an average of about 5 line items for the category current assets in the set of filings analyzed.  The extension rate for current assets was 4.2%, slightly less than the average extension rate for the overall balance sheet which is 5.3%.

Here are the most commonly occurring current asset line items:

In the Excel workbook above there is a spreadsheet which contains a list of every extension added to current assets for all the filers.  I took that list, I did a search on the term "inventor" (to catch inventory and inventories). I then removed the US GAAP XBRL taxonomy concepts.  What was left were these extensions:

Really. The concept "us-gaap:InventoryNet" is not good enough?

Go grab the Excel spreadsheet, slice and dice it, if you find something interesting please let me know.

Something to note.  So obviously because I am grabbing this information about the line items per balance sheet section, I can clearly identify the components of that section. This is whether the concept is an extension or not.  While I cannot tell you WHAT the extension is without reading the concept documentation; I can get the line item.

As I write this it occurred to me that another interesting bit of information is the number of extensions per balance sheet section.  I sort of have that information.  If, for example, there are an average of 5 current assets line items and the extension rate is 4.2%; then the average filer has .21 extension concepts.  Plus, given the obvious misuse of extensions for the concept inventories above, the extension rate can likely be reduced.

Anyway, have fun looking at the data if you are so inclined.

Posted on Monday, December 2, 2013 at 03:25PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint