XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

Looking at how one would find the reported fact which represents total revenues within an SEC XBRL financial filings helps you understand finding reported facts more generally.

I took a look at how each of the 30 reporting entities which make up the DOW reported revenues and this is what I found. Note that I am looking at the 10-K reported for fiscal years ended in 2012 generally.

Of the 30 reporting entities which make up the Dow, revenues was very easy to determine using automated processes for 27 of those entities. These are the exceptions:

American Express was the only member of the DOW which did not report one total amount which represented total revenues. If you look at the American Express income statement you will see that AMEX reported total non-interest revenues and total interest income, but did not provide a total for the two. For contrast, look at the JP Morgan Chase income statement; they had basically the same situation as AMEX but JP Morgan Chase DID provide total revenues. It is exponentially harder to be sure that you got the correct revenues fact if the reporting entity does not provide total revenues such as using the concept "us-gaap:Revenues" or "us-gaap:SalesRevenueGoodsNet". Another way to see this is to see how consistently easy it is to find reported facts such as Assets, Liabilities and Equity, Equity, and Net Cash Flow.
Du Pont was one of two reporting entities which created an extension concept to express total revenues. If you look at the Du Pont income statement you will see that they created the extension concept "dd:TotalNetSalesAndOtherIncomeNet". There is no better way to make discovering a high level concept such revenues impossible then by creating an extension concept. Again for contrast, General Electric had virtually the same reporting situation and did not find the need to create an extension concept. I did not look into whether the extension by Du Pont was appropriate or not.
EXXON was the other reporting entity which created an extension concept for total revenues. If you look at EXXON's income statement you will see that they reported the line item "Total revenues and other income" using the extension concept "xom:TotalRevenuesAndOtherIncome". Again, I point out that General Electric did not find this need.

With regard to Du Pont and EXXON either one of two things must be true: (a) there is a concept missing from the US GAAP Taxonomy which should exist which they could have used or, (b) Du Pont and EXXON could have made a better concept selection choice.

Perhaps why EXXON chose to create an extension concept is because it does something that the US GAAP Taxonomy does not seem to provide for. EXXON also created an extension concept for the line item "Sales and other operating revenues" (xom:SalesAndOtherOperatingRevenueIncludingSalesBasedTaxes). Then EXXON deducts "sales-based taxes" in the expense section. Comparing this with a few other reporting entities in the same industry:

Chevron does not use this approach.
Phillips does not either.
Marathon DOES use this same approach for excise taxes, however they do NOT create an extension concept for their revenues line item (EXXON did), but Marathon, like EXXON, does create an extension concept for total revenues "mpc:TotalRevenuesAndOtherIncome".
Hess excludes excise taxes from revenues and uses the same approach as Chevron and Phillips.

Based on the facts that I see, it appears to me that EXXON could be right to create an extension concept for total revenues and a concept is missing from the US GAAP Taxonomy for this type of situation. The expenses concept appears to exist. If the revenues concept existed it would be easy enough to write an algorithm to net these two numbers and create comparable revenues numbers for all reporting entities, even if they use different approaches.

EXXON and Marathon using different ways to express the same accounting approach using XBRL. Both of these companies might have better explained why they are doing this in the documentation for the concepts added to their taxonomy.

What this does show is the power of XBRL to handle variety such as this. This is how US GAAP works (allowing variety such as this), this is how XBRL was designed, and this flexibility can work. US GAAP is not random free-for-all, but it does allow for different approaches all of which are allowed. US GAAP is flexible. Financial analysts understand all this sort of stuff and make adjustments to their financial models for such different accounting approaches.

The US GAAP Taxonomy, SEC filings, and data extraction algorithms will all evolve and eventually all this will work and information extraction will work, it will work predictably, and automated information reuse will become a reality; not just for revenues. This revenues example is just that, an example. This type of situation exists for many other financial report line items and disclosures.

These types of situations just need to be uncovered and dealt with. Also, this example points out that not all extension is bad. Extension can point out missing concepts from the US GAAP Taxonomy. An extension such as that provided by EXXON can make important differences stand out. What is best? (a) automating information extraction without knowing this difference or (b) forcing those trying to extract information to recognize this difference and properly adjust for it?

What do you think?