Digital Financial Reporting

This set of short videos shows a tool called Quantrix.  Watch the videos.  I encourage you to invest in watching the complete set.  Trust me, it is worth the time.

After watching the video, ask yourself a question: "Why can't SEC XBRL financial filings work like this."

Here is financial information shown in Tableau.  Imagine putting just the fundamental accounting concepts of public companies into that format. Hard to use?  I don't think so.

True is, SEC XBRL financial filings can work in that manner.  If fact, they can work even better.

The Louvre museum has an annual balance sheet of a State-owned farm, drawn-up by the scribe responsible for artisans: detailed account of raw materials and workdays for a basketry workshop. Clay, ca. 2040 BC (Ur III).

Wiki commons

Paper-based (or clay-based) and even electronic PDF or HTML financial reports are readable by humans. On the other hand, digital financial reports are readable by both humans and machines.

Machines can therefore do things to help humans create or use digital financial reports that such machines could not help humans with before. This help from machines in creating and using the financial information within a financial report will reduce costs and increase quality. For example,

• A computer can read the reported financial information, understand the information, and can help make sure all of your mathematical computations are correct and intact; make sure everything foots and cross casts and otherwise ticks and ties.
• A computer can read the reported financial information, compare the reported information to disclosure rules, and make sure the creator followed mandated disclosure rules.  This is somewhat like a manually created disclosure checklist is used today as a memory jogger.
• Reported information can be easily reconfigured, reformatted, and otherwise repurposed without the need to rekey information because a computer can do all this for you.
• Ambiguity is reduced for humans because for a computer to make use of the information, the information cannot be ambiguous.  Making the information easy for a computer to correctly understand also makes it easier for humans to understand.
• Processes can be reliably automated because computers can reliably move information through the work process.  Unlike trying to link spreadsheets together, linking digital financial information together can be much more reliable.
• Computer software can adapt itself to specific types of reporting scenarios, again because software leverages and understands the machine readable financial report information.
• Because processes can be automated, the time it takes to create financial reports will be reduced and the human costs of connecting processes can be reduced.

This is not to say that humans will not be involved in the process of creating financial reports.  Clearly machines will never be able to exercise judgment. Computers cannot detect all possible mistakes, they can only help humans.

How can all this happen?  The more a machine can understand (high semantic clarity), the more a machine can assist humans.

These resources can provide you with additional background information on the possibilities offered by digital financial reporting:

• Digital Isn't Software, It Is a Mindset
• How Data will Transform Business
• Project10X: The Power of Strong Semantics
• Semantics Overview
• Understanding Concept Computing
• Digital Financial Reporting will Change Accounting Work Practices
• Race Against The Machine: How The Digital Revolution Is Accelerating Innovation, Driving Productivity, and Irreversibly Transforming Employment and The Economy (MIT)

All we need to do is get the right software built which understands digital financial reports.

This blog post updates a prior post, Minimum Criteria for Evaluating SEC XBRL Financial Filings. The core premise did not change, only the supporting data and therefore the summary totals. This post updates the data for the complete set of 10-K filings submitted to the SEC between March 1, 2013 and February 28, 2014.

To repeat the core premise: "Prudence dictates that using financial information in SEC XBRL financial filings should not be a guessing game. Rather; safe, reliable, predictable, automated reuse of reported financial information seems preferable."

To realize that goal, fundamental things about an SEC XBRL financial filing must always be correct.  These are the minimum criteria for using the information; and therefore they should be the minimum criteria for evaluating the appropriateness of SEC XBRL financial filings.

Not meeting these minimum criteria cause the information contained in SEC XBRL financial filings to be ambiguous, to not be decipherable by automated computer processes, to yield "red flags" which indicate the information may not be trustworthy to automated computer processes, or to be unusable by such automated processes. Further, any human readable renderings derived from this information will not be usable.

In addition, violations of these criteria cause very specific issues, most are very easy to see and understand, and generally issues are very easy to fix.

The following is a summary of the minimum criteria which are necessary for an SEC XBRL financial filing in order to make use of any financial information within that digital financial report. Also provided is the percentage of situations within SEC XBRL financial filings which already meet this criteria.

1. 99.9% meet the criteria of consistent XBRL technical syntax rules and are therefore fundamentally readable documents (More information | Examples)
2. 97.9% meet the criteria of specified by automatable SEC EDGAR Filer Manual (EFM) rules (More information | Examples)
3. 99.9% meet the criteria of consistent and unambiguous report level model structure relations (More information | Examples)
4. 99.2% provide a detectable "root of reporting entity" so that information can be properly discovered using automated processes (More information | Examples)
5. 99.3% provide a detectable and unambiguous current balance sheet date (More information | Examples)
6. 97.8% consistenty report or provide enough information to impute 51 fundamental accounting concepts and those concepts consistently adhere to 21 basic accounting relationships (More information | Examples)
7. 90.1% provide detectable roll up rules for balance sheet, income statement, cash flow statement (More information | Examples)

How do I know that these criteria are correct?  Because 1,281 SEC XBRL financial filings satisfy all seven of these criteria and the foundational information in their digital financial reports is proven to be usable by automated computer processes. These 1,281 public companies are digital financial reporting all stars.

What is even more interesting than the 1,281 examples where you can use these digital financial reports is the fact that the gap between the others which do not meet these criteria and those public companies also becoming digital financial reporting all stars because they meet this required minimum criteria is so small. Consider the following:

• 1,281 have 0 errors/issues/anomalies (these are the current all stars)
• 2,293 have only 1 error/issue/anomaly
• 1,382 have 2 errors/issue/anomaly
• 700 have 3 errors/issue/anomaly
• 433 have 4 errors/issue/anomaly
• 255 have 5 errors/issue/anomaly

