Digital Financial Reporting

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.

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.

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.

This Forbes article, XBRL Would Be Wonderful If It Always Worked, is right. For the information to be useful, it has to be 100% correct.  Or close.  My fundamental accounting concept analysis shows an accuracy rate of 97.6%.  The analysis also shows every SEC XBRL financial filing which contributes to an anomaly being detected.  The filers could fix their filings to get this information correct, then the 100% would be realized.

Or, the SEC could institute a set of less than probably 50 automated tests which are executed with the other testing which is done to determine whether the filing will be accepted by the SEC.  That would push the accuracy rate for that specific area to 100%.

Sure, more automated tests would be necessary, but these fundamental accounting concepts would be a good start!

As part of my efforts to understand SEC XBRL financial filings, I analyzed 7,160 such SEC XBRL financial filings, all 10-K filings, looking at a set of 51 fundamental accounting concepts and the relations between those concepts I would expect to see in those filings.

What do I mean by "fundamental accounting concept" and "relations between those concepts"? Well, you can get all that information here on this Fundamental Accounting Concepts Wiki. Examples of fundamental accounting concepts include: Assets, Current Assets, and Noncurrent Assets.  An example of a relationship is: Assets = Current Assets + Noncurrent Assets.

And this is not about requiring a filer to report noncurrent assets or thinking that if a filer does not report noncurrent assets that you cannot figure out what noncurrent assets is.  If assets is reported and current assets is reported, a child with a calculator can figure out that noncurrent assets = assets - current assets.

And this considers that some filers report a classified balance sheet and others provide an unclassified balance sheet.  Also, some filers have a single-step income statement and others report a multi-step income statement.  Some filers combined their income statement and statement of comprehensive income into one statement, some report that information in two statements.  That does not matter. Some filers don't even report comprehensive income.  Why?  Because it is zero, it is not because they don't have to; it is implied to be zero.

Now, don't confuse these fundamental accounting concepts with the US GAAP XBRL Taxonomy concept used to express that fundamental accounting concept.  A simple example will show what I am talking about. So for example, the 2012 US GAAP XBRL taxonomy or earlier allowed Liabilities and Equity to be expressed using one of two different concepts: us-gaap:LiabilitiesAndStockholdersEquity or us-gaap:LiabilitiesAndPartnersCapital.

In the 2013 US GAAP XBRL Taxonomy deprecated (retired) the concept us-gaap:LiabilitiesAndPartnerCapital. The fact that the concept is deprecated shows two things.  First, that the US GAAP XBRL Taxonomy expresses many fundamental accounting concepts using multiple taxonomy concepts.  Second, that these issues will likely be corrected over time as this issue was corrected.

However, until such time one needs to map concepts used by SEC filers to a set of fundamental accounting concepts in order compare information appropriately.  That is exactly what I have done.  You can see that mapping here in this computer readable XML file. And here is all this metadata you can read in Excel.

If you look through the mapping file you start to understand why something like the fundamental accounting concepts are necessary. Analysis software does not understand these relations unless you tell the software about the relations.

So are these fundamental accounting concepts correct?  Are the relations correct?  Well, 97.6% of SEC XBRL financial filings say that the concepts and relations are correct.  See this summary:

(Click image for larger version)

This information helps you see that these fundamental accounting concepts and the relations between those concepts are correct:

Here is the same information above shown graphically:

(Click image to view larger image)

The data and the chart of the data show that 91% of all SEC XBRL financial filings have 3 or less anomalies (i.e. they follow the 51 fundamental accounting concepts and the relations between the concepts in all but 3 cases within their filing).

What does this mean? Well, it means a number of things.  First, as I mentioned in another blog post; automated testing of things like this can help improve information quality of SEC XBRL financial filings. Second, the fundamental accounting concepts and relations seem to be correct.  If they are not correct, then what?  Change them until you get a set that everyone agrees are correct.

Are these the only relations which exist in SEC XBRL financial filings? Certainly not.  These 51 concepts and 21 relations are a beachhead.  If this information is correct then EVERY SEC XBRL financial filing can be compared at this level. If they can be compared at this high level, then one can drill down into lower levels and both see the concepts and relations, write the business rules, and improve the quality at the next level down.

The many different disclosures have business rules which are followed.  For example, a disclosure of the components of inventory would always have total inventories, should always foot, and would always exist if the line items inventories existed on the balance sheet.  And so it is with the 1000 to 2000 (I don't know what the number is, but it is not infinite) other disclosures.

All these business rules make up a knowledgebase of information which will be useful for many things. One thing that this knowedgebase will be used for is making sure SEC filers create their digital financial reports correctly. This is not about changing US GAAP or telling filers how to report.  This is about common sense, rational, sensible use of XBRL to express the information you want to express.

Balance sheets balance.  These concepts and relations are fundamental.