BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.

Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.

Entries from December 15, 2013 - December 21, 2013

Understanding Prototype Theory

Prototype theory is something I picked up when I read David Wenberger's very insightful book, Everything is Miscellaneous.

The book has two key points.

  • That every classification scheme ever devised inherently reflects the biases of those that constructed the classification system.
  • The role metadata plays in allowing you to create your own custom classification system so you can have the view of something that you want.

Several years ago I summarized what I learned about prototype theory into this document, Understanding Prototype Theory and How it Can be Useful in Analyzing and Creating SEC XBRL Filings. The document also pulls information together about Concept Learning and Prototype and Exemplar Theory of Concepts.  If you are working with SEC XBRL financial filings, trust me...this information is incredibly helpful.

A fundamental problem of the US GAAP XBRL Taxonomy, in my view and in the view of many others that I talk to, is that it was (a) admittedly designed to be a "pick list", (b) the pieces are too big, and (c) the pieces which people generally work with are not physically identified.

This is what I mean, this is one section of the US GAAP XBRL Taxonomy (2011 Version), Debt. (That is an older version but there is not really much of a change in the 2013 version in terms of its organization.  I am using the older version because I remodeled the 2011 version, you will see why in a minute.)

If you look at that section of the US GAAP XBRL Taxonomy, you can clearly see that it can be categorized by it network which identifies it as "460000 - Debt". That network can be differentiated from every other network by the title and identifier of the network.

But, tell me what is in that network?  Or rather, you can read it and tell me what is in it.  But have a computer tell you what is in that network.  It cannot.  Why? A computer cannot identify what is in that network because it cannot identify the pieces which make up the network because the organization is inconsistent.  You can identify sum pieces, for example each of the [Table]s.  But, because not everything is in a [Table] and there is not really any other way to latch on to a specific piece because the representation is inconsistent, a computer cannot identify "the pieces".

Contrast the US GAAP XBRL Taxonomy representation to my remodeled version of exactly that same information. Note that everything in that remodeling is represented within a [Table].  I used US GAAP XBRL Taxonomy [Table]s where they existed, and where they did not exist I created a [Table].

But SEC XBRL filers don't use the information in the US GAAP XBRL Taxonomy at the [Table] level.  Look how big many of those [Table]s are.  Consider, say, the "Long-term debt maturities" disclosure which is a very common disclosure provided by SEC XBRL Financial filers which tends to look like this:

The above example of how long-term debt is disclosed. How do I know? Because I analyzed SEC XBRL financial disclosures, see this analysis of Long-term Debt Maturitieswhich I created for another project I am doing, and that is how the US GAAP XBRL Taxonomy is used generally by filers. This analysis has even more information on how small these disclosures really are.

So, if you look closely at my reorganization of the US GAAP Taxonomy you will see two things: (1) If you look within each [Table], you can see that the pieces are at the level SEC filers tend to use the information and each of those pieces is identifiable and (2) each one of those pieces follow a defined accounting concept arrangement pattern which I have made explicit.

This is what you should be looking at:

 

So now, because I have specifically identified each of the pieces of the US GAAP XBRL Taxonomy and I know that SEC filers create filings at that level, I can put the two things together and identify every report component of ever SEC XBRL financial filing.

How?  Well, consider this little XML file. That is a fragment of this larger file to make reading the file easier.

Click for a larger image

So, I have prototypes for EVERY piece of the commercial and industrial companies portion of the US GAAP XBRL Taxonomy.  I got them by reorganizing the taxonomy into a useful form, each disclosure.  Those disclosures match what SEC XBRL financial filers are disclosing.  I have exactly the same XML representation for every SEC XBRL financial filing.  I use the prototypes to identify the SEC XBRL financial filing report components, and the SEC XBRL financial filings to help me create prototypes.

Why do I go through all this effort? Well, that is how I do this:

A proper organization of the US GAAP XBRL Taxonomy is very useful for all sorts of things!

