Digital Financial Reporting

As part of my efforts to understand SEC XBRL financial filings, I analyzed 7,160 such SEC XBRL financial filings, all 10-K filings, looking at a set of 51 fundamental accounting concepts and the relations between those concepts I would expect to see in those filings.

What do I mean by "fundamental accounting concept" and "relations between those concepts"? Well, you can get all that information here on this Fundamental Accounting Concepts Wiki. Examples of fundamental accounting concepts include: Assets, Current Assets, and Noncurrent Assets.  An example of a relationship is: Assets = Current Assets + Noncurrent Assets.

And this is not about requiring a filer to report noncurrent assets or thinking that if a filer does not report noncurrent assets that you cannot figure out what noncurrent assets is.  If assets is reported and current assets is reported, a child with a calculator can figure out that noncurrent assets = assets - current assets.

And this considers that some filers report a classified balance sheet and others provide an unclassified balance sheet.  Also, some filers have a single-step income statement and others report a multi-step income statement.  Some filers combined their income statement and statement of comprehensive income into one statement, some report that information in two statements.  That does not matter. Some filers don't even report comprehensive income.  Why?  Because it is zero, it is not because they don't have to; it is implied to be zero.

Now, don't confuse these fundamental accounting concepts with the US GAAP XBRL Taxonomy concept used to express that fundamental accounting concept.  A simple example will show what I am talking about. So for example, the 2012 US GAAP XBRL taxonomy or earlier allowed Liabilities and Equity to be expressed using one of two different concepts: us-gaap:LiabilitiesAndStockholdersEquity or us-gaap:LiabilitiesAndPartnersCapital.

In the 2013 US GAAP XBRL Taxonomy deprecated (retired) the concept us-gaap:LiabilitiesAndPartnerCapital. The fact that the concept is deprecated shows two things.  First, that the US GAAP XBRL Taxonomy expresses many fundamental accounting concepts using multiple taxonomy concepts.  Second, that these issues will likely be corrected over time as this issue was corrected.

However, until such time one needs to map concepts used by SEC filers to a set of fundamental accounting concepts in order compare information appropriately.  That is exactly what I have done.  You can see that mapping here in this computer readable XML file. And here is all this metadata you can read in Excel.

If you look through the mapping file you start to understand why something like the fundamental accounting concepts are necessary. Analysis software does not understand these relations unless you tell the software about the relations.

So are these fundamental accounting concepts correct?  Are the relations correct?  Well, 97.6% of SEC XBRL financial filings say that the concepts and relations are correct.  See this summary:

(Click image for larger version)

This information helps you see that these fundamental accounting concepts and the relations between those concepts are correct:

Here is the same information above shown graphically:

(Click image to view larger image)

The data and the chart of the data show that 91% of all SEC XBRL financial filings have 3 or less anomalies (i.e. they follow the 51 fundamental accounting concepts and the relations between the concepts in all but 3 cases within their filing).

What does this mean? Well, it means a number of things.  First, as I mentioned in another blog post; automated testing of things like this can help improve information quality of SEC XBRL financial filings. Second, the fundamental accounting concepts and relations seem to be correct.  If they are not correct, then what?  Change them until you get a set that everyone agrees are correct.

Are these the only relations which exist in SEC XBRL financial filings? Certainly not.  These 51 concepts and 21 relations are a beachhead.  If this information is correct then EVERY SEC XBRL financial filing can be compared at this level. If they can be compared at this high level, then one can drill down into lower levels and both see the concepts and relations, write the business rules, and improve the quality at the next level down.

The many different disclosures have business rules which are followed.  For example, a disclosure of the components of inventory would always have total inventories, should always foot, and would always exist if the line items inventories existed on the balance sheet.  And so it is with the 1000 to 2000 (I don't know what the number is, but it is not infinite) other disclosures.

All these business rules make up a knowledgebase of information which will be useful for many things. One thing that this knowedgebase will be used for is making sure SEC filers create their digital financial reports correctly. This is not about changing US GAAP or telling filers how to report.  This is about common sense, rational, sensible use of XBRL to express the information you want to express.

Balance sheets balance.  These concepts and relations are fundamental.

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.

This Understanding Concept Computing helps one understand where digital financial reporting is headed in my view. This is not as much about the specific term "concept computing"; it is more about the ideas that I see in that slide deck.

In particular take a look at slide 32 which talks about "self-declaring" and "self-defining" components.

"Knowledge models" which are the concepts and relations between concepts are not hard coded into software applications, rather software applications read these knowledge models and dynamically adjust themselves.

This is another presentation, Concept Computing in Twelve Tweets. 

Model = Design = Documentation = User Interface

Concept computing enables everyone to model.

BeInformed videos.