Digital Financial Reporting

Imagine that you actually wanted to make use of XBRL-based information for analysis of the financial information of companies.  What exactly would you need to do?

First, you have to perhaps go to the RSS feed the SEC provides for filings.  You have to grab the filings you want to analyze.  You have to get the information from the filings.  You have to adjust for errors in the information. Etc.

Well, here is some data to play with.  This is for a set of 15 companies, about 8 years of machine readable information, all 15 entities use exactly the same reporting style, I picked companies where there is a minimal amount of errors in the reports so there is not a lot of adjustments needed for mistakes.

Here is a test set of filings that you can use.  I provide pointers to the filings.  I have tested the information to make sure there are not many errors.  The information is for 15 banks, each of their filings, 10-Qs and 10-Ks since the SEC started using XBRL:

1. List of reports in human readable form. (Just to visualize what is here)
2. Same list in machine readable RSS. (Computer can work with this)
3. Extraction/validation tool. (This shows you how to put the pieces together; however, the mappings, impute rules, and consistency checks are HARD CODED)
4. Metadata (mapping rules, impute rules, consistency checks) for all companies. (Allows you to dynamically map, impute, and test for consistency for any of the 76 reporting styles)
   1. Schema for rules for this specific reporting style.
   2. Mapping rules.
   3. Consistency checks and impute rules. (This is by network)

Let me know what you come up with.

In September 1998, at about 10 AM or so, I started a presentation to the AICPA High Tech Task Force related to XML-based financial reporting.  By noon that same day a plan was in place to get Barry Melancon, president of the AICPA then and today, to approve the creation of a prototype to test the idea.  That September meeting started a process of what was to become XBRL.

Almost 20 years later, I have personally achieved what it was that I wanted to achieve: creation of an expert system for creating financial reports.  That software was created by Hamed Mousavi, a software engineer, and myself.  It took us almost five years.  Most of that time related to figuring out how to do it.  I explain to software engineers and professional accountants how we did this in the document, Guide to Building an Expert System for Creating Financial Reports.

Are their better ways? It is hoped that the ideas Hamed and I are sharing in this document will start a discussion and that the collective wisdom of the institution of accountancy will correct what we may have gotten incorrect.

Most of the ideas in this document come from discussions and feedback that we received over the past 15 or so years from many, many colleagues who are too numerous to list.  In gratitude for that assistance we make this information available. That input was critical to shaping the thoughts and ideas expressed in this document. Collectively, thank you to the entire XBRL community!

Sedona, Arizona; September 1998:

(Click image for larger view)

Stay tuned to see accounting, reporting, auditing, and analysis change to better operate in a digital environment. 

An XBRL-based report is made up of facts (i.e. the "data" reported) and a model (i.e. the structure and other relationships between the facts).  An XBRL instance articulates the facts; an XBRL taxonomy articulates the model.

The accounting equation is an excellent example of the power of a symbiotic collaboration of fasts and a model.  The accounting equation seems simple: assets = liabilities and equity.  But don't under estimate that simple model.  Accounting rules created over the years have built upon that fundamental model:

• Assets = Current assets + Noncurrent assets
• Liabilities = Current liabilities + Noncurrent liabilities
• Equity = Equity attributable to parent + Equity attributable to noncontrolling interest

One could go on building out those relations. For example, I have.  Here are high-level relations for US GAAP and IFRS. You can see human-readable and machine-readable versions of those high-level relations.

Now, not every company has exactly the same high-level relations.  For example, both US GAAP and IFRS have the notion of a classified balance sheet which breaks down assets and liabilities into their "current" and "noncurrent" categories.  Banks and other companies don't use the current/noncurrent distinction; they use an unclassified balance sheet or also called an order of liquidity balance sheet presentation.

I addressed those different approaches to organizing these high-level financial concepts in the model I created by introducing the notion of a "reporting style".  A reporting style is simply patterns of how companies report their financial information.  I have the reporting styles for US GAAP and IFRS.  This document related to IFRS reporting styles is the best documentation for understanding exactly what a reporting style looks like.

