Digital Financial Reporting

One of the significant issues with XBRL-based public company financial reports to the SEC is that there is no one set of consistency checks that everyone uses to check their digital financial reports.  The SEC has its Edgar Filer Manual (EFM) tests (interactive data public test suite), XBRL-US has their consistency suite, XBRL Cloud has their tests, I have my fundamental accounting concepts and minimum criteria tests, and I suppose that each software vendor has proprietary tests and checks that they do.

What there really needs to be is ONE set of consistency checks that is used by everyone, not different versions of tests and checks which cause different versions of consistent and inconsistent.

I have made available all of my fundamental accounting concepts work free of any restrictions at all to XBRL US or anyone else for that matter.  I really hope they take advantage of that work.  I would encourage everyone to encourage the XBRL-US Data Quality Committee to consider leveraging this work.

All of this can be downloaded here.  Perhaps what I am doing is more sophisticated that what XBRL-US is doing right now or willing to take on.  However, the fundamental accounting concepts offers important information about how to best create the US GAAP XBRL Taxonomy and tests which will be important down the road.

I don't know if people remember my state-of-the art example of using XBRL definition relations.  These are more along the lines of what is really needed to get XBRL-based digital financial reports dialed in correctly. Those consistency checks will make more sense when software starts guiding professional accontants in the creation of financial reports (i.e. expert systems).

People will eventually figure this out. What about you?  Are you going to be proactive and therefore ahead of the curve or are you going to be reactive and therefore behind the curve playing catchup?

Each strategy has it pros and cons.  But either way: things are about to change big time.

In a prior blog post I described how digital financial reporting will work in the future at a very high level.  Notice at the very bottom of that blog post where I very briefly described Process Execution through Application Ontologies. It turns out that the notion of "process execution through application ontologies" is known by another term:  expert systems.

In yet another blog post I provided some high-level information about semantic technologies.  Included within that set of information was a link to a book, Systematic Introduction to Expert Systems, by Frank Puppe.  I bought that book from Amazon.com.  You can read the first chapter and a few other parts of the book here on Google Books.

So what is an expert system?  I found the following definitions that I like and that will serve my purpose here:

Expert systems are computer programs that are built to mimic human behavior and knowledge.

A computer application that performs a task that would otherwise be performed by a human expert.

Frank Puppe explains in his book that there are three general categories of expert systems:

• Classification or diagnosis type: helps users of the system select from a set of given alternatives.
• Construction type: helps users of the system assemble something from given primitive components.
• Simulation type: helps users of the system understand how some model reacts to certain inputs.

A digital financial report creation tool is basically an expert system that helps its user, a professional accountant, assemble and generate an external financial report.  The final product, the financial report, could be generated in human-readable form like the HTML, PDF, or word processing document-type outputs; and/or in machine-readable form such as XBRL or RDF/OWL.

Chapter 21, Review of the Problem-Solving Type Construction, of Frank Puppe's book describes in detail how this would work.

Remember my blog post, Understanding Blocks, Slots, Templates, and Exemplars? Remember the two documents Understanding the Basic Mechanics of a Digital Financial Report and Understanding the Mechanics of an SEC-type XBRL-based Digital Financial Report?  This stuff might make more sense to you now.

But most importantly, the document Knowledge Engineering Basics for Accounting Professionals helps one understand how to get a machine to do useful stuff.  Nonsense in, nonsense out.

Many people probably think that I am nuts and that a computer could not possibly be any more helpful than it is being today in the process of creating a financial report.  Others may understand what I am saying and believe me.  Time will reveal who is right.  Where do you weigh in?

Every craftsman values good tools.  While a trained craftsman can use any tool and likely still do a better job than an unskilled or under-skilled person performing the same task; craftsmen still value good tools.

Also, a good tool can turn an under-skilled person into a more highly-skilled person if the tool reduces ignorance (i.e. provides increased knowledge).

What can be a problem is if a lesser-skilled person is unaware of things they should be concerned with but the tools they use don't help them to overcome this deficiency in skill or experience.

Accounting professionals working with digital financial reports such as XBRL-based financial filings to the SEC suffer from a lack of quality tools.  The good thing is, that is changing.

I figure that I am 100 times more productive today than I was only one year ago.  This is no exaggeration.  Click on the image below and look at the interface that I created for reviewing public company XBRL-based financial reports:

(Click image for larger view)

