Digital Financial Reporting

People describing what a taxonomy is tend to say that a taxonomy is much like a dictionaries. This is a huge mistake and thinking that a taxonomy is like a dictionary will lead you to miss the real nature of and power of XBRL.

To understand this, it is helpful to look at the differences between a dictionary, a classification, a taxonomy, and an ontology.

• A dictionary is much like a list, a dictionary had no hierarchy.
• A classification system is a grouping of something based on some criteria. A classification tends to not have a hierarchy.
• A taxonomy is a classification system which does have a hierarchy, but the hierarchy tends to be less formal.
• An ontology is a set of well-defined concepts which describes a specific domain. Ontologies are generally defined using a class, subclass relations. Classes and subclasses have defined properties and relations. This works much like object oriented computer programming. The goal of an ontology is to provide a formal, referancable set of concepts which are used in communications within a domain. So, an ontology is also expressed as a hierarchy, but the hierarchy is more explicit and much richer in meaning than a taxonomy.

Why should you care about this? Well, today, most people who are building taxonomies are building what is described as "taxonomy" above. This is a great first step. But the real benefits of XBRL will be realized when taxonomies are constructed to be more like what is described as an "ontology" above.

No worries though. People can build extensions and turn an a taxonomy into an ontology. They probably already are. The idea that a taxonomy being an ontology is definitly not an origional thought which I came up with, it is more my listening to people over the past 10 years and learning what the heck a taxonomy is.

This gets even more interesting when you look into RDF, OWL, and the semantic web stuff which the W3C is doing. How exactly XBRL will fit into these things, I don't really understand. No worries. There are others who do. They will make this happen. What is important to understand is that this stuff will happen.

The US GAAP Taxonomy, for example, is just a first step in defining semantic meaning used in financial reporting. Way, way more richness will be provided for the information in that taxonomy.

It will be interesting to see what people come up with.

The SEC XBRL previewer absolutely rocks, and you can try it for yourself. You don't need to be a public company or have a CIK number. Here is how to do it.

First, grab this file, you can use it as a first test: 00000000001.zip  (You can just put your mouse over the ZIP file link, right click and select "Save target as..." Note that I grabbed this set of files from the SEC EDGAR system and I have run it and I know it works.  This is the filing submitted by "The NASDAQ OMX Group, Inc."  This is public information.  Or, you can create your own test submission and view that.)

Second, go to this web page: Privately Preview your Interactive Data Submissions

Third, you can enter any CIK number you want.  Fill in the information on the left side of the form.  Put in the CIK number you want, upload the file from above (or a file you created), enter the security code, and then press the "Submit" button.

You will be given a confirmation code.

Fourth, wait about 15 minutes.  Then, on the RIGHT side of the form; enter the same CIK number you used to submit the filing and then enter that confirmation code you received.  Put in the security code again.  Press the "Submit" button on the right side.

You can view the different sections of the submission by pressing one of the headings you see on the top of the form you will see.  You can also download all the information in an Excel spreadsheet.

The rendering is pretty good and I am sure will only get better.   The block text is all smashed together, but that will either be improved or the issue will go away when block text can no longer be used.

Nice work SEC!

I think that I heard, for the first time from the SEC, that the old SGML/HTML filing formats which public companies currently use are going to be phased out over time.  Check out the video of the open meeting in which the SEC mandated XBRL, approximately 2 hours 10 minutes to 2 hours and 12 minutes.  Listen to it, see what you heard.

This makes sense for three reasons.  First, the liability issue which was discussed during that time in the video and raised by the one descenting vote.  Second, it just means more work for preparers who have to be sure that the two versions (the SGML/HTML and the XBRL) agree.  Third, relating to the second is that you have two versions of the truth as you have two versions of the filing.

It makes a lot of sense to have both the old and new filing formats for a while.  This is definitely a very safe way to introduce XBRL, it helps get issues resolved.  When people are happy with how the XBRL is working, make everyone's life easier by getting rid of the SGML/HTML.  Users will be able to render the XBRL perhaps not exactly like the SGML/HTML versions, but functionally the same.

So, this brings up a bunch of questions.  I will highlight one (there are others).  This is a good one.  It has been discussed for years in the XBRL community.  I speculate that now that accountants understand that this XBRL stuff is real, they will have to start dealing with these types of issues.