Add all those numbers up and you get 6,344 or 95% of all SEC XBRL financial filings which are 5 or less errors from meeting that minimum criteria. That is 10,164 errors!

Something is worth repeating here.  I am not saying that I have 100% of my criteria exactly correct.  What I can say is that given my interpretation, if my interpretation were employed the system would work.  However, the goal is system equilibrium, for the system to be in balance. There are three things which impact the system:

1. The SEC XBRL financial filing.
2. The business rules.
3. The software algorithm which reads the SEC XBRL financial filing.

So basically if someone has a better interpretation of the business rules or of someone can create a better software algorithm to effectively and safely use these digital financial reports, cool.  But we do need to have one agreed system, not 6674 different systems one for each of the 6674 different filers.

There is one other thing worth mentioning.  I don't have this totally dialed in yet, but this is what I currently see.  My perspective on these tests was the filing, the submission, the report.  If you pass all the tests then "you are an all star". 

But that perspective might not be correct or the best way to look at what is really going on with SEC XBRL financial filings. Perhaps a better and certainly a different perspective is looking at all the possible errors which COULD exist as compared to all the errors which DO exist.

Consider the following. In my set of 6,674 SEC XBRL financial filings I am testing there are 6,442,922 relations between the report elements contained in those filings.  Of those 6,442,922 relations there are only 344 total relations which are potentially ambiguous. If I am getting my decimal points correct, that is .0054% of the total relations. The vast, vast majority of those relations are correct.  This is not to minimize the errors, those errors must be fixed.  But considering that very few systems adequately manage these model structure relations correctly (proof of that is ANY errors), those who are creating these reports are doing a very good job of getting these model structure relations correct.

These SEC XBRL financial filings are made up of many, many, many little pieces.  All these many, many little pieces have to fit together correctly. Most of these pieces do fit together correctly.

What if we were to flip this around? The tests that I am looking at has the focus on what is wrong in the SEC XBRL financial filing.  What if one were to look at what is RIGHT!  Again, the point here is not to minimize the errors.  Again, those must be fixed.  But what I am noticing is that there are also a lot of things which are right with these digital financial reports; particularly considering that there are not nearly enough automated processes watching over the creation of the information.

To give you a perspective, there are an average of 1278 reported facts in a report.  Each reported fact has a context.  Each reported fact has taxonomy schema pieces, linkbase relations, lots and lots of stuff.  The XBRL 2.1 and XBRL Dimensions conformance suites have probably around a thousand tests.  Considering all the possible things which could be wrong and for 6674 SEC XBRL financial filings, there are 3 errors.  That is really pretty amazing.

Again, don't get me wrong.  In an article, XBRL Mistakes Really Hurt: Why Accuracy is Crucial for Your Company’s Communications with Financial Markets, Professor Dhananjay (Dan) Gode, a Clinical Associate Professor of Accounting at New York University’s Stern School of Business, makes the following statement:

"95% accuracy is not good enough – even 98% is not good enough"

The only way digital financial reports will work is if they are 100% accurate. The truth is that digital financial reports can be more accurate than the current financial reports created using Microsoft Word.  Why? Because computers can read and therefore help accountants creating digital financial reports.  Word knows nothing about financial reporting.

As you can see from my minimum criteria, digital financial reporting tools do understand financial reports.  Digital financial reporting tools know that "assets = liabilities and equity".  They know that assets foot.  They understand the notion of the balance sheet date and can help you keep it that information consistent.  Word can do none of this! And I would point out the phrase "minimum criteria".  My seven criteria is only the tip of a much larger iceberg.  While humans are crucial to the process of creating and even using financial information, computers can help humans if financial reports are digital.

So are SEC XBRL financial filings "half correct" or "half wrong"?  SEC XBRL financial filings are far, far more than "half correct".  I don't know if you can extrapolate my data onto the entire filing.  My lowest category is 90.1%.

Every accountant knows that assets should foot.  So should liabilities and equity.  Net income (loss) on the income statement foots.  Net cash flow on the cash flow statement foots. Further, SEC Edger Filer Manual (EFM) rules, 6.15.2, requires that these computations be provided with SEC XBRL financial filings in the form of XBRL calculation relations.

90.1% of SEC XBRL financial filings provide these XBRL calcuations for these primary financial statement roll up computations. Pretty straight forward. This document Understanding Why Roll Ups are Missing provides what helps you understand how to see if required XBRL calculation relations are missing from SEC XBRL financial filings which support the validation/verification of these primary financial roll ups which always exist in financial statements.

There is something which is important to understand.  I will point this out for the roll up computations but this relates to all these tests.  Consider this graphic which will help explain the point: 

There are two ways you can view these tests: by filing and by test. If you look at this by filing, then if you don't have any one of the four roll ups, then you fail the test.   If you look at this by test, each individual roll up is considered and if you have three of the four, you get "credit" for three.

I point this out so you can use this information to look at this information.  There is no real right or wrong answer, you just need to understand what the information means.

This is my summary of key insights:

Insight #1: Balance sheets report assets, liabilities and equity; assets foot; liabilities and equity foots.  Income statements report net income (loss); that foots as well.  Cash flow statement report net cash flow; and that foots as well.

Insight #2: If you are looking at this basic financial information and you can verify that these roll up computations work as expected, your trust of the information when you send it to some automated process, which might do a comparison or something, can be much higher because everything seems to work as you expect.

Insight #3: Each of these roll up computations is required by SEC EFM rules.

Insight #4: There is no "technical" reason that these XBRL calculations cannot be expressed and verified to be consistent.  If someone thinks there is some reason they cannot express these correctly and therefore they leave them out, they make a mistake in their representation of the information in XBRL.  If the representation mistake is corrected, then the XBRL calculations can work correctly.

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.