Now, I did not make this stuff up.  All I did was observe empirical evidence and organized things.  Here is my evidence for US GAAP and for IFRS.

On the one hand, one of the most unfortunate distinctive peculiar features of both the US GAAP XBRL Taxonomy and the IFRS XBRL Taxonomy is that they were both created to be "pick lists" of 'tags".  There were a lot of reasons this happened.

On the other hand, neither the FASB (maintainer of the US GAAP XBRL Taxonomy) nor the IFRS Foundation (maintainer of the IFRS XBRL Taxonomy) had the benefit of thousands of XBRL-based financial reports that are machine-readable when they initially created their taxonomies.

However, now they do.  Both IFRS and US GAAP XBRL-based reports have been submitted to the SEC and are just sitting their waiting to be used for all sorts of things.  One really good use of those XBRL-based financial reports is feedback on how to create XBRL taxonomies.

The FASB and IFRS Foundation should take advantage of this opportunity.

But the most unfortunate consequence of the US GAAP XBRL Taxonomy and IFRS XBRL Taxonomy being "pick lists" is a bunch of software vendors that have been led down the wrong path.  Rather than being able to leverage the XBRL taxonomies for US GAAP or IFRS; software has to "fight" the taxonomies to overcome the deficiencies.

That costs software vendors dearly in terms of functionallity that these vendors could offer the users of the software, quality problems in the financial reports created, increased software development costs, among other issues.

The FASB, IFRS Foundation, SEC, ESMA, software vendors, XBRL International, investors, data aggregators, and the public/listed companies that have to all interact with XBRL-based reports don't act as if they had an interdependent relationship where cooperation serves everyone.  How unfortunate.

The losers?  Basically everyone.  Increase costs, quality problems, unsatisfied potential users of the information.  How very unfortunate.

The solution?  Recognize the interdependent nature of the relationship and cooperate.  Maybe I am being naive.  But I would rather be naive than participate in this problem.  So, I just build my own metadata to work around the dysfunction.

Answer Set Programming (ASP) is a declarative logic problem solving approach based in stable model semantics.  It is tailored to modeling problems in the area of knowledge representation and reasoning (KRR). Frankly, most of this is over my head.  But, answer set programming seems like it is a step in the right direction.  Here are some resources:

• University of Vienna
• Knowledge Representation, Reasoning, and the Design of Intelligent Agents The Answer-Set Programming Approach
• Potassco
• Answer Set Programming Tutorial
• Online demo
• Clingo
• Answer Set Programming in Practice

It seems like answer set programming is similar to description logic.

Continuing on with my analysis of IFRS reporting styles I have created an additional temporary reporting style code for the income statement.  The reason I created this temporary code is that the ISXXXXX basically turns off all of the income statement tests until I can establish the pattern of the income statement that has this code.

What I figured out is that I can turn half of the income statement tests on if I simply start at the income statement line item "Income (loss) from continuing operations before tax".  I can then test 5 relations, easing into the final reporting style. The code I used was ISNATU0.

When I did created this code and the supporting Excel validator, I realized that almost all 406 IFRS filings have those 5 relations.  I have seen only ONE IFRS filing that breaks this pattern, reporting "income (loss) from equity method investments and joint ventures" within their tax provision essentially.

So what I did was put all 406 IFRS filings into one Excel spreadsheet validator and checked the filings consistency with those five rules of the ISNATU0 code.  What I found was this:

• 335 filings, or 83% of all filings, were consistent with all 5 of the income statement rules that I added.
• 70 filings, or 17% of all filings, were INCONSISTENT with one or more income statement rules.
• On a per test basis, 107 (5%) test were inconsistent with expectation and 1,923 (95%) were consistent with expectation.  (406 filings times 5 tests).
• Of the 107 inconsistencies, I confirmed that 25 were filer errors and documented those errors.  That means that actually only 82 are not confirmed to be consistent with expectations (i.e. there could be an error in my test or an error in the IFRS XBRL Taxonomy)

Here are the POSITIVE and NEGATIVE test results for this ISNATU0 set of filings.