When I originally started using prototype theory, I thought that what I was trying to do is convince the FASB and the SEC to provide specific "handles" on every disclosure so that I would not need to go through all this effort.  But I think that I have convinced myself that those handles are not necessary.

My idea was for the FASB to provide a specific [Table] for every disclosure so each disclosure could be identified easily by anyone using SEC XBRL financial filings. They already provide [Table]s for some things, the idea is simply to provide a [Table] for everything.  Why is this possible?  Disclosures don't change.  The presentation of disclosures can be fiddled with by SEC filers, but what they can disclose cannot.  Look at the long-term debt maturities again.  What is disclosed does not change significantly, it is "the law".  There is some variability, but not much.  Now, this is not the case for EVERY disclosure, for example qualitative disclosures have more variability. However, qualitative disclosures are not random; patterns do exist.

But while providing specific identifiers for each disclosure is possible and may even be desirable and even a good practice for those creating taxonomies; it is not necessary.  The fact that I can get to whatever disclosure I want using prototype theory is proof of that.

Seeing the Treasure Trove of Value from SEC XBRL Financial Filings

While those SEC XBRL financial filings are far from perfect and not really good enough for automated reuse of the information by financial analysts and investors; that financial statement database is a literal treasure trove of value to professional accountants. And I don't mean just external accounting managers of public companies.  I mean the hundreds of thousands of CPAs who create private company financial statements.

There is already one commercial application that I am aware of which makes use of the XBRL-based database of public company financial reports: GAAPWatch which was created by XBRL Cloud. I tried GAAPWatch and even created some videos which shows the sorts of things you can do with GAAPWatch.

I created a tool which is based on the same web service as GAAPWatch. I took that tool which was origionally created for analyzing the quality of the XBRL-based financial information and tweaked it a little bit and now I have an incredible research tool. To do queries, I cached some other information locally on my computer so that I could search through individual digital financial reports using some techniques which I created.

Similar to GAAPWatch, I can view the pieces of a financial report and get to those individual pieces by searching on the characteristics of reporting entities or by searching for specific disclosures contained within a financial report.

But what I can also do is search for individual facts which are reported in a financial report and find filers who reported those facts, see how and where they were reported, compare and contrast how different reporting entities provided those disclosures, and compare the relationships between reported facts. Those queries are done against the locally cached information to make the queries run significantly faster.

So here are some fairly rudimentary examples that I think provides insight to the possibilities which are available right now. (This ZIP file contains Excel spreadsheets which has the information I pulled from the set of SEC financial filings I am working with.)

  • Say you wanted to see how environmental site loss contingencies were being disclosed. First, you would have to find reporting entities which had such disclosures.  Then you have to find the disclosure within the report.  Then you can read through the disclosures and see how specific filers approached the disclosure.  My query discovered 120 such disclosures and the specific location within the report which contained the disclosure.  Press a button, and I can see the disclosure in my application.
  • Suppose you wanted to see the relationship between having the line item "Income tax expense (benefit)" on the statement of operations and having an income tax policy provided or whether it is more common to provide the reconciliation between statutory tax rates and the effective tax rates using percentages or amounts.
  • Imagine that you wanted to understand the specific sorts of things which are disclosed in the nature of operations for reporting entities who operated within a specific industry.

Research can be done during the process of creating financial report disclosures where, say, private companies can leverage the high-quality financial disclosures within financial reports submitted to the SEC.

The closest thing that I can think of which exists today which is similar is what used to be called Accounting Trends and Techniques which was renamed U.S. GAAP Financial Statements - Best Practices in Presentation and Disclosure which is published by the AICPA.  The benefits of using the SEC XBRL financial filings is that

  • the entire process of creating the resource can be 100% automated
  • you can have a different version of this disclosure research resource for specific industries as the marginal cost is so low because of the automation
  • you don't need to limit the resource to 500 reporting entities or some specific subset of disclosures because it is just as easy to grab information from every reporting entity