The issue I will point out is the statement "presented on the face of the financial statements" (or something to that affect).  There are two notions in financial reporting, presented (on the face of the financials) and disclosed.  If you ever looked into an XBRL instance document, there is no partition between the "face" and the "disclosures".  An XBRL instance document is just a big bag of facts.  Users can get those facts out however they desire.

Does there need to be some partition?  Personally, I don't think so.  This is one of the legacy ideas which fits with paper-based financial reporting which is really unnecessary with XBRL.  Users can get whatever information out of the XBRL instance that they desire, however they desire, arranging that information however they see fit.

Is this without issues?  No.  The point is, this is one of many things which will need to be figured out by the business community.  Again, there others.  My fear is that too many legacy ideas will be brought forward to the new paradigm.  Should some past ideas be brought forward?  Absolutely, the good ones.  But not the bad ones.  The question is who makes the call?

Could I be wrong about whether "presented on the face of the financials" needs to be brought forward?  Sure I could be wrong.  If it does need to be brought forward, it still needs to be discussed as there is no approach for achieving that currently in the US GAAP Taxonomy, in the preparer's guidance, or anywhere else that I have seen.

I think it is time for financial reporting to "go green", think of new ideas an not be limited to what paper can achieve, and take advantage of this opportunity.

Ever wanted a really simple example of XBRL?  Well, you are in luck.  Here is a very basic example of what XBRL is, how it works, and how easy it is to create.

This example shows the very basics.  It consists of:

• A taxonomy: HelloWorld.xsd
• An instance document:  HelloWorld.xml
• An Excel spreadsheet which allows you to generate XBRL: HelloWorldExample-2008-12-19.zip

The best way to use this is to download the ZIP file which contains the Excel spreadsheet, the taxonomy and the instance document.  You can look at the taxonomy and the instance document.  Open the Excel spreadsheet.  NOTE THAT IT CONTAINS MACROS!!!  Go to the workbook "Hello World Example" and simply press the buttons on the right, in order preferably, and you can create your own XBRL.  You can go to the "Create HelloWorld Taxonomy" spreadsheet to generate the taxonomy.

Some things to note about this "Hello World" example:

• While the example is pretty basic, you can get a really good sense for what is going on, how things work, how to generate your own simple instance documents, and how easy creating basic XBRL really is.
• You will realize that you don't NEED any fancy tools to get started.  But BEWARE!!!  There is no XBRL validation being done by the example.  However, if you grab a validator and validate it, you will see that this is valid XBRL.  It is not that I am recommending creating XBRL without a validator.  This is not a production system, it is only a simple demo.
• If you look at the example you will note there are no linkbases.  Ah, those mean and nasty linkbases!  Well, you will also see that you don't have much metadata.  No labels, no calculations being expressed, no formulas, no references, no nothing but concepts.  Looks a lot like normal XML.  Well, it is.  The point is that all those mean and nasty linkbases is where all the helpful metadata is.  You are going to want those to get all that great metadata they provide.
• If you are proficient with Excel, you can probably read the VBA which makes this go.  The example does not even use an XML parser to generate the XBRL, it basically just writes a text file.  The VBA which extractes data from the instance and populates it does use an XML parser.
• See how the mapping workbook is used to both generate the XBRL and also to populate the spreadsheet from the XBRL file.  Two way process using the same mapping.

Sure, this is not perfect, it is not robust, and it certainly is not some big scalable application for using XBRL.  But, it is useful in helping you see the basics, reverse engineering how to work with XBRL and for some general experimentation.

For more information go to the Learning about XBRL page and/or Digital Financial Reporting.

In a 4 to 1 vote, the U.S. Securities and Exchange Commission will begin requiring public companies which are regulated by the SEC to submit information using XBRL.  The mandate is similar to the proposed rule the SEC floated for comment several months ago.

There will likely be more information on the SEC's news digest. (Nothing there at the time this entry was written.)

You can get play by play of the ruling at Rob Blake's blog.

Commissioner Casey said something to the affect, "The advantages of XBRL are self evident."

Commissioner Walter said that the affect of XBRL will be "Broad, sweeping"

Commissioner Paredes said "Investors can use [XBRL] information as they see fit."

Chairman Cox was given a lot of credit for having the vision to make interactive data a reality.

The descending vote related to liability of those submitting information.  The descending commissioner was supportive of XBRL but felt that companies should get less breaks relating to the liability for any issues with information submitted in XBRL.

In an interesting statement made during the meeting, it was pointed out that the old filing formats will eventually be phased out.  No time table was stated for such phase out.

Welcome to a brave new world of financial reporting!