Digital Financial Reporting

I created a document, Issues in XBRL-based Digital Financial Reports, which summarizes accounting logic representation issues within XBRL-based public company financial reports submitted to the SEC.  The document contains about 50 easy to understand errors which are explained so that a reader can use the document to understand the error.  Additionally, there is a link to the filing so that anyone can go to the filing and confirm (or refute) the information that I have provided.

There are two pieces of information that help you understand how helpful that document is.  First, here we are five years into the mandate for public companies to file XBRL-based financial information with the SEC.  FIVE YEARS!!!  Software vendors and filing agents are still getting these 22 basic, fundamental accounting concept relations incorrect.  But, if you look at a comparison of periods you see two things: (a) that there are filing agents and software vendors that are getting a high percentage of the financial filings they create consistent with these basic accounting concept relations; and (b) that consistency with these relations are slowly improving: March 2014: 93.92% , March 2015:  97.00%, , March 2016:  98.75%, August 2016: 98.90%.

Second, why did those 8 software vendors/filing agents understand and then correct those errors?  Because I have been providing infomation such as what is in that PDF to as many filing agents/software vendors as I can to help them understand, detect, and correct those sorts of errors.  (No one really ignores the information, some are faster to fix errors than others.) Basically, the PDF is an excellent learning tool for accountants creating XBRL-based digital financial reports.

Public companies and the SEC are the "canary in a coal mine" for digital financial reporting.  The SEC is being pretty tolerant as software vendors, filing agents, accountants, financial analysts, and auditors figure out how to make digital financial reporting work appropriately.  The CFA Institute has an excellent vision of what they call structured data can provide.

Keep in mind that these accounting logic relations need to be checked in every report, for every period.  I am checking only 22 relations between about 40 concepts.  There are probably 1000 to 5000 such relations in the typical 10-K financial statement.  That is way too much to check manually, automated processes are necessary.  To automate processes, you need machine-readable business rules.

XBRL-based digital financial reporting is not likely going away.  Fact is, its use will likely only increase.  Reading the PDF will help you tune your digital financial reporting skills. Want to really understand digital financial reporting?  Here you go!

The Resource-Event-Agent (REA) model is an approach to conceptualizing the semantics of economic exchanges such as accounting transactions. The REA model is an ISO standard, ISO/IEC 15944-4:2007.  (You can download a FREE copy of the 2007 version of the ISO standard, the newest 2015 version requires a purchase. Appendix B: REA Model Background, page 70.)

The REA model is best understood by understanding the "R" the "E" and the "A".

• Resources: Economic resources or claims are objects that are under the control of an economic agent.  Economic resources/claims may things such as goods, services, rights, obligations, claims.
• Event: Economic events are the events, transactions, circumstances, and other phenomena which change economic resources from production, exchange, consumption, and distribution.
• Agent: Economic agents are identifiable parties which obtain, use, or dispose of economic resources.

People seem to use the REA model for various things: describing databases, capturing information about value creation patterns, explaining how to make accounting systems better, and so on.

My interest in REA is simple: use the semantics to represent economic exchanges such as accounting transactions in machine-readable form such as XBRL.  Can I do that?  Well, I already have.  I built an XBRL taxonomy and an XBRL instance to prove the idea.  I want to build a good set of examples before I make my XBRL taxonomy and XBRL instance available.

Here are several resources for more detailed information about REA:

• REA Models video: This is an 8 minute video which provides an overview of the REA model.
• REA Ontology Video: This is a 50 minute video which dives into more detail.
• REA Model Tutorial: Very basic tutorial which takes about 60 minutes to work through.
• What is REA?: An explanation of REA by REA Technology, lists of books and other resources.
• Research papers: A bunch of research papers related to REA provided by Bill McCarthy, the creator of REA.

One obvious question is: What is the difference between XBRL Global Ledger (XBRL GL) and REA?  From what I can tell, REA and XBRL GL tend to do many of the same things.  REA is more top down, big picture, work to the details.  REA is not really a syntax, it is semantics.  XBRL GL is a syntax that also provides detailed semantics.  XBRL GL tends to be bottom up, working from the details to the big picture.  From what I see, REA and XBRL GL tend to be complementary in nature.  REA is an ISO/IEC standard.  XBRL GL is an XBRL International standard.

Why am I interested in REA?  Think drill-down from an XBRL-based financial report to the underlying transactions.  Stay tuned!  I will make my prototypes available, but I want to tune them some more.

In prior blog posts I mentioned semantic reasoners, inference engines, XBRL Formula processors, and other such logic processors (not completely sure what to call these things).

What I was trying to figure out was what sort of application is necessary to process the information contained in an XBRL-based financial report in order to perform sophisticated verification of the information provided in such a structured data document.  One example is accounting and reporting checklists.

One thing that I have figured out is that syntax is not important.  It is semantics that is relevant, particularly the expressiveness of the semantics and the safe implementation of the semantics.  Fads and arbitrary preferences confuse and confound people, making it hard to get a straight answer.