The inconsistency is not visible at all in the actual filing, everything foots correctly and everything else looks just fine.  But if you notice the review tool on the left that shows the YELLOW cell, you immediately understand that something is up.  If you look closely, you notice that this filer used the concept "us-gaap:AssetsNoncurrent" incorrectly.  That concept includes property, plant, and equipment per the US GAAP XBRL taxonomy but if you look at the assets section of the financial report, you see that PPE is not included in the total used to express the fact they are reporting.

So, there are two errors here really.  The first error is that the concept the reporting entity is looking for does not exist in the US GAAP XBRL Taxonomy.  It needs to be added, that is the first issue.  The second is that rather than creating an extension concept, the filer picked some concept that to them seemed close. This conveys the wrong information.

Those are the sorts of issues the fundamental accounting concepts and relations makes very easy to see.  Two very, very positive things are happening.  First, tools are improving.  Second, lots of accountants have experience with using XBRL now after five plus years of creating digital financial reports.

But unfortunately, these sorts of nuances can be hard to recognize with less than optimal tools.  So accountants, pester your software vendors for better functionallity. 

Here is another screen shot, this time with a digital financial report which is consistent with expectation:

(Click image for a larger view)

This tool I built myself using Microsoft Access fiddling around with pieces of functionality provided by XBRL Cloud.  The tool provides a side-by-side comparison of a financial report with a validation report used to check the consistenty of the financial report.  It make it easy to figure out why there is some sort of inconsistency.  If you want to know more about this, send me an email and I can provide additional information.

Introducing (drum roll.......) the US GAAP XBRL Taxonomy Commentary Linkbase!

OK, so it only has two entries currently, but that is not the point.  The point is, Digital isn't software, it is a mindset.  If you understand how financial reporting is going to work in the future then you understand that being able to represent knowledge in machine-readable form is a good thing.

I created the commentary linkbase using Microsoft Access as a working prototype. You can download the Microsoft Access database here.  Don't understand how to program?  Well, maybe you want to learn.  Don't understand XBRL.  Well, this is a way to learn about XBRL.

What I am going to use the commentary linkbase for is to help public companies get the fundamental accounting concept relations correct. What will you use it for?

The quality of public company XBRL-based digital financial reports increased yet again.  This month 3 generators (software vendors, filing agents) reached the point where 80% or more of their filings where consistent with a set of fundamental accounting concept relations.

A few data points are worth pointing out.  First, the sum of errors in all filings related to these fundamental accounting concept relations is about to drop below 3,000.  Right now, the sum of all errors is 3,001.  Contrast that to the 12,259 total inconsistencies for the 2013 10-Ks and and 4,463 total inconsistencies for the 2014 10-Ks.

Second, if you look at the graphic on the very bottom you can see that consistency with each test is now above 95% for every test except for one which is at 94.98%.  Next month, every test will likely be above 95%.

Here is a comparison across time which shows total reports as the blue bar and total number of 100% consistent public company XBRL-based financial reports which is the red line:

(Click image for larger view)

Here are the results summarized by generator:

(Click image for larger view)

Here are the results summarized for the individual tests:

(Click image for larger view which includes test description) 

You can find the human-readable and machine-readable versions of of the consistency checks used to test these fundamental accounting concept relations here.

I am changing the way I evaluate consistency with these fundamental accounting concept relations tests slightly going forward.  In the past, I have combined the consistency checks with the machine-readability checks.  My rational is as follows.  In the past I have had the mantra,

"Prudence dictates that using financial information from a digital financial report not be a guessing game."

There are two parts related to achieving machine-readability of the financial information reported by public companies.  The first is the consistency of the fundamental accounting concept relations which are expected.  The second is providing adequate information for a machine to be able to decipher the information.

The first, consistency with expected relations, is a US GAAP accounting issue.  Basically, using the wrong concepts or mathematical errors are accounting consistency issues.

The second, the ability of a machine to be able to correctly decipher information is not a US GAAP accounting issue.  There are plenty of perfectly legal US GAAP ways to report information that my rather unsophisticated algorithms for reading reported information cannot read.  If the software algorithms were more sophisticated, I could read the information.  Basically, public companies don't have to report so that simple algorithms can read their reported information.  In my personal opinion it would be better if algorithms were easy to create, that minimizes the guessing game and increases the probability of software vendors creating software get algorithms right.

And so, I have found a way to distinguish these two different things.  I will explain this next month when I roll this new approach out.  Also, because the number of inconsistencies is getting so low, I am able to summarize every inconsistency category.  This will help understand inconsistencies and tune the US GAAP XBRL Taxonomy.  Stay tuned.