Digital Financial Reporting

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.