Seeing the Cause of Consistency by Reconciling Software APIs
I am in the process of comparing the results of obtaining financial information from SEC XBRL financial filings from four different software algorithms (four different software vendors and working on a fifth). This document shows the current results of that analysis. (If you are a software vendor and you have an API which provides financial information from SEC XBRL financial filings and want to be included in this analysis you can see how to extract this information here, contact me when this is working and I will add you to the analysis.)
One thing this analysis shows is exactly what is necessary to make use of the information in SEC XBRL-based financial filings. What that means is that there is no reason to be ignorant about the impact of making specific choices about how information is represented.
These three resources provide detailed information related to reading this information:
- Understanding the Minimum Processing Steps for Effective Use of SEC XBRL Financial Filing Information
- Arriving At Digital Financial Reporting All Stars
- Getting the Current Balance Sheet and Income Statement Start Date Right (This issue was not explained completely in the first document, this clarifies one important issue.)
There are two key pieces of getting the fundamental accounting concept information which provides clues as to what is necessary to get ANY information from an SEC XBRL financial filing.
The first is the mapping between the US GAAP XBRL Taxonomy and the fundamental accounting concepts. This is the XBRL-based machine readable information which contains that mapping. Clearly if different software programs use different mappings, the results the software program will be different. Since the XBRL-based machine readable information is hard for humans to read, I generated this human readable version of the exact same mapping information.
Two of the more interesting mappings are for net income (loss) and equity. Go look at the document or consider this screen shot (click image for larger view):
What is that mapping saying? Well, it says that the same line item "Net Income (Loss)" is being reported using different concepts from the US GAAP XBRL Taxonomy. Those six cover most cases. Now don't get confused here. I really mean the exact same line item, not "Net Income (Loss) Attributable to Parent" or "Net Income (Loss) Attributable to Noncontrolling Interest" or "Net Income (Loss) Available to Common Stockholders". I mean the EXACT SAME LINE ITEM.
There are exactly two reasons this is happening: (a) the concepts available in the US GAAP XBRL Taxonomy, (b) the interpretation of how filers are told to file per the Edgar Filer Manual. I am not going to go into details and explain this, that would take an incredible amount of time and we would have to dig into the details. There is no need to do that though, the SEC XBRL financial filings speak for themselves.
The bottom line is that this inconsistency in which net income (loss) concept to use to report what information is unnecessary. There is no technical reason, you don't get more information if this approach is used, it is flat out unnecessary. In fact, it is unnecessarily confusing.
Look at the concept "Equity". That also provides good insight.
The second key piece are the rules which are necessary to impute fact values which are not reported but that you need to both analyze information and as checks to make sure your data does not contain errors. This is the set of impute rules necessary to get the fundamental accounting concept information.
Looking at impute rule BS-Impute-04, it basically says "IF Assets is not equal to ZERO and if Current Assets is not equal to ZERO (i.e. both Assets and Current Assets are reported); THEN Noncurrent Assets is equal to Assets - Current Assets (i.e. if the filer did not report Noncurrent Assets which is common, just calculate it).
Pretty straight forward why you would need to do this, to both get values you need and cross checks to make sure the information that you are working with is correct.
The impute rules show three important things. First, that you can do this to get and work with the information you need. Second, it shows the extent to which you MUST do this given the way SEC XBRL financial filings are created. Third and most important, that if you CANNOT get certain values there is no way you can create an automated set of impute rules the only alternative is to manually map each SEC XBRL financial filing where you cannot get the values you need.
A good case in point is revenue. Some filers don't report the concept "us-gaap:Revenues". No problem, just use those mappings. Right? Wrong. There is so much variety in terms of what concepts filers use to report revenues and some filers do not provide a total for revenues that it is impossible for the CORRECT value for revenues to be sorted out. So again, what this means is that humans have to get involved to overcome this issue, potentially for thousands and thousands of filings.
By contrast, almost 100% of all filings have the concept "us-gaap:Assets", a total for assets. It is trivial and safe to obtain that reported value. Most information can safely be obtained, it is the exception that is unsafe, revenue is one example. Operating expenses is another. There are a handful of other exceptions.
So you get the financial report, you run software against that report, you obtain results. This is the result I obtained from the Home Depot financial filing:
Four different software programs, EXACT SAME RESULT! So what is so surprising about that, you would expect the software to get the same result, right? Why would software get different results? Do you WANT software ever getting different results for financial information?
No, you DON'T want different results. You want the software returning the results to safely, reliably, predictably and repeatedly give you the correct information, over and over and over no matter what software application you are using. Is that not the promise of XBRL?
By way of contrast, do you want obtaining even this basic information to be a guessing game? Do you want software vendors to write individual software programs which might return different results? I am making a coordinated effort to make certain that these software vendors return the exact same information to achieve a purpose. The purpose is two things:
- Show that it is possible
- Show what it takes
Go back to the mappings and the impute rules and really look at them. Would you want those mappings and impute to be as complex as possible or as simple as possible to try and help software vendors to be able to write consistent query tools? Clearly this is a rhetorical question, but it makes the point. The simpler the better.
Look at the mappings and the impute rules. What can be done to make those simpler?
This analysis is less about ***the*** fundamental accounting concepts and more about the process. Anyone could create any defined set of concepts they might desire. The process is EXACTLY the same, just different concepts. So please don't focus on the specific concepts.
On the other hand, this set of concepts and relations is provably 100% complete for extracting information from not only the primary financial statements, but also from any disclosure which is linked to the primary financial statements. For example, if property, plant and equipment is broken down into its components in the disclosures, these fundamental accounting concept relations force the disclosures which hook to the primary financial statements correctly to likewise be correct. That is the beauty of these fundamental concepts and relations, they form quite a nice "skeleton" into which everything fits.
Please do not misinterpret anything that I am saying to indicate that I am saying that financial reports need to be "forms" in order for XBRL to work for something like SEC XBRL financial filings. To the contrary, the same skeleton which the fundamental accounting concepts provide also provides a framework for extensibility. A discussion of extensibility is beyond the scope of this blog post. I would point out that different concepts need different types of extensibility rules and different types of relations between report elements. Properly implemented, extensibility works well and is definitely needed for US GAAP based financial reporting.
I will be doing this analysis for each of the DOW 30 companies, then the Fortune 100, then the S&P 500. My goal is to tune the software, the impute rules and if necessary the fundamental accounting concepts themselves. I have already found a couple of additions which makes this process more reliable.
Creating a safe, reliable, predictable, repeatable process is a choice. If you are ignorant of the moving parts of the puzzle, you might make the wrong choice. This helps see the moving pieces, it makes the moving pieces quite clear. There is pure science, no subjectivity or judgement is involved.
This information is helpful in improving the excessive tolerances in the SEC XBRL financial filings system and by others creating systems to avoid these excessive tolerances.
Consistency is a conscious result of removing inconsistency.
Reader Comments