Digital Financial Reporting

Below are links to PDF files that have high-quality documentation of approximately 380 errors that exist in XBRL-based financial reports of public companies which and been submitted to the SEC as of March 1, 2017. I detected these errors as part of my measurement of the fundamental accounting concept relations and the continuity errors discovered as part of those cross-checks.

Examining and understanding these errors can help professional accountants improve their skills in working with XBRL-based digital financial reports and software developers create software useful to business professionals that help them not make these sorts of mistakes.

I created this information so that I could provide it to professional accountants who were not detecting these errors when they created their XBRL-based financial reports.  Over the past several years I have made this information available to filing agents and software vendors which they used to understand and fix these sorts of errors.  These 380 errors are about one quarter of the remaining high-level errors in the set of about 7,000 public company financial reports.

These errors tend to be very uncontroversial.  Proof of that is that software vendors and filing agents, once they are made aware of these errors; fix these errors.  For example between 2015 and 2017; Merrill went from 55% consistent to 97% consistent; RR Donnelley went from 73% to 98% consistent; DataTracks went from 62% to 98% consistent. (See the comparison of periods here.)

All of these errors were detected using processes that have been implemented in commercial software. For example, here is a tool provided by XBRL Cloud which they make available on their Edgar Dashboard.

None of these errors are related to the XBRL techical syntax.  The errors all relate to employing XBRL to convey meaning.  These are logical, mechanical, and mathematical mistakes made by the creators of the reports.  Software needs to support the functionallity to detect these sorts of errors.  Here are a few examples of the patterns of errors that you find in the XBRL-based financial reports of public companies: (documented by the PDFs provided below)

• Reporting contradictory/conflicting information. For example, reporting "revenues" facts that contradict one another.
• Using concepts incorrectly relative to other concepts. For example, WHOLE/PART relations that are wrong such as using "us-gaap:CostOfRevenues" (DIRECT operating expenses) as a PART OF "us-gaap:OperatingExpenses" (INDIRECT operating expenses) when they should have used the concept "us-gaap:CostsAndExpenses" (TOTAL DIRECT + INDIRECT operating expenses)
• Simply using the wrong concept.  For example, a common error that you will see is using a concept that relates to "Other comprehensive Income" to represent a line item related to "Comprehensive income" because an incorrect concept was mistakenly selected.
• Creating completely XBRL valid relations, but the relations either is inconsistent with the US GAAP XBRL taxonomy or literally CHANGES THE MEANING of US GAAP.
• Creating unjustifiable extension concepts.  For example, a handful of public companies create the extension concept "my:TotalAssets".  Really?

Each of these errors are logical errors, mechanical errors, or mathematical errors which have NOTHING to do with XBRL technical syntax.  Each error was represented using PERFECT XBRL technical syntax; but the information conveyed was just wrong.

Principles help you think about something thoroughly and consistently.  As a result of my measurement of the fundamental accounting concept relations, I created the XBRL-based digital financial reporting principles.  They help you think about XBRL-based reports.

This information should be very helpful to professional accountants creating XBRL-based reports and software developers building tools those professional accountants use.  There are those reports grouped by audit firm.  I am not saying that any of these audit firms have responsibility for any of these inconsistencies, I am simply making this information available in this form because I also sent this information to each audit form to help them understand these sorts of errors. (April 2017)

• BDO:
  • BDO1
  • BDO2
  • BDO3
• EY:
  • EY1
  • EY2
  • EY3
  • EY4
  • EY5
• KPMG:
  • KPMG1
  • KPMG2
  • KPMG3
  • KPMG4
• PWC:
  • PWC1
  • PWC2
  • PWC3
  • PWC4
  • PWC5
• Deloitte:
  • Deloitte1
  • Deloitte2
  • Deloitte3
  • Deloitte4
• Other
  • Grant Thornton
  • Moss Adams
  • DeCoria, Maichel & Teague

Happy learning! Oh, if you are wondering why I am taking time to put together the business rules for discovering there errors; have a look at the components of an expert system and/or check out my little expert system for creating financial reports. The rules contribute to making the expert system work.

Remember when I posted that I had created the world's first machine-readable financial reporting checklist?  Well, I now have a machine that can read that checklist.

I believe that a software developer and myself have created what I can honestly call the world's first expert system for creating financial reports (as far as I am aware). 

But what is even more interesting is that what drives this expert system is a global standard XBRL-based general purpose business reporting expert system.  The system is both in the form of a tool that is very approachable by business professionals and an API interface. 

There are many sources for defining what an expert system or what people are now tending to call "knowledge based systems".  This web site points out two very important things.  First, the components of an expert system.  Secondly, which is even more interesting, is a discussion of a notion of a general purpose expert system.  Imagine an expert system where the syntax of the fact database and knowledge base is a global standard: XBRL. 

The diagram at the bottom of this post explains the components of an expert system.  Here is how we implemented those expert system components in our software:

• Knowledge acquisition: The domain knowledge which was represented represented in the form of machine-readable business rules were created manually (i.e. not via machine learning). And so, the application has interfaces for creating business rules.
• Knowledge base of rules: The knowledge base of rules is represented 100% using the XBRL technical syntax.  The knowledge base of rules includes an XBRL taxonomy schema, XBRL linkbases, and XBRL Formulas.  I defined some XBRL arcroles that are used in the XBRL definition relations to represent specific types of relationships.
• Fact Database:   The fact database is an XBRL instance or set of XBRL instances.  My fact database can be from ONE XBRL instance such as a single financial report, all the different periodic reports of one entity, the reports for some set of economic entities that report, or all the way up to every XBRL instance that makes up the SEC EDGAR database.
• Reasoning, Inference, Rules Engine:  The reasoning/inference/rules engine is an XBRL processor + and XBRL Formula processor + additional processing that overcomes specific deficiencies in the XBRL Formula specification.  The primary deficiencies relate to a lack of chaining (we support forward chaining, a lack of inference logic to derive new facts using the rules of logic, and deficiencies in specific types of problem solving logic (which we added via the XBRL arcrole definitions).
• Justification and Explanation Mechanism:  The justification and explanation mechanism provides information, generally in a controlled natural language type format, which is very readable and understandable to business professionals and an "audit trail" that enables a business professional to trace any piece of information all the way back to its origin within a financial report fact or knowledge base business rule.

Using the notion of "profiles", the application supports US GAAP-based financial reporting, IFRS-based financial reporting, what I call a "general profile" that provides an architecture and any business reporting scheme simply has to supply the metadata for that reporting scheme.  Here is a brief initial video that I have created to help show the GUI.

Here is a document that helps you understand the current validation capabilities of the application. Why is this important to understand?  Because it helps you understand the knowledge that is in the applications knowledge base of rules and the capabilities of the reasoning/inference/rules engine.

In my view the approach that we took to create this application is very interesting and provides insight that would help others leverage the XBRL global standard.  We are very happy to help others who want to understand what we believe we have created.  If you want additional information, please contact me.  Additional information will also be provided on my blog. 

Components of an Expert System:

(Click image for larger view)