Digital Financial Reporting

Many people tend to offer up the explanation "there are too many extensions" as the reason why SEC XBRL financial filing information provided by public companies is not usable as envisioned.

The true reason the information is not as usable as it could be is more nuanced than that simplistic and unsubstantiated statement. When it comes to extensions, when extensions are done correctly those extension are generally a very good thing.

Did you know that per the XBRL Cloud EDGAR Dashboard that 99.9% of all SEC XBRL financial filings had the proper XBRL technical syntax? Do you realize that the XBRL US Consistency Suite found a total of 140 XBRL technical syntax errors in the approximately 100,000 XBRL financial filings submitted to the SEC? That is .14%.

Do you know that testing of a set of 7160 SEC XBRL financial filings showed that 98% of such filings pass a set of tests for 50 fundamental accounting concepts which one would expect to find and 21 relations between those fundamental concepts?

Why is it that 99.9% of all SEC XBRL financial filings have such a high rate of compliance to the XBRL technical syntax?  There is a very, very simple and straight forward answer to that question: the XBRL conformance suite.  Tests!

Back in 2001, XBRL 2.0 had a serious software interoperability problem.  Business users could create XBRL in one software application, send it to someone else using a different application, and the receiving application many times could not load the XBRL.  Clearly this was not a good situation.

The current version of XBRL, XBRL 2.1, does not suffer from that interoperability problem.  Why?  XBRL technical syntax issues were solved back in 2005 when XBRL created and started using a conformance suite to test software interoperability.  Every version of every XBRL technical specification has had a conformance suite since that time.  You can find those conformance suites along with the technical specifications.  Here is where you find the XBRL 2.1 conformance suite.

A conformance suite is simply a set of tests where the results are known and software applications are expected to act in certain specific ways when they encounter situations found in the tests.

So a good question to ask yourself is this: Why are there 140 XBRL technical syntax errors found in submitted SEC XBRL financial filings if there is an XBRL technical syntax conformance suite???  Why wouldn't XBRL Cloud and the XBRL US Consistency Checks and the SEC inbound validation get exactly the same results?  Why shouldn't the number of errors in SEC XBRL financial filings be zero?

The answer to that question is that while the XBRL conformance suite helps interoperability, it is not perfect.  The conformance suite is only as good as the tests it contains and the compliance to software vendors to those tests.  The software which the SEC uses for the inbound validation of SEC XBRL financial filings seems to give different results than XBRL Cloud's Edgar Dashboard and the XBRL US Consistency Suite.  Humans make mistakes.  Conformance suites or consistency suites and other such tests help humans make less mistakes.

It works like this as shown in the diagram:

(Click for a larger image)

The only way a meaningful exchange of information can occur is the prior existence of agreed upon syntax, semantics, and workflow/process rules.  To the extent that these rules exist, information exchanged will have the "quality" of meaning for the information to be reusable by automated analysis processes.  By automated analysis processes I mean something as simple as comparing the basic financial information of reporting entities.

So now back to the 98% of fundamental accounting concepts being in the filings and the relations between those concepts being correct.  US GAAP has agreed upon rules.  For example, "assets = liabilities and equity".  Every accountant knows that rule and other such rules.  Well, actually, seems that a handful don't know that.  Or, somehow they created a balance sheet that did not balance.  About 15 SEC filers, of a total 7160 which were tested, had a balance sheet which did not balance.

What would happen if the SEC put a rule in its inbound validation which tested to see if the balance sheet balanced for every period provided within the financial report?  Well, then those 15 reporting entities would need to correct their financial reports in order to submit them and have the SEC accept them. And, then that quality issue would not exist.

How hard is that?  Well, not hard at all.  In fact, here is that exact test along with a handful of other test in this XBRL Formuila file. You many not understand that file, but an XBRL processor which supports XBRL Formula would.  You can see those rules being enforced by the XBRL Cloud EDGAR Dashboard, see the "US GAAP Domain Level Rules" column:

Here are tests to be sure the structure of the representation is correct, I don't have a rate for that but based on looking at the XBRL Cloud EDGAR Dashboard, it looks pretty good:

So why does XBRL Cloud or XBRL US get to determine what constitutes a good or bad SEC XBRL financial filing? Why wouldn't the SEC do that?  Well, good question.  But the SEC does not.  You really cannot argue with XBRL Cloud or XBRL US or my tests of fundamental accounting concepts other than to point out where those tests are wrong.

Tests are how you articulate to computers what "good" and "bad" look like. Test are how you agree on right and wrong.  Tests is what helps a filer, the SEC, the FASB, software vendors, and those using the information understand that they are all on the same page. Tests is what enables a meaningful exchange of information.

The 99.9% interoperability at the XBRL technical syntax level and the 98% interoperability of 50 fundamental accounting concepts and 21 relations is not to say the quality of SEC XBRL financial filings is where it needs to be.  It is more a statement to show that there are some very high quality areas but that this is only the tip of the iceberg.  It also shows a path to quality: more tests.

What about those extensions? How about tests which explain where extensions are allowed and where they are not allowed?  That would provide clarity to filers.

While automated tests cannot be created to detect every quality issue, more tests will certainly help improve SEC XBRL financial filing quality.