Digital Financial Reporting

Absolutely crucial to making use of any SEC XBRL financial filing information is the proper detection of the current balance sheet date. And while 99.3% of SEC XBRL financial filings have current balance sheets which are not erroneous and are unambiguously detectable; .7% of filings are potentially ambiguous.

This document Understanding Why Current Balance Sheet Date Cannot be Detected walks you through 8 specific situations where the current balance sheet date is either erroneous or ambiguous. You can see from the document where the dei:DocumentPeriodEndDate, the endDate value of the period context of the "required context", and the balance sheet date of the most current period presented are not consistent and why that can cause problems.

But that is not the primary point here. Here are the primary points:

• Specific reasons for errors: Inconsistency between these three dates is a specific reason why information within an SEC XBRL financial filing might not be detectable or could lead to the wrong information being identified as the current balance sheet date.
• One error means systemic issue: Why is it the case that even one of these errors exist within the SEC EDGAR system?  Simple answer: missing inbound validation test on the part of the SEC.

Now, don't misinterpret what I am saying.  I am not saying that every aspect of making sure that the current balance sheet date can be 100% correctly detected using automated processes.  I am not ready to hold that out as true.  Why?  Because I cannot prove that in 100% of all cases the correct current balance sheet date can be detected using automated processes.  I cannot say that because I have not proven to myself that all the SEC XBRL financial filing information that I am looking at is correct.  I will know that to be true when I stop finding mistakes.  Not there yet.

But what I can say is that I am 100% confident that a computer can look for three dates, compare the dates, and determine if the dates are consistent or inconsistent.  That is the rule which can be automated.  Specifically, (a) software looks at the dei:DocumentPeriodEndDate reported fact, (b) software looks at the endDate of the period of the context which is used on the dei:DocumentPeriodEndDate which will always be the "required context" as defined by the SEC Edgar Filer Manual (EFM), (c) the computer can compare those to dates to make sure they are the same date, (d) the computer can look for concepts which appear on the balance sheet such as "us-gaap:Assets" and see if a value can be found for that reported fact.

On the other hand, if an SEC XBRL financial filing consistently provided the WRONG date and if information was provided for the correct current balance sheet date and the dates which were provided pointed to the prior period, there can still be an error.  Only a human could pick up on this error.

That is why I cannot, at this point, say that you can detect the current balance sheet date with 100% certaintly.  You can only say that if you detect an inconsistency between the dates, then you know something is wrong.

Why do you care about this?  Well, this has huge ramifications if you are trying to engineer a system which works correctly.  This is the primary point of my ramblings: how do you implement digital financial reporting and digital business reporting correctly.

So have a look at the PDF document mentioned above for more details.  But be sure to walk away with these insights:

Insight #1: Detecting the current balance sheet date is fundamentally necessary to make proper use of information contained within an SEC XBRL financial filing.

Insight #2: There is a significant difference between detecting 0 errors and detecting even 1 error.  The existence of 1 error reveals a problem in the system, potentially a missing test.

Insight #3: It might not be possible to create 100% of the automated tests necessary to make 100% certain that everything is working correctly.  However, if it is possible to create an automated way to detect and correct errors a system should implement that rule.