Well, I cannot say exactly how sensible or logical or faithful that SEC XBRL financial filings are overall but I can point out some very good signs in the information public companies are creating and specific reasons for issues with that information which is the first step needed to fix the issues.
Now, all SEC public companies are providing complete, detailed financial reports in XBRL. I have been looking at this information for three years trying to understand it, understand how XBRL works, how to best employ it for financial reporting, etc.
What I know I did not understand until the last few years, and, to the best of my recollection, I really don't have any evidence that anyone understood either, was all the details of what would make digital financial reporting truly work. This blog post, Achieving Meaningful Exchange of Information, summarizes things pretty well: this is a very hard undertaking, even for information technology experts and other domains, I think that financial reporting is a pretty tough use case (i.e. rich information set, little or no tolerance for error), and all this is done with complete transparency and in the public eye (i.e. all this information is there for people like me to hack away at). But it is the business users who need to make this work how they want/need it to work.
This is what see in the SEC XBRL financial fiings and I admit this is a very high level, but it is a beach head, it is a start. I improved my analysis processes, eliminating duplicate filings, focusing on 10-K filers, and from the SEC RSS Feed I was able to pull 7,150 Form 10-K (or 10-K/A, 10-KT, 10-KT/A) filings. This is what I see:
- Of the 7,150 filings I can get sensible, logical, faithful, and 100% meaningful core financial information for 6,515 or 91% of those filings. (Meaning that there are 635 or 9% which I cannot.)
- This was done by a non-programmer (I am a CPA, not a programmer; but I have learned to write some code over the years), it was done using Microsoft Access, I do not use an XBRL processor to extract this basic information (although, I do admit it would be easier particularly for more detailed information).
- It takes approximately 4 hours for this entire process, most of that time is download time.
- There is no way in the world this would have been remotely possible without XBRL or something like it.
- Errors and ambiguity sticks out like a sore thumb if good tools are used to look at these SEC XBRL financial filings.
I will put all the raw data into an Excel spreadsheet and make it available over the next week or so. People can fiddle with it, see if they can see anything. To be clear, the pieces of information I am trying to grab are the following: assets, liabilities and equity, equity, net income (loss), net cash flow, current assets, current liabilities, and a handful of other high level concepts such as these. There is other information which I grab which is key to getting this information correctly such as the dei:DocumentPeriodEndDate, the SEC RSS information, a few other items.
What could make things better? Well, as that article mentioned above points out,
The only way a meaningful exchange of information can occur is the prior existence of agreed upon semantics and syntax rules. This is the only way. These rules are a precondition for a meaningful information exchange. To the extent that a meaningful exchange occurs the information exchanged can be effectively reused without human intervention. There is a direct correlation between the "agreed upon semantics and syntax rules" and the "meaningful exchange of information." Full stop.
It is all about the rules. Imagine the following. Imagine the XBRL Cloud EDGAR Dashboard or something like that. Clearly it would be best if the SEC or maybe the FASB did this. They might eventually. If you take a look at these rules it becomes clear why each column in this dashboard is important.
The target: Imagine if everything was green
But it is really straight forward: you have a dashboard of some sort, you have all the SEC flings listed, you have GREEN cells for everything and then all the filings are perfect. There are no RED cells which indicate errors. There are no UNKNOWN cells which indicates missing rules. There are so many details here that there is no way you can get 8000 some odd SEC filers to do exactly the right thing without them understanding what the rules are.
And even if you have 100% of the rules necessary to assure that every SEC public company filing is sensible, logical, faithful representations of financial information; it is still impossible to make certain all information is verifiably "true" and "fair" using only automated processes. Only humans can verify certain things. For example, if someone mistakenly switched the concept on two facts, "prepaid expenses" and "deferred assets" as an example, humans might be the only way to figure that out. Now, because information is so intertwined in a financial report switching things in one place could be detected in other places because thing might not add up; be sure that humans will still be involved.
And what if we could make this work, how valuable would that be? What if this was cost effective, easy to use, robust, reliable, repeatable, predictable, scalable, secure, auditable. How useful is that?
Folks, that is exactly what is going to happen. That is what is happening. And frankly, XBRL is not even needed and no one creating a financial report even ever has to press the "save as XBRL" button.
This is what the semantic web is all about. The accounting profession is leading the way. Way back in 1999 when XBRL started the technical architects of XBRL got this. Maybe not all the details, but they did get the big picture. Lots of different domains are struggling to make their semantic webs work and to make sure their semantic information fits into other semantic information.
This is hard stuff and the SEC deserves credit for what they are doing. Other regulators also, they seem to be the ones driving XBRL in most cases.