Effective XBRL-based Digital Financial Reporting

Neither the U.S. Securities and Exchange Commission (SEC) nor the European Single Market Authority (ESMA) implementations of XBRL-based financial reporting information collection schemes works the way that they really need to work.

In fact, in 2008 or 2009 when the SEC's XBRL-based system went live, I told Mike Willis who worked at PWC at the time and now works for the SEC that it was not going to work.  I did not understand precisely why at the time.  I also knew that the ESMA implementation was not going to work because it was essentially a duplication of what the SEC did but using a different XBRL taxonomy (IFRS instead of US GAAP) and an attempt to implement what they called "anchoring" which they seemed to figure would solve all the problems the SEC was encountering.

I spent the next 15 years figuring out precisely why the SEC's implementation was not working effectively and more importantly how to fix what was not working.

So, the first issue related to both the SEC and ESMA implementation of XBRL can be understood by having a look at the Compliance Maturity Model which leverages the Capability Maturity Model. What both the SEC and ESMA did was implement "stuff", they did not create a "process" or a "system" or a "program".  They simply did "stuff" and they therefore had no way of knowing if that "stuff" would work and they don't seem to measure anything to make sure the outcomes they desired are being met because they never really defined the outcomes they desired.

A second issue with what the SEC and ESMA implemented can be seen by understanding the difference between "standardized" reporting as contrast to "customized" reporting.  This paper, Critical reflection on XBRL: A “customisable standard” for financial reporting?, provides an excellent graphic which explains the difference between "standardized" and "customized" reporting approaches.  But what they don't make crystal clear is the different between "freeform" customization as contrast to "controlled" customization.  Building on that paper's graphic, I created this enhanced version of that same information:

US GAAP and IFRS financial reporting is not "standardized" reporting where standardized means "form".  Both US GAAP and IFRS financial reporting are "customized" reporting approaches because the creators of financial reports are permitted to modify the report model within specific boundaries.

Note that phrase "within specific boundaries". How US GAAP and IFRS financial reporting work is explained in my document Essence of Accounting.  Reporting entities have flexibility to use different subtotals to summarize reported information, different alternatives exist to report the same information, things can be organized (presented) in many different ways.

However, this does not mean that US GAAP and IFRS reports are random. There are definitely patterns.  These patterns can be grouped into the buckets of the Cnyefin Framework.  Over a period of about 15 years, I went through what I came to understand was a process of "sensemaking" and figured out the essence of how financial reporting really worked.

That led me to understand that financial reporting and the audit of financial reports were terribly and fundamentally broken.

A financial reporting scheme is supposed to specify what an economic entity is supposed to report to a regulator such as the SEC or ESMA.  A financial reporting scheme should provide:

• Description: A financial reporting scheme should be a clear and complete description of a report model (specification of what is required); created by standards setters or regulators or anyone else specifying a report.  And obviously the clear and complete description should represent accounting and reporting rules precisely and accurately.
• Construction: A financial reporting scheme should be a guide to the creation of a report based on that permitted report description.
• Verification: Accountants creating reports and auditors independently verifying to be sure that reports have been created consistent with the description.
• Extraction: Financial analysts, investors, regulators, and others enabling the process of using information from reports should be able to do this effectively.

In a word "clarity" needs to exist in the system in order for the system to work effectively to meet the needs of all those that participate in this system.  But today, there are errors in financial reporting schemes, ambiguity in financial reporting schemes, financial reporting has become extremely complex, many mistakes are being made, audits are failing, and so forth.

But the same technology that is both creating the problems of information volume and information complexity, issues with describing a financial reporting scheme effectively and clearly, and physically exchanging that information with others; that technology will also solve our current problems.

The Great Transmutation is about a paradigm shift in financial accounting, reporting, auditing, and analysis.  People refer to this paradigm shift in different ways.  Here are how some people package this paradigm shift:

• MIT refers to this as Algorithmic Business Thinking 
• Carnegie Mellon University refers to this as Computational Thinking
• Harvard University refers to this as Regulation, the Internet Way
• Vanderbilt University refers to this as Regulation 2.0 
• The Data Coalition calls this Smart regulation 
• Tim O’Reilly Founder and CEO O'Reilly Media Inc. calls it Algorithmic regulation 
• Deloitte refers to this as “The Finance Factory” and Digital Finance 
• Robert Kugel of Ventana Research calls it “Digital Finance” 
• The government of Norway calls this “Nordic Smart Government and Business”

What the SEC and ESMA need to do is to help those they regulate to understand that they need new capabilities to be in compliance in the future.  The SEC and ESMA need to think about what they are doing as a "process" or a "system" or a "program" rather than just a bunch of stuff which might not be the right stuff.

XBRL-based financial reporting can be clearly understood by simply applying XBRL to something as basic as the accounting equation.  I wish I would have understood this back in 2008/2009 when I was trying to figure out how to make XBRL-based reporting work.  My system for XBRL-based reporting is summarized in the Seattle Method.  Undoubtedly, the SEC and ESMA can do better.  Eventually, they probably will.

In fact, I am optimistic that accounting, reporting, auditing, and analysis will all be overhauled over the next 25 years.