Well, this is what I have figured out.  First, I can articulate all the semantics that I can imagine using XBRL.  As such, it would make sense to use an XBRL Formula processor to process the XBRL instances and related XBRL taxonomy information (including metadata that one can add).

But, all of the XBRL-based business rules and other metadata that I have created to support the creation and sophisticated validation of XBRL-based financial reports of the style that are submitted by public companies to the SEC shows that the currently available commercial XBRL Formula processors (which sit on top of XBRL processors and XBRL Dimensions processors) have specific deficiencies.  Literally, all are deficient.

To overcome these deficiencies, the following capabilities MUST exist or need to be added to XBRL Formula Processors:

• Support normal stuff that high-quality XBRL Formula processors support (i.e. Arelle, UBmatrix/RR Donnelley, Fujitsu, Reporting Standards, etc.)
• Support inference (i.e. deriving new facts from existing facts using logic, what inference engines do)
• Improved support validation and use of structural relations (i.e. XBRL Taxonomy functions; this was consciously left out of the XBRL Formula specification in order to focus on XBRL instance functionality)
• Support forward chaining and possibly also backward chaining in the future (i.e. chaining was also proposed but was left out of the XBRL Formula specification)
• Support a maximum amount of Rulelog logic which is safely implementable and is consistent with ISO/IEC Common Logic and OMG Semantics of Business Vocabulary and Business Rules
• Additional XBRL definition arcroles that are necessary to articulate the Rulelog logic, preferably these XBRL definition relation arcroles would end up in the XBRL International Link Role Registry and be supported consistently by all XBRL Formula processors (i.e. these general arcroles, and these financial disclosure related arcroles; this human readable informationis helpful to understand the arcroles)

If you try and reconcile the pieces of XBRL with the components of an expert system, you can clearly see the specific deficiencies in the capabilities XBRL Formula processors (i.e. the above list).  Here is that reconciliation:

• Database of facts: A database of facts is a set of observations about some current situation or instance. The database of facts is "flexible" in that they apply to the current situation.  An XBRL instance is a database of facts.
• Knowledge base (rules): A knowledge base is a set of universally applicable rules created based on experience and knowledge of the practices of the best domain experts generally articulated in the form of IF…THEN statements or a form that can be converted to IF...THEN form. A knowledge base is "fixed" in that its rules are universally relevant to all situations covered by the knowledge base.  Not all rules are relevant to every situation.  But where a rule is applicable it is universally applicable.  All knowledge base information is machine-readable. An XBRL taxonomy is a knowledge base.
• Rules processor/inference engine: A rules processor/inference engine takes existing information in the knowledge base and the database of facts and uses that information to reach conclusions or take actions.  The inference engine derives new facts from existing facts using the rules of logic. The rules processor/inference engine is the machine that processes the information.  An XBRL Formula processor is a rules processor and, if build correctly, can perform logical inference.
• Explanation mechanism: The explanation mechanism explains and justifies how a conclusion or conclusions are reached.  It walks you through which facts and which rules were used to reach a conclusion. The explanation mechanism is the results of processing the information using the rules processor/inference engine and justifies why the conclusion was reached.  The explanation mechanism provides both provenance and transparency to the user of the expert system.

This functionally listed above is necessary to properly work with XBRL-based financial reports.  Please review the Law of Conservation of Complexity.  Financial reports simply cannot have errors and there is too much detail in a structured data-based report for humans to get right using only manually oriented human-based processes.  There are exactly two ways to achieve this functionality:

1. Improve the capabilities of XBRL Formula processors as indicated above (i.e. add the listed capabilities to existing XBRL Formula processors).
2. Enhance existing business rules engines to support XBRL

If you want to understand better what I am saying here, please read the document Comprehensive Introduction to Expert Systems for Professional Accountants.  If you want an even better understanding, have a look at the Framework for Understanding Digital Financial Report Mechanics.

If you have any feedback to improve what I am saying here, please let me know.  If you know of any other resources that explain this stuff better than I have, please make me aware of those resources.

John F. Sowa's paper Fads and Fallacies about Logic made something very clear.

The challenge of getting XBRL-based structured data financial reports to work correctly for public companies is not a technical problem; rather it is an even more formidable challenge of fads, misinformation, trends, arbitrary preferences, politics, and standards.

This is what I learned:

1. There is a communications chasm between business professionals and information technology professionals.  Business professionals need to cross that chasm by learning how computers work. Fear of technology is uncalled for. (Please read Comprehensive Introduction to Knowledge Engineering for Professional Accountants)
2. Syntax does not matter, it is a technical detail.  Semantics matters to business professionals.  There are so many technical alternatives available, so many things that are not interoperable that should be interoperable, endless philosophical debates and theoretical arguments, and most are a waste of time and energy.  Being practical matters.
3. Business professionals don't need to "learn to code" or even learn technology.  Software developers need to learn to build better software.  To get this, business professionals need to understand what software to ask for.
4. Business professionals need to gain an understanding of logical principles.  Basic stuff like: there exists, every, and, or, if-then, not, true, and false.  Really, it is that simple.
5. The hardest task of knowledge representation is to analyze knowledge about a domain and state it precisely in any language. This is not a technical problem, this is a domain problem. Only business professionals can describe a business domain.  Full stop.
6. Any declarative notation could be treated as a version of logic: just specify it precisely.  XBRL definition relations can be a logic if used correctly.  So can XBRL Formula.  XBRL presentation relations not so much.
7. The logic notations of the middle ages is better than the stuff mathematicians and computer scientists came up with. (see the diagram on page 2, that is logic)
8. The tools that will be created for digital financial reporting will be very powerful.

