Drilling into Income Statement Semantic Model 
Saturday, September 17, 2011 at 07:56AM
Charlie in Creating Investor Friendly SEC XBRL Filings

The income statement is a bear. The balance sheet and cash flow statement were rather straight forward as compared to the income statement.  Might need to take a different approach.

There are two primary reasons the income statement is a bear.  The first is that there really is no prescribed form or set of totals which one can latch onto.  For the balance sheet and cash flow statement there are "buckets" which everything fits into, totals are generally reported for these buckets or enough totals exist so that the totals (such as liabilities) which are not reported can be easily imputed (i.e. because equity is required to be reported and liabilities and equity is reported, finding total liabilities is a cake walk). The second issue is the number of permutations/combinations which are possible due to the existence or non-existence of equity method investments, taxes, discontinued operations, extraordinary items, noncontrolling interest, preferred shares. Picking the correct "subtotals" can be a challenge.

What I can say about the income statement for the 5525 filings in my test set is this:

I have not given up on being able to sort this out and automate the comparison of these high-level items between filers, clearly where it makes sense.  Comparing a retailer who uses gross profit to a bank who does not use gross profit can be done, it is just done at a different level of the income statement, say income (loss) from continuing operations before taxes, which they both will have.

Personally, what I would like to see done is certain line items should be reported whether you have them or not. What I am trying to achieve is two things: automatable comparison and/or aggregation across all filings and "ease".

For example, if a filer does not have any revenue, from my vantage point I feel that it is better to report revenue of zero than it is to drive software vendors nuts trying to write reliable algorithms to accurately compute say an aggregation of revenues across all SEC filings.  Same deal for a few other line items, maybe "income (loss) from continuing operations before taxes", "net income (loss)", perhaps a few others.

Trying to do this today is possible, but it will be brittle and fragile, not robust, reliable, accurate, and predictable which is what we need.

Filers are not giving up any flexibility to report their operations how they feel they should be reported within US GAAP.  All I am talking about here is a few subtotals, make sure they are there.  It is not disputable where income from equity investments, income from discontinued operations, income from noncontrolling interest, nonoperating income and expenses, revenues, gross profit, taxes, extraordinary items are reported.  That does not change.  All I am saying is that adding a few subtotals will make it easier for those trying to grab this data, expanding the set of those who can make use of this information.

From a creation perspective, my real interest really, these subtotals do exist in the taxonomy you are working with.  The creators of information know the relations which they want to express and can go into the taxonomy to find the pieces, leveraging these semantic relations which do exist.  That is not an issue.  But for those using the information, if they don't have something to grab ahold of, they will have to unravel the income statements of filers one-by-one.  This very possible, but time consuming, expensive, and brittle.

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