Detecting Accounting Anomalies in HTML SEC Submissions by Leveraging XBRL
Friday, December 6, 2013 at 07:53AM
Charlie in Becoming an XBRL Master Craftsman, Creating Investor Friendly SEC XBRL Filings

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:

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.

Article originally appeared on XBRL-based structured digital financial reporting (http://xbrl.squarespace.com/).
See website for complete article licensing information.