This is John Sowa's summary of his article:

In summary, logic can be used with commercial systems by people who have no formal training in logic. The fads and fallacies that block such use are the disdain by logicians for readable notations, the fear of logic by nonlogicians, and the lack of any coherent policy for integrating all development tools. The logic-based languages of the Semantic Web are useful, but they are not integrated with the SQL language of relational databases, the UML diagrams for software design and development, or the legacy systems that will not disappear for many decades to come. A better integration is possible with tools based on logic at the core, diagrams and controlled NLs at the human interfaces, and compiler technology for mapping logic to both new and legacy software.

Digital is coming to financial reporting.  Accountants, who came up with the idea for XBRL, are leading the way.  Public company XBRL-based financial reporting to the SEC is showing the way and working out the details.  Standards will be perfected by the market. Per the Law of Standards, things will get simpler; the market will see to that.

Current XBRL Formulaprocessors don't meet the needs of XBRL-based financial reporting.  All of the XBRL-based business rules and other metadata that I have created (i.e. fundamental accounting concept relations, disclosure validation, model structure validation) to support the creation and validation of XBRL-based financial reports of the style that are submitted by public companies to the SEC shows that the currently available commercial XBRL Formula processors (which sit on top of XBRL processors and XBRL Dimensions processors) have specific deficiencies.

To overcome these deficiencies, the following capabilities should be be provided:

1. Support normal stuff that high-quality XBRL Formula processors support (i.e. Arelle, UBmatrix/RR Donnelley, Fujitsu, Reporting Standards, etc.)
2. Support inference (i.e. deriving new facts from existing facts using logic)
3. Improved support structural relations (i.e. XBRL Taxonomy functions; this was consciously left out of the XBRL Formula specification in order to focus on XBRL instance functionality)
4. Support for chaining, specifically forward chaining and possibly also backward chaining in the future (i.e. chaining was also proposed but was left out of the XBRL Formula specification)
5. Support a maximum amount of Rulelog semantics logic which is a set of logic that is highly expressive and safely implementable in software and is consistent with ISO/IEC Common Logicand OMG Semantics of Business Vocabulary and Business Rules
6. Additional XBRL definition arcroles that are necessary to articulate the Rulelog logic, preferably these XBRL definition relation arcroles would end up in the XBRL International Link Role Registry and be supported consistently by all XBRL Formula processors (for example these and these)

If you try and reconcile the pieces of XBRL with the components of an expert system, you can clearly see the specific deficiencies in the capabilities XBRL Formula processors (i.e. the above list):

• Database of facts: A database of facts is a set of observations about some current situation or instance. The database of facts is "flexible" in that they apply to the current situation.  An XBRL instance is a database of facts.
• Knowledge base (rules): A knowledge base is a set of universally applicable rules created based on experience and knowledge of the practices of the best domain experts generally articulated in the form of IF…THEN statements or a form that can be converted to IF...THEN form. A knowledge base is "fixed" in that its rules are universally relevant to all situations covered by the knowledge base.  Not all rules are relevant to every situation.  But where a rule is applicable it is universally applicable.  All knowledge base information is machine-readable. An XBRL taxonomy is a knowledge base.
• Rules processor/inference engine: A rules processor/inference engine takes existing information in the knowledge base and the database of facts and uses that information to reach conclusions or take actions.  The inference engine derives new facts from existing facts using the rules of logic. The rules processor/inference engine is the machine that processes the information.  An XBRL Formula processor is a rules processor and, if build correctly, can perform logical inference.
• Explanation mechanism: The explanation mechanism explains and justifies how a conclusion or conclusions are reached.  It walks you through which facts and which rules were used to reach a conclusion. The explanation mechanism is the results of processing the information using the rules processor/inference engine and justifies why the conclusion was reached.  The explanation mechanism provides both provenance and transparency to the user of the expert system.

This functionally is NECESSARY (i.e. see the Law of Conservation of Complexity) to enable professional accountants to properly work with XBRL-based structured financial reports.  The margin for error is ZERO. If you don't understand this, I would encourage you to read the Framework for Understanding Digital Financial Report Mechanics.

There are exactly two ways to achieve this functionality:

1. Improve the capabilities of XBRL Formula processors as indicated above.
2. Enhance existing business rules engines to support XBRL.

So that is WHAT needs to be done.  I am less clear on HOW to best achieve this.