I include the automated SEC Edgar Filer Manual (EFM) rules within my 7 minimum criteria for making use of information contained in SEC XBRL financial filings. However, I am not quite sure how to actually make use of this information.
On the one hand, automated EFM rules are critical to the process of making use of any SEC XBRL financial filings. That is why the rules exist. So for example, you can determine the current balance sheet date of a filing by checking for the value of the concept "dei:DocumentPeriodEndDate". So in that regard, these rules are critical.
On the other hand, many of the EFM rules relate to things like how to properly format HTML within a text block and things which have no impact on the fundamental use of information within an SEC XBRL financial filing.
And so, I don't really use this rule category in my evaluation process; I mainly just track the error count. But, I do evaluate key factors which are, in fact, required by the EFM such as that "dei:DocumentPeriodEndDate" value. I do that within a separate criteria category though.
Secondly, I get this information from XBRL Cloud who evaluates SEC XBRL financial filings on their EDGAR Dashboard. The terms of my agreement with XBRL Cloud for my use of this information preclude me from providing detailed information about automatable EFM errors because XBRL Cloud charges for that information.
What I can say is this: The number of EFM errors has dropped significantly over the years and the current data which I get from XBRL Cloud shows that 97.9% of all SEC XBRL financial filings have zero automated EFM rule violations.
Something that is worth pointing out which can be confusing is why does XBRL Cloud show any EFM rule violations at all? I mean, isn't the point of the EFM to document how the SEC will be evaluating SEC filings when they are submitted to the SEC?
Well it does not quite work that way. The SEC does not do a complete job of testing against their own EFM rules. Further, XBRL Cloud has different interpretations of those rules than other software vendors or does a more complete job of implementing rules. And so, because there are cracks in the SEC's inbound validation and because software vendors don't collaborate and try and make their software interoperable; XBRL Cloud points out these inconsistencies between the SEC, other software vendors, and XBRL Cloud's implementation of the EFM. This is unfortunate because it is confusing, but that is what is going on.
I will call this good for automated EFM rule validation necessary to make use of information in SEC XBRL financial filings. The specific things necessary will be covered within the other criteria I use in my evaluation process. But I will summarize my insights as follows:
Insight #1: Automated EFM rules are fundamentally necessary to drive the usability of any of that public company financial information contained in SEC XBRL financial filings. However, many rules such as HTML formatting do not relate to the minimum criteria necessary to make use of this information.
Insight #2: When the process works correctly, the SEC specifies an automated EFM rule, the SEC inbound validation verifies filings against those rules, SEC submissions comply with that rule because of the inbound validation, and things work. For example, every SEC XBRL financial filing submitted provides a concept dei:EntityRegistrantName and SEC validation during submission checks to make sure that concept exists and if it does not then the submission is rejected.
Insight #3: Cracks in the process such as different implementations and interpretations of automated EFM rules by the SEC different software vendors cause inconsistencies in SEC XBRL financial filings. If you think about it, if things worked correctly the XBRL Cloud EDGAR Dashboard would always show ZERO errors.