Digital Financial Reporting

Every financial report is provided for some economic entity or accounting entity. If you cannot find this entity in an SEC XBRL financial filing, you cannot successfully use any information the filing contains. This information is key.

The entity of focus or root reporting entity is detectable in 99.2% of all SEC XBRL financial filings.  This document Understanding Why Root Economic Entity Cannot be Detected summarizes information and provides specific information about why the 52 entities of focus could not be detected in my set of 6,674 SEC XBRL financial filings.

Here is a summary of these reasons these entities were not discovered:

• Related to reporting entity reporting a successor (using Scenerio [Axis]) (total 14)
• Related to reporting entity reporting a successor (using Legal Entity [Axis]) (total 1)
• Related to an error in discovery of the current balance sheet date but was misinterpreted to be a undiscoverable root reporting entity (total 14)
• Not really an error, zeros reported for all balance sheet fundamental accounting concepts or missing line items (total 11)
• Inappropriate extension concepts (total 1)
• Related to reporting of parent holding company (total 4)
• Related to use of inappropriate concept and statement of net assets  (total 3)
• Filer used "Audited member" on Scenario Axis (total 1)
• Filer used "Restatement Adjustment [Member]" on Scenario Axis (total 1)
• Filer created of Legal Entity [Axis] member to express entity, did not use dei:EntityDomain (total 2)

Two things are worth clarifying.  Bullet three is really an inability to detect the current balance sheet date error. So it is an error, but not the error I thought it was.  To fix the classification of the error I need to adjust the software algorithm a bit.  Bullet four is not really an error either, it just looked like an error because this handful of filers reproted zeros for key pieces of information used to determine if the root entity was detected.  But it does point out some issues with how some things are reported if the value is zero.

On the one hand, these errors are not a huge deal because the number of errors is so small. But on the other hand, this is the basis for all other information in a financial report.

Insight #1: Every financial report is about some economic entity or accounting entity.  These entities come in many different flavors and have different characteristics which are important to understand.

Insight #2: It seems to be better to change the way information is represented in order to make it so the root entity of focus can be discovered than it is to constantly change software algorithms to detect root entities.

Insight #3: Just because a majority of SEC XBRL financial filings are represented in a particular way does not make that way right.

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.

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.

What appears to be one of the most boring of the seven minimum criteria for evaluating an SEC XBRL financial filingis the category consistent XBRL technical syntax. First off, it really is not that important because 99.9% of all SEC XBRL financial filings have consistent XBRL technical syntax.  It is also "technical". No one even wants to deal with the "technical" stuff related to SEC XBRL financial filings.

But if one is curious and looks a little closer at WHY the consistency of SEC XBRL financial filings at the XBRL technical syntax level is almost perfect; then one would learn some important and useful things.

And so how is that consistency rate of 99.9% achieved?  Well, it is achieved because XBRL software, or good XBRL software anyway, supports the XBRL 2.1 conformance suite and other XBRL conformance suites such as XBRL Dimensions, XBRL Formula, etc. A conformance suite is a set of tests which helps software agree on how the XBRL technical syntax works.  These XBRL conformance suites have hundreds of tests which prove that software interprets the XBRL specifications consistently.  The conformance suites help software inter operate.

A good question might be: "Hey, can we use something like a conformance suite to help increase the consistency in the other six of the minimum criteria, to make SEC XBRL financial filings more consistent and more usable by investors and analysts?"

And the answer to the question is "Yes!"  If rules are created which define how SEC XBRL financial filings should be created, the rules are published for creators of those statements to follow, then fewer errors would result.  This is particularly true if the rules were used by the SEC inbound validation process.

For example, today every SEC XBRL financial filing reports a fact "dei:EntityRegistrantName".  EVERY SEC filing has that reported fact.  Why? The submission process verifies the existance of that fact before the filing is accepted by the SEC.

Why can't a test such as "Assets = Liabilities and Equity" be part of that inbound validation process?  That test might not require a filer to report "Assets" or "Liabilities and Equity"; but if they did, the two values should be equal for each context in which they exist.

Why would this be a good idea?  Well because:

The only way a meaningful exchange of information can occur is the prior existence of agreed upon technical syntax, domain semantics, and process/workflow rules.

These sorts of rules are the key to high-fidelity information exchange and quality, useful public company financial information. Filers don't want to make mistakes.  But there are so many details that it is hard to get all the details correct unless a computer helps the accountants who are creating these digital financial reports.

Although, what is truly amazing is how correct accountants are getting the information even without a complete, comprehensive conformance suite which covers all possible categories of the minimum criteria.

Finally, by "minimum criteria" I truly mean minimum.  There are thousands and thousands of relations within a financial report.  Computer processes can watch over these relations.  And I don't mean XBRL technical syntax.  That is trivial.  In fact, that is already happening, thus the 99.9% consistency in XBRL technical syntax.  I mean domain semantics.  Getting the accounting correct.  Digital financial reporting will automate much of what is done when something like a disclosure checklist is completed.

So the XBRL technical syntax being 99.9% consistent is not boring, it is a clue as to how all of the other criteria will be watched over in the future.  And these minimum criteria are the tip of a much bigger iceberg.

Almost forgot.  There are only three filings in the set of 6674 which had XBRL technical syntax errors:

