Digital Financial Reporting

This is probably one of the best examples of the problems caused when a machine is forced to imply information.  It is an example of where one error can lead to another error which masks the first error. It is also an example of the consequences which occur when a filer in essence redefines the meaning of a concept by using a concept in a different way than it was intended.

I will use this AT&T filing to make my point.  I am not picking on AT&T, it is just that I happen to run across this in my tuning of the fundamental accounting concept impute rules.

If you look at the income statement of AT&T, focusing on the operating income section: 

The income statement looks straight-forward enough.  Note the line item "Total operating expenses".  If you examine the concept using the SEC interactive data viewer, you see that the filer used the concept us-gaap:OperatingExpenses to represent that fact:

However, if you examine the US GAAP XBRL Taxonomy, you notice that the concept Operating Expenses does not include Cost of Revenue.  The total of Cost of Revenue and Operating Expenses is the concept Costs and Expenses:

However, if you take a look at the AT&T income statement again, AT&T included the line item "Costs of services and sales" within the line item Total operating expenses.

So, the problem is that AT&T should have used the concept us-gaap:CostsAndExpenses to represent the line item they refer to as "Total operating expenses". While the label is similar to the concept they did use, the meaning of what they are representing matches the concept Costs and Expenses which includes Cost of Revenue.

The problem is that my fundamental accounting concept relations conformance testing did not pick up this error.  The impute algorithm imputed a value incorrectly.  So, the error made by the filer who used the wrong concept is masked by an error in the impute algorithm which imputed a value incorrectly. The results of my validation report did not show any errors.

But I found this when I looked at the validation report.  Now, a human can figure out that an error occurred by looking at the information, but a machine stumbles over this and does not realize that it made an error.  But if I never happend to look at the report, I would not detect the mistake.

This is why it is better to explicitly provide information rather than force a machine to try to imply a fact.

XBRL International released a document, XBRL Taxonomy Guidance Document, which is a very good step in the right direction when it comes to building XBRL taxonomies. The focus is using the XBRL technical syntax correctly. That is only a portion what a taxonomy author needs to understand when they are representing information about a business domain in machine-readable form.

Over the years I have run across the following books which are extremely helpful in trying to understand digital financial reporting.  I strongly recommend that for anyone who wants to understand digital financial reporting well or who want to build rock-solid products/solutions to read the following books:

• Data and Reality, by  William Kent: (First and last chapter are best, entire book is useful) The primary message of the Data and Reality book is in the LAST CHAPTER, Chapter 9: Philosophy.  The rest of the book is EXCELLENT for anyone creating a taxonomy and it is good to understand, but what you don't want to do is get discouraged by the detail and then miss the primary point of the book.  It provides something useful.  The goal is NOT to have endless theoretical/philosophical debates about how things could be.  The goal is to create something that WORKS and is USEFUL.  A shared view of reality. That enable us to create a common enough shared reality to achieve some working purpose.  Actually SEEING it work (i.e. prototype) PROVES that it works, let you see and understand HOW it works, and help one see how to make it work even better. 
• Everything is Miscellaneous, by David Wenberger:  (Entire book is useful) This is very easy to read book that has two primary messages:  (1) Every classification system has problems.  The best thing to do is create a flexible enough classification system to let people classify things how THEY might want to classify them, usually in ways unanticipated by the creators of the classification system.  (2) The big thing is that it explains the POWER of metadata.  First order of order, second order of order, and third order of order.
• Models. Behaving. Badly., by Emanual Derman:  (First half of the book is useful) If you read the Financial Report Semantics and Dynamics Theory, you got most of what you need to understand from this book.  But the book is still worth reading.  It explains extremely well how it is generally one person who puts in a ton of work, figures something out, then expresses extremely complex stuff in terms of a very simple model and then thousands or millions of people can understand that otherwise complex phenomenon.
• Semantic Web for the Working Ontologist, by Dean Allenmang and Jim Hendler:  (First two chapters) This is an extremely technical book, but the first chapter (only 11 pages) explains the big picture of "smart applications".  It is awesome.  It also explains the difference between the power of a query language like SQL (relational database) and a graph pattern matching language (like XQuery).  Querying can be an order of magnitude more powerful if the information is organized correctly.  That is why picking the correct data storage format is important.

I would recommend reading the books in the order listed.  The investment in time to understand this information will avoid going down the wrong path.

Back in April 2014 as part of the minimum criteria testing I was doing, I observed that the percentage of public company filings which conformed to all of the fundamental accounting concept relations was 25.6% (1711 filers).

Last month I pointed out that the percentage of public companies which conformed to all of these relations was 53.1% (3863 filers).

I ran the same test for the last filing of every public company which reports to the SEC today and the percentage that conform to all of the fundamental accounting concept relations is now at 61.9% (4334 filers). You can see the graphic below which breaks this information out by generator (filing agent or software used).

This rapid growth rate is expected to continue for three reasons:

1. These relations between fundamental accounting concept relations is not really controversial and it is increasingly easy to understand and correct the errors.
2. I have provided a substantial amount of information here which helps those who want to correct these issues. This recently added analysis shows that each of these tests can precisely detect not only nonconformance to these relations, but also generally the reason for nonconformance.
3. I know of at least one commercial implementation of software which can be used to detect and therefore correct these issues, XBRL Cloud. This testing will appear on XBRL Cloud's Edgar Dashboard at some point.

If you look at the numbers below and compare them to the prior results you will see that pretty much every generator is improving.  I pester software vendors to include this testing in their products to help them understand that their software can help external financial reporting managers avoid errors like these.  But more importantly, I am trying to get software vendors to realize that this is only the tip of a much, much bigger iceberg. This is a digital disclosure checklist summary which I created several months ago. This shows you where things are headed.

These rules may seem annoying to software vendors.  I can tell you two things.  First, external financial reporting managers already have to comply with these rules. They are just doing so using time consuming and expensive manual processes.  Second, automate these tasks by leveraging the XBRL-based structured information and you will provide something very useful: reducing the risk of noncompliance.

It is these rules which will make the quality of public company financial information submitted to the SEC to be at a level to make it safely, reliably, predictably usable by machine-based automated processes. If you don't understand digital financial reporting, the risk of becoming a relic of the past is increasing every day.

(Click image for larger view)If you don't want to become a relic of the past era of paper-based financial reporting, understand how digital financial reporting really works.  Digital financial reporting is not only inevitable, it is imminent.

If you want to understand the moving parts and you can walk through an Excel macro, the prototype Excel application on a link at the bottom of this page can help you understand the important moving pieces.

Digital is not software, it is a mindset!