But the ability to search through specific reported facts and other information goes far, far beyond what the AICPA's product provides. Eventually software vendors who make software for the creation of financial reports will realize the utility of having this research information directly within software applications used for creating financial reports.  The software vendors will also realize that any aspects of the tools such as the disclosure guides used to jog your memory to make sure you did not miss a disclosure can be automated.  And obiously software can watch over external financial reporting managers to make sure they did not make other mistakes such as computations which don't add up correctly.

Besides making the human readable copies of financial reports better, all those SEC XBRL financial filings will help the general quality of XBRL also improve.

(Here is a video of the application I used to get this information.)

Seeing the Benefits of XBRL to Reporting Entities

The reporting entities which are creating all those SEC XBRL financial filings tend to lament that all the benefit goes to those using the structured information and that they have to do all the work.  OK, and so people would likely point out that the information is not even that useful because the quality is not good enough.

Personally, I have never held that belief and I am beginning to be able to SHOW that there is not only benefit to reporting entities creating financial reports whether those reporting entities have to report to the SEC using the XBRL format or not.

While I have not been able to connect all these pieces as good as I would want, I am rapidly getting where I want to be.  But here is some stuff I put together as an interim step which show, I believe, the advantages information structured using XBRL provides.

First, take a look at this document: Financial Reporting Best Practices. Take a look at that and the first thing that you might notice is that you don't really see anything necessarily related to XBRL. What I mean is that anyone creating a financial report would find that information useful.  If you are an SEC XBRL filer you might find it even more useful; but even if you don't, it helps external reporting managers in their task of creating a financial report. I am not talking about only public companies.  I am talking about private companies also.

You say no; I already have resources such as this or I already understand how to report a reconciliation of the statutory rate and effective tax rate.  Sure you do.  You have books.  Well, three things about the books: (a) as soon as they are printed they are obsolete, (b) putting the books together is time consuming and therefore expensive, (c) if the information is in the form of a book a computer cannot really read the information and re-purpose the information in other formats.

Now, I really cannot show the true benefit here by putting this information into a PDF.  To get the full experience, you need to have a subscription to a web service or something which enables you to interact with the information more effectively.  Me, I use the XBRL Cloud Edgar Report Information Web Service.  I would encourage you to get a subscription and experiment with it.

I can emulate how interacting with the information would work.  Here is another application of XBRL Cloud which they call "The Evidence Package". Click here or on the image below to go to that application.

Click on image to open interactive application

Click on any of the report elements (the labels on the left) and you will see documentation about the line item, references to the Accounting Standards Codification, and other helpful information.

Think about what is going on here.  You can look at a specific piece of a financial report.  You can add information to those about what the report component is disclosing, you can reorganize the information and not look at the information by who filed it, but rather by what information is being disclosed.

Never, never, never before was it possible to look at information about what is in financial reports in this manner.  All of this is possible because the financial information is structured, in this case in XBRL.  Before financial reports were just one big blob of which a computer could do nothing with.  Now because the information is structured; you can restructure it and use it in lots of new and interesting ways.

What I find even more interesting is that you can use all those SEC XBRL financial filings TODAY!  Quality issues are less critical to accountants researching trying to figure out how to create a disclosure.  Why?  Simply ignore the poor quality report components and use the good ones.

This information is also useful to SEC XBRL financial filers. Why? Great way to see what other filers are doing and how what you create stacks up.

If you have not seen this blog post yet, go back and read it. This helps you see where all this is going and see how easy it is to get at this information.  I created my own software application and I am not even a programmer!

All I do is access URLs on the internet. Here is one of those URLs:

https://eri.xbrlcloud.com/edgar-report-information/rest/entities/0000874292/filings/0001445260-12-000048/components/4676254/rendering/

Again, you need a subscription to use these, but it represents one piece of a financial report.  My software application just interacts with URLs like that which have all that SEC XBRL financial information broken up into useful report components.