• U. S. Premium Beef, LLC
• Atlas Resource Partners, L.P.
• RiceBran Technologies

Why would the SEC's XBRL processor not detect these errors and reject the filing, but some other XBRL processor(s) report these errors? The XBRL consistency suites are not perfect nor does XBRL software vendors implement the XBRL conformance suites perfectly.  After all, humans are involved in that process and humans make mistakes. However, all that said; arriving at 99.9% consistency shows the value of a conformance suite.

This is the summary of insights:

Insight #1: SEC XBRL financial filings are consistent at the XBRL technical syntax level because of the conformance suites which help software understand and implement the XBRL technical specifications correctly.

Insight #2: Conformance suites can be used to create business domain rules such as "Assets = Liabilities and Equity".  These rules are totally up to the business domain. It is these sorts of business rules which produce high-fidelity information exchanges.

The latest information on report level model structure greatly improves what was available in my prior analysis. One incredibly insightful and useful thing I was able to achieve is to access every relation between every report element for all 6674 SEC XBRL financial filings analyzed.  You can see the details of that analysis here.

One mistake I was making which came to light is that I was evaluating filing rather than actual relations.  This is important because while the data shows that 95.8% of SEC XBRL financial filings had unambiguous relations (i.e. if only ONE relation was ambiguous, the ENTIRE REPORT was said to be in error); if you looked at the RELATION LEVEL, 99.9% of the millions of relations were unambiguous.

Here are the report level and the relation level summaries:

Walking through an example is helpful in understanding the report level model structure relations.  So consider the information for relations where the parent is an [Axis].  In the graphic below you can see that there are 386,912 [Axis] in the set of 6,674 SEC XBRL financial filings analyzed.  As expected, an [Axis] had ZERO Networks as children, ZERO Tables, ZERO Axis, 450,091 Members, ZERO LineItems....BUT HOLD ON...what do we see...11 Concepts as children of an Axis! What is up with that?

The point here is that an [Axis] has Members, which is defined as a report element with a type attribute equal to 'nonnum:domainItemType', as children, nothing else.  What does it mean if a Concept is a child of a Member?  Concepts are used to report facts.  Members are used to describe the value of an Axis. Concepts are not intended as children of an Axis.  So, how should this be interpreted?

Below is a summary of the 14 most potentially ambiguous relations found in a set of 6,674 analyzed SEC XBRL financial filings.  Of the 6,442,922 relations in SEC XBRL financial filings, a total of only 344 relations were deemed odd and the interpretation of their relationships was ambiguous:

• 1 SEC filers have an [Axis] as the child of a Network.
• 3 SEC filers have a [Member] as the child of a Network.  [Member]s are generally children of an [Axis] or another [Member]
• 1 SEC filer has a [Table] that is the child of another [Table].  What is the meaning of this?
• 25 SEC filers have a Concept as a child of a [Table].  [Table]s generally have [Axis] and [LineItems] as children.  What does it mean if a Concept is a child of a [Table]?
• 22 SEC filers have an [Abstract] as a child of a [Table].  [Table]s generally have [Axis] and [LineItems] as children.  What does it mean if an Abstract is a child of a [Table]?
• 11 SEC filers have a Concept which is a child of an [Axis].  Only [Member]s should be children of an [Axis]
• 137 SEC filers have a Concept which is the child of a [Member].  Generally [Member]s are the only children of other [Member]s
• 1 SEC filer has an Abstract as the child of a [Member]. Generally [Member]s are the only children of other [Member]s
• 45 SEC filers have a [Table] as a child of a set of [LineItems].  Generally [LineItems] are children of [Table]s, not the other way around.
• 3 SEC filers have an [Axis] which is child of a set of [LineItems]s.  Generally Concepts and [Abstract]s are found in 99.99% as children of a LineItems of SEC filings.
• 1 SEC filer had a [Member] which is the child of a Concept.  How should this be interpreted?
• 2 SEC filers had [LineItems] which were the child of a Concept.  How should this be interpreted?
• 20 SEC filers had an [Axis] which is the child of an [Abstract].  How should this be interpreted?
• 72 SEC filers had a [Member] as the child of an [Abstract]. How should this be interpreted?

There are other illegal and odd relationships. For example, while 99.4% of Networks have a root child concept report element which is of the category Abstract; a handful use a Table as the root element (1261), or a Concept (46).  This may not be ambiguous.  But 183 use LineItems as the root concept.  LineItems are general used within a Table, but again; the information might not be ambiguous.  But 1 SEC filing as an [Axis] as the root and 3 have a Member as a root.  What the heck does that mean?

The point is that while there are 817 anomalies, the 344 relations summarized above are the most odd. However, it would be better if none of the 817 issues existed.

Identifying these report level model structure relations and attempting to extract this information from SEC XBRL financial filings provide a number of noteworthy insights:

• Insight #1: The report elements which make up an SEC XBRL financial filing can be grouped into categories: Network, Table, Axis, Member, LineItems, Concept, Abstract. This report element categories have relations with other report element categories. The vast majority of relations between report elements in SEC XBRL financial filings, 99.9%, and the vast majority of filings themselves, 95,8% of all such filings, follow these relations.
• Insight #2: Not following these report level model structure relations leads to potentially ambiguous representations of such digital financial filings.