BLOG: Digital Financial Reporting
This is a blog for information relating to digital financial reporting. It is for innovators and early adopters who are ushering in a new era of digital financial reporting.
Much of the information contained in this blog is summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the three documents on this digital financial reporting page.
Nine quality leaders have laid the foundation for semantic interoperability and established a clear path to zero defect XBRL-based financial reports. A significant milestone was reached this month. The total number of filings that had inconsistencies dropped below 1000, currently only 953 have errors while 5,281 public companies are consistent with the fundamental accounting concept relations.
The document, Summary of Issues of Quality Leaders, inventories the complete list of fundamental accounting concept relations inconsistencies of every quality leader. In so doing, the document lays a path from the current high quality levels to zero defect levels. Remember, there are exactly three reasons for inconsistencies to be reported:
- The creator of the XBRL-based financial report made a mistake. To correct this mistake, the report must be fixed.
- The creator/maintainer of the US GAAP XBRL taxonomy made a mistake. To correct this mistake, the US GAAP XBRL Taxonomy must be fixed.
- The creator/maintainer of the fundamental accounting concept relations business rules made a mistake. To correct this mistake, the business rules must be fixed.
It really is that simple. The document mentioned above shows every inconsistency. Most of those 80 inconsistencies in the 69 reports are not disputed, filing agents/software vendors agree that they have made a mistake and they will fix the public company XBRL-based financial report. But they don't agree with all of the inconsistencies. What then? Who serves as the referee to establish what must be fixed: the filing, the taxonomy, or the business rule? This remains a bit vague.
But as the number of errors is reduced, the areas of disagreement begin to reveal themselves in the XBRL-based financial reports. The vast majority of inconsistencies are not disputed. While the quality leaders have fixed their mistakes, the quality laggards have not.
This ZIP archive contains an Excel spreadsheet that contains a listing of all 1,433 inconsistencies which exist in the 953 public company XBRL-based financial reports. If each of the inconsistencies were corrected by fixing the filing, the US GAAP XBRL Taxonomy, or the business rules; then the XBRL-based financial information would have zero defects as articulated by the business rules. While the rules I have provided are necessary (i.e. they are fundamental relationships) those rules are not sufficient. I have already pointed out that the disclosure mechanics rules also need to be passed.
The point is this: there is a self-evident connection between "quality" and "business rules". All you need to do is read the document which summarizes the remaining issues of the quality leaders and you cannot help to see this important connection.
How hard is it to fix mistakes? If you go back and look at prior testing results you would see that EDGARfilings PROfile went from 76% consistency in March 31, 2016 to 98% consistency in November 27, 2016. This graphic shows their improvement in quality. Merrill went from 55% consistency in March 31, 2015 to 97% consistency in March 31, 2016. Here is Merrill's graphic. Fixing mistakes just takes effort. Good tools can help too.
Here is the summary of consistency with the fundamental accounting concept relations business rules as of November 27, 2016:
Nice work to the quality leaders who have worked so hard to dial in their XBRL-based digital financial reports! Collectively, the 9 quality leaders have reached Sigma Level 4 and I expect them to reach Sigma Level 5 within the next three months. You quality laggards need to get to work fixing your mistakes.
* * * PRIOR RESULTS * * *
Previous fundamental accounting concept relations consistency results reported: August 31, 2016; June 30, 2016; March 31, 2016; February 29, 2016; January 31, 2016; December 31, 3015; November 30, 2015; October 31, 2015; September 30, 2015; August 31, 2015; July 31, 2015; June 30, 2015; May 29, 2015; April 1, 2015; November 29, 2014.
This blog post points you to resources which explain the disclosure mechanics piece of the Zero Defects XBRL-based digital financial report. The document Understanding Disclosure Mechanics provides a high-level overview of what is meant by the term disclosure mechanics.
This blog post provides a list of the 55 disclosures for which I am using for testing purposes.
Here is an update to my world's first XBRL-based, machine-readable financial reporting checklist. (No one has refuted my claim that this the world's first)
I have now added machine-readable business rules for the 55 disclosures listed below. This is still only considered a working prototype because this (a) has not been completely tuned yet and (b) is not yet implemented in commercial software (it currently only runs using my custom made software). This document shows the results I am getting for the first 25 disclosures I implemented. The other 30 that I added are getting similar results. The document also walks you through the tests that I am currently running.
What is becoming increasingly apparent is the utility of these business rules not only for after-the-fact validation of XBRL-based financial reports; but also to drive guidance-based digital financial report creating software, queries of reported information (look at the mappings), etc.
The notion of "Zero Defect XBRL-based digital financial report creation" (see this blog post for more detail) is a collection of values, principles, techniques, and practices. It is a philosophy. The objective is to create an XBRL-based digital financial report which is free from objective mistakes such as logical, mechanical, and mathematical defects. The philosophy is a means to achieving the objective.
Having financial reports free from such easy to agree with objective mistakes lets professional accountants and analysts that interact with such reports be confident in the meaning of the underlying facts being conveyed by the report so that they can focus on the subjective aspects where they add the most value, areas where computer assisted verification of financial reports is impossible because of the limitations of computer capabilities in processing information. (To understand that a computer's ability to process information is not infinite, read this information about the notion of problem solving logic.)
Machine-readable business rules provide a safety net of direct evidence to support report quality and compliance with reporting standards and regulatory rules. With this approach, near zero defects (Sigma level 6, 99.99966% correct) is achievable at a lower cost and higher quality than current manually oriented approaches. Further, quality is verifiable whereas under current approaches since measurements cannot really be taken true quality levels are unknown.
And so, the financial report is verified with the assistance of automated business rules and all such business rules must pass. Business rules are suggestive evidence that a financial report has no logical, mechanical, or mathematical defects. Passing all business rules is not definitive proof that a report is 100% correct in all regards (because business rules could be missing), but the business rules are certainly an excellent first line of defense and if the appropriate business rules are created a very high comfort level is achievable.
This leaves professional accountants to focus on the subjective areas which are beyond the capabilities of machine-based processes to verify.
More to come... Stay tuned!
I have been looking at the problem I have been trying to solve exactly backwards.
Business rule driven XBRL-based financial report creation uses the same philosophy as what Agile programming calls test driven development for creating software. Agile financial report creation yields XBRL-based financial reports which are free from XBRL technical syntax defects, model structure defects, mathematical relations defects, logical defects, and mechanical defects.
This simple example explains the difference between the current approach used to create XBRL-based financial reports which yields quality problems and a better business rules driven approach which yields zero defects, guaranteed.
- Step 1: Provide fact "Assets".
- Step 2: Provide fact "Liabilities and equity"
- Report complete.
Give the steps above, what prevents the creator of a financial report from creating the fact "Assets" with a value of say 1,000; creating the fact "Liabilities and equity" with a value of "1,500"; and then submitting that report to the SEC or other regulator? Nothing prevents the report error above from being submitted to a regulator, even though the report violates the accounting equation. And that is exactly the sort of thing that is going on with XBRL-based public company financial filings to the SEC.
Business rules driven approach:
- Step 1: Create business rule: "Assets = Liabilities and equity"
- Step 2: Create fact "Assets"
- Step 3: Create fact "Liabilities and equity"
- Report complete.
The business rule prevents facts that would violate the accounting equation from inadvertently being created. Software uses the business rule created in Step 1 to monitor the report creation process. Given these steps above, it is impossible to create a financial report that violates the logical relationship specified by the accounting equation, the fundamental rule of accounting. Now, this one rule is provided only as a basic and easy to understand example. Clearly you need more rules. But what rules?
Here are the machine-readable business rules you need:
- Base XBRL Specification Conformance Suite: Provides hundreds of tests to make sure software is implemented consistently with the base XBRL technical specification. Note that XBRL-based public company financial reports curently about 99.99% consistent with the base XBRL conformance suite.
- XBRL Dimensions Conformance Suite: Provides hundreds of test to make sure software is implemented consistently with the XBRL Dimensions technical specification. XBRL-based public company financial reports are currently about 99.99% consistent with the XBRL Dimensions technical specification.
- Model Structure Relations Rules: Provides rules which specify the logical relations between the Networks, Tables, Axes, Members, Line Items, Abstracts and Concepts which make up an XBRL-based taxonomy. XBRL-based public company financial reports are currently about 99.98% consistent with these logical relations.
- Edgar Filer Manual Rules: Provides Edgar system specific rules for public companies submitting XBRL-based financial reports to the SEC.
- XBRL US Data Quality Committee: Specifies different sets of specific rules related to the construction of an XBRL-based financial report.
- Fundamental Accounting Concept Relations Rules: Provides rules which specify the logical, mechanical, mathematical relations between the high-level financial reporting concepts represented within XBRL-based financial reports which may differ based on the reporting style used by a public company. Currently, public companies XBRL-based financial reports are about 98.88% consistent with such logical, mechanical, mathematical relations.
- Disclosure Mechanics Rules: Provides rules which specify the logical, mechanical relations between the report fragments which make up the Level 1 Notes Text Blocks, Level 2 Policy Text Blocks, Level 3 Disclosure Text Blocks and Level 4 Disclosure Details. Currently, it is looking like public companies are between 65% and say 85% consistent with these logical, mechanical relations.
- Disclosure Mathematical Relations: Provides rules which articulate the mathematical relations of the specific disclosures provided by a specific reporting entity to both describe and can be used to verify the roll ups, roll forwards, member aggregations, and other specific mathematical relations of the report. Currently, only roll up relations (XBRL calculations) are provided by public companies and those relations tend to be about 90% or better. Roll forward relations, member aggregations, and other such mathematical relations are not currently represented within public company financial reports and the consistency of those mathematical relations is unknown.
- Reporting Checklist: Provides rules related to which disclosures are required to always be provided, which disclosures are required if some specific line item is material within a financial report, and other such rules.
- Conceptual Model Rules: Provides a thick layer of metadata for working with digital financial reports. Specifies relations and rules which describe and can be used to verify consistency with the digital financial report conceptual model. For more information see the Financial Report Semantics and Dynamics Theory.
I think that is about it for the logical, mechanical, and mathematical relations type rules. There are other rules that are specific to more detailed areas of financial reporting and accounting. These rules start to get into the compliance/noncompliance of regulatory rules. I don't want to go down that path right now.
Think about it this way: It is not about looking at the pieces of a digital financial report and finding pieces that are wrong. It is about looking at the pieces of a digital financial report and proving that all the pieces are right.
This list of rules might seem like a lot, and it is. Professional accountants creating reports and financial analysts using reports will not need to concern themselves with most of these rules. For example, software deals with base XBRL technical specification and XBRL Dimensions conformance. That is low-level stuff business professionals will never need to deal with.
If you want to understand more, please read the document Comprehensive Introduction to Business Rules for Professional Accountants.