Digital Financial Reporting

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?

(Note that I updated the S&P 500 information to correct an issue where I was not finding "Equity" for a handful of reporting entities.  This correction is reflected in the current data set.)

As part of some other things that I am doing and some experimentation I have created two prototypes of using SEC XBRL information provided in 10-Ks. I am only trying to use very basic financial information (assets, equity, revenues, net income, net cash flow), but I think these helpful in seeing the possibilities.

Here are links to the two prototypes:

• Summary information for Dow 30, Fortune 100, and S&P 500
• Information Mashup for S&P 500

Information extracted from SEC XBRL financial filings was done without the help of an XBRL processor. What I am trying to do is see how reliably I can extract very basic financial information. Places where I am having extraction issues are clearly indicated.  What is NOT indicated as well is where I am pulling the wrong information.  For example, it is hard to know for sure if I am getting the "revenues" numbers correctly because of the way filers put this fact in their SEC XBRL filings.  I know that revenues for American Express Company is incorrect because they break out non-interest and interest revenues and do now provide a total (i.e. most companies provide a total for revenues using a common set of concepts).

Other issues related to uncommon uses of [Axis] cause issues.  For example, while most filers use the legal entity [Axis] and indicate the legal entity as either the consolidated entity or parent holding company; this SEC filer does something radically different, (a) they use the name of their company as the value of the legal entity [Axis], but complicating things even more they (b) do not make this the default dimension.  This sort of inconsistency makes using the data much more complicated and increases the risk of picking the wrong information to use. This filer does something slightly different. Personally, I see these sorts of inconsistencies as both unnecessary and they clearly increase the risk of automating the reuse of the information.

The first prototype; the summary information for the Dow 30, Fortune 100, and S&P 500; shows the error rate to be fairly low for these key pieces of information.  For the Dow, there are 150 pieces of extracted information (30 companies times 5 data points) with only one occasion where I could not find the fact which I was looking for.  General Electric chose to muck up the works by providing an extension concept for "net cash flow". I am NOT saying that all the numbers are 100% correct. That is a lot of work to test and I am not to that point yet.  But, finding things which seem to work are a very good first step to achieving the XBRL vision of reusing the information.

Likewise, the error rates for the Fortune 100 and S&P 500 are fairly low. I calculate a .6% error rate for the Fortune 100 and a 1.9% error rate for the S&P 500.  Not bad, but again; any error rate of more than 0% will yield a less than satisfactory result.  There were some other issues relating to the SEC RSS feed which showed themselves from trying to use the S&P 500 information.  A number of filings don't seem to show up in the SEC RSS feed.  Not sure why, but this is sure annoying. Also, I have some duplication of some companies. I have not yet gotten to the bottom of how that was caused, still working on that.

The raw data is provided in Excel.  Fiddle with it. If you find anything interesting please let me know.

The second prototype shows even more possibilities.  The S&P 500 Additional information links to a number of other web pages creating a nice mashup.  Most of the information which I used came from the Wikipedia list of S&P 500 companies web page.  What I had to do though was manually put the SEC CIK number on the Wikipedia list in order to cross reference the information which I had with the information Wikipedia had.  The reason is (a) the Wikipedia information did not provide the CIK number which was the key I had to use and (b) the SEC filings did not provide the company ticker symbol for every company nor did they provide the exchange on which the stock was traded.

Metadata like this CIK number is critical for putting lists of things together.  Another piece which I added (and I am not done yet) is the auditor.  That is not provided anywhere in the XBRL.  I had do go read the HTML page where the name of the auditor does exist.  Perhaps the audit report will eventually be expressed using XBRL and then the auditor will be easy to grab. Be way, way easier to use this information if the SEC required it in the SEC XBRL financial filing.  For example, I have all sorts of interesting information about the generator software used to create the SEC XBRL filing.  That is provided by software vendors and can be gleaned from  the XBRL (it is in a comment).

This stuff is going to be so useful (and cool!) when it works correctly.  By looking at this sort of prototype it is easier to see the gaps between what exists and where we will end up.

The SEC is creating a so-called "RoboCop" to help them detect fraud in financial statements. The SEC is putting together what they seem to be calling an "accounting quality model". They describe the accounting quality model as "being designed to provide a set of quantitative analytics that could be used across the SEC to assess the degree to which registrants’ financial statements appear anomalous."

The SEC is not the first group to think of this idea.  Back in 2009, a paper, Quality of Financial Reporting: measuring qualitative characteristics, was written on this topic.  In the paper, the authors describe a 21-item index which, they say, can be used as a measuring tool which can reliably access the "quality of a financial report".

