Digital Financial Reporting

Several months ago I searched and searched, trying to find what I would consider a model SEC XBRL filing.  I did find one.  (Here is a blog post which summarizes the types of mistakes filers are making.)

In the latest set of SEC XBRL filings, I found 24 SEC XBRL filings which I gave a "5 Star Rating"!  That is quite a nice leap.  You  can see the list here on an HTML page (and here is the list in XML if you want to read the list programatically and perform your own analysis).

Model SEC XBRL Filings

While these filings may not be totally perfect, this is a very significant move in the right direction for SEC filings in my view.  There is one thing which is a bit disappointing about the list which is that one filing agent created all of the filings.  That vendor is EdgarOnline.  Nothing against EdgarOnline, I just would like to have seen more vendors on the list of those getting a 5 Star Rating.

An interesting point here is that there are at least three separate parties who say that the list of 24 filers did a good job.  First there is me, I say those are good filings.  See below how I define "good".  Second, EdgarOnline says they are good; otherwise they would have done them differently.  Third, XBRL Cloud says that they are good.  The public list of SEC filings validation results (called the "dashboard") made available show zero errors in all the categories I used.  (I excluded certain best practices and informational messages from my evaluation criteria.)

Conceivably, you could add another "party" to those who say that those SEC XBRL Filings are on target which is the US GAAP Taxonomy Architecture. That is where XBRL Cloud, EdgarOnline, and myself get the information to help us figure out how to properly create SEC XBRL filings.

5 Star Ratings

Here is a list of SEC XBRL filings which I gave a 5 Star Rating to.  I consider these filings models of what I consider a good SEC XBRL filing.  Can you consider these best practices?  I think so.  Show be better practices.  See a detailed listing of the characteristics below.  But here is the list of the 24 SEC filers who get my 5 Star Rating (again, here is the list on a web page where you can get to additional details):

• ALCOA INC
• BOEING CO
• CARDINAL HEALTH INC
• CISCO SYSTEMS INC
• CLIFFS NATURAL RESOURCES INC.
• CNX GAS CORP
• CONSOL Energy Inc
• EBAY INC
• ELECTRONIC ARTS INC.
• FASTENAL CO
• Google Inc.
• HOLOGIC INC
• INTERCONTINENTALEXCHANGE INC
• INTUITIVE SURGICAL INC
• OPEN TEXT CORP
• PARKER HANNIFIN CORP
• PPG INDUSTRIES INC
• PRECISION CASTPARTS CORP
• QWEST COMMUNICATIONS INTERNATIONAL INC
• SIGMA ALDRICH CORP
• UNITEDHEALTH GROUP INC
• VARIAN MEDICAL SYSTEMS INC
• WALT DISNEY CO/
• WELLPOINT, INC

Congratulations to these 24 filers and to EdgarOnline for helping to move the list of models from 1 to 24.  There is still a ways to go to get where we need to be, but this is certainly a big step in the right direction.

Criteria for Receiving 5 Star Rating

Here are my criteria for receiving a 5 Star Rating. First, let me say that the rating is not about perfection, it is about a minimum standard.  A lot of people tell me, "Well, it got into the SEC so it is good enough."  My quality standards are higher than the SEC.  They are where the SEC really needs to go to make the XBRL truly "interactive data" (as the SEC calls it), usable for analysis across companies and to allow for the HTML/ASCII filings to eventually be phased out.  Again, even my criteria are not sufficient to attain the goal of usable analysis or phasing out the legacy formats.  However, they are absolutely necessary to achieve that goal. 

The data set I am working with are 10-K and 10-Q SEC XBRL filings between 2010-01-12 and 2010-02-19 from the XBRL Cloud report.  (I use that and not the SEC RSS feed because I cannot get a what I need from the SEC RSS feeds.)

Here are the criteria:

1. No XML, XBRL, or EFM Errors:  The first criteria is no basic errors.  This is indicated by having a "0" in Column 8 which is marked with "E" under "Edgar Filing Manual" on the XBRL Cloud validation report.  There really should be no difference between what XBRL Cloud says is an error, what the SEC says is an error, and what any other vendor says is an error.  The fact that there are submissions with errors as indicated by XBRL Cloud means that there are disagreements between the SEC, XBRL Cloud, and other vendors as to what is an XML, XBRL or EFM error.  (i.e. interoperability issues)  Making these interoperability issues go away is key to making SEC XBRL filings usable.  EdgarOnline seems to believe that XBRL Cloud is correct.  I say that because they pass XBRL Cloud definition of "EFM Errors".  (An interesting side note here is that these issues seem to be going WAY down.  Analysis of prior quarters showed multiple vendors being inconsistent with XBRL Cloud validation.  In this last analysis there was only one vendor who was inconsistent (7 are consistent with XBRL Cloud) and there were only 25 inconsistencies (last quarter there were 255 inconsistencies spread among the 7 vendors).
2. Calculations consistent: Automated processing and calculation inconsistencies don't go together.  It is my view that if most filers can get rid of 100% of calculation inconsistencies, then ALL filers should be able to do so.  I will hold that view until I have evidence to support a different view.  All calculation inconsistencies which I have seen are, in my view, a result of sloppy preparation of the XBRL instance.  As such, if you have calculation inconsistencies, you get no 5 Star Rating.  See the calculation reports for the 24 companies on the list.  All the calculations are squeaky clean.  (Keep in mind though that I am not testing to be sure that 100% of computations have some test to be sure they are correct.  That is where things need to go, but first the existing inconsistencies need to be made to go away so that is the current focus.)
3. Pass one basic XBRL Formula test: The filings need to pass one basic XBRL Formula test or business rule. The business rule states that the beginning balance of cash plus total changes in cash equal the ending balance of cash.  EVERYONE has cash generally.  Cash changes for everyone.  Therefore EVERYONE should both have all these concepts and the computation needs to work.  For all these filers, those criteria are met.  There are many reasons one can come up with to argue that this is not a valid criteria.  But, the point here is to drive that discussion which needs to happen to truly resolve a number of real issues relating to using XBRL.  Some of these are accounting related such as the unnecessarily inconsistent way filers calculate this change.  See this blog post for more information.
4. [Table]s created correctly: The US GAAP Taxonomy Architecture calls for [Table]s to be constructed in a specific way.  Every [Table] in the US GAAP Taxonomy follows the US GAAP Taxonomy Architecture.  SEC filers likewise need to follow the rules for [Table]s.  To not do so will cause very serious comparability problems.  There are other areas where filers need to follow the US GAAP Taxonomy, but this area is a start.  I am not even testing the XBRL Dimensions aspect of [Table]s at this point, that will come.  First, the basics.  If you don't use [Axis] and [Line Items] properly in a [Table], your information will not be comparable to other information and therefore you don't get a 5 Star Rating.
5. Extension concepts make sense: This is a bit more subjective so I am actually cutting people a lot of slack here.  But,  if you provide an extension concept, it needs to make sence in the grand scheme of things and you need to provide a description of the concept.  Poor choices here reduce comparability of the information, which is not good for investors using the information, and therefore if you do this you don't get a 5 Star Rating.

There you have it, those are the criteria.  Again, pretty basic.  As the number of SEC XBRL filings pass these basic criteria, then one can start looking at the additional things which will need to be addressed to make the SEC XBRL filings useful for comparison and so they can completely replace the HTML/ASCII filings.

If you are creating an SEC XBRL filing, these are good examples to follow.  I consider these 24 SEC XBRL filings to be good models for others to follow.

To get a fuller appreciation of the filings, go look at the details on this page.  Click on the reports such as the calculation validation reports, the actual "Interactive data" at the SEC web site, and all other information which can help you understand the filing.  If you are a software vendor and you want to run your tools over this set of filings, use this XML document.

Want to get added to the list?  Should someone be removed?

If you believe that your filing or any filing should be added to this list let me know.  Point me to the filing and I will check it out.  I personally want the club of 5 Star Ratings to grow, the more the merrier.  If you think someone deserves to be removed from this list due to some fatal flaw that I am not checking, let me know about that also.  I want to point to good examples for others to follow.  No need to have poor XBRL filings listed here.

The following are two links to information which represent further progress in creating a UML model for financial reporting:

• DRAFT of UML Model: This is a PDF with the images from a UML model created plus narrative added which explains the model. This model was made available by Cliff Binstock of XBRL Cloud.  Cliff modified the model based on suggestions by me.  The model is made available under a Creative Commons license, anyone can make use of this however they see fit, everyone is encouraged to contribute to creating and completing it.  However, it is best if one model can be agreed upon.  The model was created using the free ArgoUML Tool.  If you want a copy of the model which can load into that tool, please send me an email (CharlesHoffman@olywa.net) and I will send you a copy which you can edit.  Those who add value to this model will be included as creators of this UML model. 
• DRAFT Mind Map: This is a mind map of the same information.  What I am finding is that both of these serve a purpose.  The UML model is more concise and formal, but harder for business people to understand.  The mind map is easer to understand, but not "standard" or detailed enough for technical people (i.e. that is why UML was invented).  Therefore, both will be maintained.

The next step is to tune the existing draft and create additional "logical" and "physical" models.  All three of these models should fit together.  Personally, I also want to express the model in OWL.  The intension of these models is to help make XBRL for financial reporting unambiguous, provide semantic consistency, in financial reporting environments (domains) were XBRL's extensibility is utilized (filers of financial reports can modify the information model).

The Financial Accounting Foundation (FAF), a not for profit entity of which the Financial Accounting Standards Board (FASB) is a part, will be charged with maintaining the US GAAP Taxonomy, per the following WebCPA post and FAF press release.  When the SEC began funding the US GAAP Taxonomy it originally started at the FAF but was transferred to XBRL US as the progress progressed.

This is an interesting twist.  The first thing that came to my mind is the potential switch to International Financial Reporting Standards (IFRS) by US companies.  I think there will, at least for the foreseeable future, be a US GAAP Taxonomy going forward if this occurs.  The US GAAP taxonomy adds information for many industries, details not found in the IFRS taxonomy, and SEC rules which will never be covered by the IFRS taxonomy.

The fact that the FAF maintains the US GAAP Taxonomy could cause even more "market provided support" for things which make the US GAAP Taxonomy usable by reporting entities.  This is similar to the fact that the FAF publishes the accounting standards, but Wiley and others publish books which explain and make the standards easier to use. 

Also, the AICPA publishes things like Accounting Trends and Techniques.  When this SEC XBRL filing really gets going, I think people will realize that using the US GAAP Taxonomy as the starting point is not the way to go, rather there will be XBRL templates which are better starting points.  The end result will be valid XBRL which can be submitted to the SEC.  It is just that the market will be able to better decide what is useful.

I do find the timing of the next update interesting:

The FAF and FASB plan to assemble a small team of technical staff who will be dedicated to maintaining the taxonomy and will work towards the release of the next taxonomy update in early 2011.

Users need better search capabilities in taxonomy creation software so they can FIND the right concepts.  The use of synonyms to help identify concepts would be very helpful to users.

Click to read more ...

In order for your XBRL information work on the Semantic Web or within your internal semantic web, or in any computer system for that matter, your data and metadata need to be unambiguous.

Before I get started here, I want to explain a few terms to business people.  Business people need a working knowledge of these terms in order to understand what is important to making your systems work, to making your XBRL unambiguous.

Why is this Important?

You may have heard terms like "metadata" and "semantic web".  But what do these terms mean and how do they relate to you.  In his book Pull, David Siegel explains these two important terms and how they will change the Web.  While the terms are defined in the book, what provides you the understanding are the countless examples of what having a "semantic web" will mean to you.

For anyone who lived through the beginning of the Web, to say there was hype surrounding the notion of how the Web would change life as we know it on planet earth is an understatement.  However, you have to admit that a lot of things have changed.  Just because there is hype does not mean that the Web is "empty", nor is it the case that "the Semantic Web" is empty.  In fact as I understand it, the Semantic Web was Sir Tim Berners-Lee's vision of what the Web needs to be, the Web as we know it today is just an interim step in that direction.

Metadata

It has been my experience that technical people like to complicate the notion of "metadata".  Perhaps they like to keep things mysterious.  You can go search the Web for a definition, in fact here is an explanation of metadata on Wikipedia.  I even hear techies use the term "meta-metadata"!

So what is metadata?  Metadata is just data.  It is just at a different level from what you normally thing of as data.  Metadata, like data, describes something.  That is it.  What is more important is to understand why metadata or data is important.  Computers are not magical things.  They can do magical things, but all this is enabled by the data and metadata which is provided by and linked together by humans.  For example, if you have a list of files on your computer you can only sort them in ways you have information about those files, the "data" or "metadata" about a file; such as the date you saved the file or the name of the file or the type of file.  The more data or metadata you have, the more a computer can do with data.

Semantic Web

Metadata and data is the foundation of the Semantic Web.  David Seigel gives a very simple explanation of the Semantic Web by posing two simple questions:

1. Is it unambiguous?
2. Is it on the Web?

So now we have a number of other terms floating around here: semantic and unambiguous. If you are a glutton for punishment, you can go here and read about semantic.  Fundamentally, semantic is about unambiguous meaning.

When I say Semantic Web, you can look at the scope of the "web" in a number of different ways.  It woulc be the "Semantic Web" meaning the open to the public on the Web, it could mean "semantic web" meaning only available within your organization, or it could just be some smaller subset of users in some sort of closed system, not open to everyone.  The type of web makes no difference.

As David Seigel explains in his book,

Data that is semantic means exactly the same thing to any system or person who uses it.

That is the key to making data usable to a computer.  You need to be unambiguous.  This is not to say that everyone has to interpret the information in the same way, this is about consistency in the meaning of the data and metadata.

Making XBRL Unambiguous

So, if you are creating XBRL you want to be unambiguous.  This does not mean unambiguous to you, it means unambiguous in general, to everyone.  There are ways to test to see if your information is unambiguous. As a business person you don't actually have to do these things yourself, you can ask the technical people implementing the system if they have done any of these.)

• Try to express it in RDF (Resource Description Framework) /OWL (Web Ontology Language).  If you can, and it makes sense, then it is unambiguous.
• Try and express your information model in UML (Unified Modeling Language) and see if it makes sense.  Again, if the UML model makes sense, then the data and metadata will likely make sense.
• Try and use the data.  If the system works, then the data and metadata are unambiguous and logical.  If not, then something needs to be fixed.

If you have not tested your systems there is a high probability that your system is not providing information which is unambiguous.  It is the testing which helps you achieve this desired goal and makes your system usable.

This is particularly true when your system allows extensibility, where those submitting information can make any sort of adjustment to an XBRL taxonomy.  Those extending your XBRL taxonomy have to be given guidance to create those extensions as you had anticipated and consistently with one another.

This testing is best done during the time when you are architecting your XBRL taxonomy and other aspects of your system, not when your system is live.  Waiting until your system goes live to do this testing may mean the need to re-architect your system.