Digital Financial Reporting

Dr. Ghislain Fourny, a computer scientist for 28msec, has written a freely available book about XBRL oriented toward professional software engineers, architects, and developers: The XBRL Book: Technical, Simple and Precise.

Ghislain brief description of the book is:

Put simply, this book is the simple and precise starting point I wish I had had when I first encountered XBRL. Most of these pages do not require any XML or XML Schema knowledge, except for the one section in each chapter that goes into details about the syntax -- but the latter can easily be skipped on a first read.

If you want to see some of Ghislain's handiwork, check out SECXBRL.info.

In another blog post I explainedseven myths about quality issues related to public company XBRL-based financial reports submitted to the SEC.

So what actualy does cause quality issues? Based on measurements and testing that I have been doing for about five years, this is what I see from those measurements/testing.  Below are common specific categories of basic errors that are still far too common:

• Using wrong concept: One common error is the public company simply using the wrong concept.  For example, using the concept "us-gaap:AssetsNet" when the concept "us-gaap:Assets" should have been used as with this public company.
• Inappropriate extension concept: Creating and using an inapproprate extension concept is a common error.  For example, creating an extension concept "jkdg:TotalAssets" like this filer did, rather than using the existing US GAAP XBRL Taxonomy Concept "us-gaap:Assets". Particularly if the filer (a) created an extension for a very high-level concept such as assets and (b) did not provide justification for the extension in the documentation they provide with the concept. NOTE: Not all extension concepts are inappropriate.
• Using a PART as a WHOLE; or WHOLE as a PART:  A far less understood but common error is reversing the "PART" and the "WHOLE" of a part-whole relation.  So for example, this filer provides an example of this. You may want to read the entire document to best understand the issue.  A simple explanation of this issue is that the concept "Health Care Organization Revenue" is the grand total of all health care related revenue that an organization can have.  But the filer used it as a PART of another revenue concept, thus a PART of the grand total is used as the WHOLE.
• Using a PART and a WHOLE together as PARTS: Again, less understood but a common error is where a PART and a WHOLE are both used as PARTS.  Example #2 here in this document provides an example of this mistake. One of the two line items that are used to reconcile "Net income" to “Numerator for basic earnings per share” is the GRAND TOTAL into with the other concept is a PART.  This is a logic error.  Read the entire document to understand that specific error better.
• Reversing the polarity of a numeric value: Example #8 in this document shows where a filer puts in a negative value, then negates the label so it renders as a positive; but should have simply entered a positive value to make the math of the relations work correctly. Reversed values are each to catch because the amount of the error is double the amount of the value.  Accounting trick!

There are many, many other categories of errors in XBRL-based financial reports.  While manual effort can detect these sorts of errors, and others; automated machine-based processes tend to be more reliable.  With all the details contained withing an XBRL-based financial report, it is very hard to do without automated processes.  While it is not the case that all verification can be automated, a good portion can.

Good processes lead to quality levels already achieved by Google and Apple.  Go back and have a look at this blog post to see the ramifications of not having good processes.

For more information about errors and how to correct them, please use visit this resource.