But what exactly is "quality"?  Well, the FASB describes that in SFAC 8: Conceptual Framework for Financial Reporting. And SFAC 8 is part of a combined, comprehensive framework being developed by the FASB and IASB together. Chapter 3 of SFAC 8, Qualitative Characteristics of Useful Financial Information, discusses what contributes to quality.

You can go read through those characteristics which contribute to quality.  I want to focus on two specific things which are mentioned: "faithful representation" and "free from error".

While IFRS emphasizes the overarching notion of the financial statements providing a "true and fair representation" of a reporting entity; US GAAP does not specifically use those terms.  US auditing standards require this, "presented fairly".  "True and fair" is the term I have used to describe quality of a financial report.  I still stand by those terms even if US GAAP does not specifically call for them.  What, "untrue" and "unfair" are OK?  I think not.

But, OK.  Perhaps one wants to stick to the letter of the law and go for only a "faithful representation". Notice the word "representation".  The FASB does not use the words "faithful presentation" which is what many SEC filers are focused on it seems based on looking at their information.  The "free from error" portion has two dynamics.  To make sure that an SEC filing is free from error, you can either (a) check things manually or (b) check things using automated processes.  Automated processes reduce the risk of errors as humans can make mistakes.  But, in order to automate processes you have to develop and express rules in the form that a computer can understand.

If you are creating a financial report, particularly a digital financial report such as an SEC XBRL financial filings, I believe the following question is a good question to ask yourself: What have you done to prove to yourself that you have created a true and fair representation of the financial information expressed using XBRL?

Here are the details which should be considered when asking that question.  Are these things true?

• Comply with financial reporting standards: Clearly a financial report must comply with the rules (i.e., IFRS, US GAAP including applicable SEC rules, industry/activity practices, other common practices), and reporting entity choices where they have such choices.
• Full inclusion/false inclusion: Everything which should be disclosed has been disclosed as deemed appropriate by the rules and the reporting entity choices.
• Foots, cross casts, ticks and ties: A financial report foots, cross casts, and otherwise "ticks and ties". All mathematical relations must be intact. All nonnumeric relations must be sensible and logical.
• All financial report formats convey the same message: A financial report can be articulated using paper and pencil, PDF, HTML, XBRL, or some other computer readable formats. While the format may change, the message communicated, the story told, should not change. Each format should communicate the same message, regardless of the medium used to convey that message.
• Justifiable/defensible report characteristics: Facts reported and the characteristics which describe those reported facts should be both justifiable and defensible by the reporting entity.
• Consistency between periods: Financial information expressed within one reporting period should be consistent with the financial information expressed within subsequent reporting periods, where appropriate. Changes between report elements which existed in both periods should be justifiable and defensible as opposed to arbitrary and random.
• Consistency with peer group: If a reporting entity chooses one approach/report element and a peer chooses a different approach/report element; clearly some good, explainable reason should exist for such difference.
• Useful, sensible, logical renderings: Renderings of facts, characteristics describe facts, parenthetical explanations which further describe such facts, and other such model structures should make sense, be logical, and ultimately be useful in understanding the information. While there may be differences of opinion as to how to format or present such information; there is significantly less or no dispute about the logic. Disclosures are informational, they relate to information without regard to formatting or other presentational artifacts. The term "notes" relate to organizing disclosures and are presentational in nature. Someone creating a financial report has far more latitude and discretion as to how to organize disclosures into notes than they do as to what must be disclosed.
• Unambiguous business meaning: A financial report should be unambiguous to an informed reader. The business meaning of a financial report should be clear/unambiguous to the creator of the financial report and likewise clear/unambiguous to the users of that financial report. Both the creator and users should walk away with the same message or story.

How many of these items above can be automated?  Clearly, automating everything is not possible. I contend that quite a bit can be automated.  If you look at what the XBRL Cloud Edgar Dashboard provides, you get a sense of the possibilities.

But I believe that what XBRL Cloud is providing is only the tip of the iceberg. The paper mentioned above has some great ideas. The FASB and IASB are providing useful guidance.

While things like the HTML versions of SEC financial reports are very good at following the accounting disclosure rules keep two things in the back of your mind. First, I am pretty sure that running automated tests over a set of financial reports will show "lapses in concentration" and other things which contribute to disclosures being missed. I have found plenty of mathematical errors just in the process of using existing financial information when prototyping; no doubt errors will be found resulting in an improvement in quality by having the ability to use automated testing processes. Second, the efficiency of using automated processes, where possible (and it is NOT always possible), will reduce costs.

Taking all this a step further, using the same notion as the SEC's "RoboCop" and testing the quality of financial reports seems very feasible. I believe that this will provide value to both accountants creating financial reports and the consumers of that financial information.