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.