Digital Financial Reporting

This is a continuation of the post "Thoughts on Rendering XBRL (First Installment)".

These are, in my view, the things which need to be achieve when addressing rendering XBRL information for consumption by humans:

• Renderings need to be interactive, meaning they can be easily reorganized to meet a user's specific needs without the need to re-key information.
• Renderings need to be in a usable form.
• Extensions to an XBRL taxonomy must not break the rendering.
• There should be no need to specify rendering information beyond what is provided within an XBRL taxonomy.
• The rendering algorithm should not be proprietary to any specific software application. (This defeats the fundamental purpose of XBRL)
• All this should be easy enough for business users to make work, both the creator of the information and the consumer of the information.
• It needs to work consistently and predictably.  If this is not achieved, automated information exchange is a non-starter.

Here are some things which I am NOT part of the rendering equation, in my view:

• It is NOT the case that "pixel perfect rendering" is the target.  While pixel perfect rendering of XBRL information is definitely needed, it is not needed for every use case. It is not in scope for what I am trying to achieve in terms of rendering.  (Besides, I can already do that using XSLT and a one-to-one rendering solution.  The problem is, you cannot make that interactive.)
• It is NOT the case that "every user needs to get exactly what they want in all cases" for the target I am talking about.  Should users get what they want?  Absolutely.  But what do you REALLY want: (a) the ability to automate the exchange of information or (b) haggle about whether something needs a double underscore or a single underscore. Life is full of trade offs.
• It is NOT about forms.  Rendering the information collected from a form is child's play because the metadata of the form does not change, it is static.  By definition here, if the metadata does not change, what you have is a form.

So, how to do it?  First off, borrow the multidimensional model. (See Getting Started with ADAPT and the OLAP Council White Paper).  Now, I did NOT say borrow OLAP, I said the multidimensional model, which is part of OLAP.  The part of OLAP which is not needed and generally seems to get in the way is it's desire to aggregate things.  Well, there are may times when we don't need that with XBRL.  But, the multidimensional model and OLAP are two different things.  Here is a quote from the OLAP Council White Paper:

"A multidimensional view of data provides more than the ability to "slice and dice"; it provides the foundation for analytical processing through flexibile access to information."

So, does XBRL need OLAP?  Sure, when it needs it.  But when it does not, it needs to not be constrined by OLAP.

An example of this constrain in a general slice and dice type tool is Microsoft Excel pivot tables.

Here is a bunch of XBRL (these were pointed out in the first installment also, they are the same thing):

• Metapatterns: http://www.xbrlsite.com/Demos/Metapatterns/2009-03-14/
• Business use cases: http://www.xbrlsite.com/Patterns/2008-04-18/
• Comprehensive example: http://www.xbrlsite.com/examples/ComprehensiveExample/

These are still a work in progress.  The metapatterns and the business use cases represent what I am trying to represent better than the comprehensive example at this point.  But, I will adjust these XBRL taxonomies until I get the desired result which is an acceptable rendering of the information the XBRL instances contain.

How I am achieving the rendering (or attempting to) is to use the following things:

1. The taxonomy XBRL information.
2. The taxonomy information model (i.e. how the taxonomy is constructed).
3. A datacube of XBRL instance information based on 1 and 2 above.

Here are examples of each of these for one of the metapatterns, the "Combined" example.  This is the taxonomy information in XML and in HTML. A human can "see" the HTML, but I use the XML to gather information about the XBRL and about the information model.  This is basically a pre-processed view of the presentation network.  I do this because I am not a good enough programmer to use an XBRL processor API.  So, I use this which is created by using some of the XBRL Cloud stuff that I have access to.

I use that network view to create something else I need.  I have tried a number of times to try and get a Microsoft Excel pivot table to render XBRL.  See the first installment of this post and take a look at this file I created way back in 2007. Look at both the pivot tables I was able to create and more importantly the DATA which DRIVES the pivot tables!

That data format (i.e. the denormalized data in Excel) and some ideas that Rene van Egmond, Cliff Binstock, some others at UBmatrix led to the creation of this: the datacube. Or rather, I call this an "interactive information cube".  It has what we need from the multidimensional model and provides flexibly, but it does not use the OLAP piece that gets in the way.  Look in the metapatterns, business use cases, and comprehensive example, a datacube is provided for each.  These datacubes are modeled after what XBRL Cloud has implemented, but adjusted to make them work how I need them to work.

The information within the datacubes are quite easy to load into Excel.  In fact, see this tool which allows you to do that (same one pointed out in the prior installment of this post).  The problem is that Excel pivot tables don't render these how I need them rendered.  So, I have to create my own approach to rendering (unless I find someone who is willing to help out who knows how to program, if you do, please let me know, charleshoffman@olywa.net).

This may seem like a goofy way to approach solving this problem, but it is all I have to work with.  There are a lot of moving parts.  This is about creating a proof of concept and an approach, not about me creating the actual control which one could use to render XBRL. That would be for programmers to do.

I am going to call that good for now, a third installment will be forthcoming.

This is the first installment of a series of posts which I am going to make relating to rendering XBRL. When I say rendering, I am talking about both the output of XBRL and the input or the tool used to create the XBRL and the information the XBRL represents.

I have been fiddling with how to render XBRL information for years. It is actually quite easy to render XBRL. This was created by applying a style sheet to the XBRL instance which generated XSL-FO which was then sent to an FO processor which generated PDF.  You can see more information about this here.

The problems with that rendering are the following:

1. It is a "one off" rendering, meaning that the rendering process works only for that particular XBRL instance.  This is not a good thing for a number of reasons, keep reading.
2. The typical business user cannot create that rendering, at least not using the tools which exist today.
3. The rendering is not "interactive" in nature, meaning that you get ONE format, what you see.  The user cannot reconfigure the rendering if they desire to see the information formatted in a different way.
4. The rendering will not handle extensions.  If someone adds an extension, it will simply not show up in the rendering which is clearly not acceptable.  Rendering static forms is basically a cake walk.  It is the dynamic forms of information which make use of XBRL's extensibility which are the challenge.

So what is the answer?  Inline XBRL?  In my view, inline XBRL is little better than the PDF version above.  It has pretty much the same negative characteristics.

This is how I see things.

• The goal:  In my view, the PDF type rendering is a good starting point for communicating the goal.  Basically, if you want to replace what you have today with something else, you need to meet all the needs being met today, plus more.  So, this is what a business report commonly looks like today (I am using a financial statement).
• How to get there: If you take a look at the business report above you will notice that what it is, is lots of little tables of information strung together in the form of a report.  To show this, what I did was take the information and put it into Excel.  I then created an Excel pivot table for every piece of the report.  That spreadsheet can be found here.  There are two sheets for each table.  The first is the actual pivot table, the second is the data which drives the pivot table.
• Interactive information: This is a prototype of the theoretical goal in my mind.  All I did was to take the pivot tables from the bullet above, take a screen shot of each, and put them into a Word document and print the Word document to PDF.

Now, it would be nice if Excel pivot tables rendered the XBRL information better, but they don't for two reasons.  First, I am no expert in Excel.  You can probably get this better, but you will not be able to get it exactly how you want it because of the second reason. The second reason is that Excel pivot tables (as most of the multidimensional tools that I have seen) are optimized for (a) numbers and (b) aggregation of those numbers.  Maybe there are ways around this, but I have not been able to find them.

So, what is the answer?  Well, that is the $64,000 question.  This is what I am trying.  The first thing you need is use cases and I have been nurturing a set of use cases for a number of years.  I have broken these use cases into three sets:

• Metapatterns: This is the essence of what needs to be achieved.  This condenses the business use cases down to their essence.  You can distill all the business use cases into one of these metapatterns.  Here is this set of use cases: http://www.xbrlsite.com/Demos/Metapatterns/2009-03-14/
• Business use cases: These are actually the same thing as the metapatterns above, but packaged differently.  They are more along the lines of business use cases, easier for a business person to get their heads around.  But, there is nothing in this set which the meta patterns does not address.  Here is this set: http://www.xbrlsite.com/Patterns/2008-04-18/
• Comprehensive example: This is really the starting point from above, the goal.  This looks like a financial statement.  But what it really is, is the set of business use cases put into the form of a financial statement, again, so it is more understandable to business people. Here is this set: http://www.xbrlsite.com/examples/ComprehensiveExample/

(Keep in mind that these three sets of XBRL taxonomies and XBRL instances are about two years old and have helped me get to where I am today in terms of my thinking about rendering XBRL.  I need to make some adjustments and corrections to these files to better tune them to my existing ideas.)

This is a work in progress, but what I have tried to do is build a tool to render the XBRL information in a form which would be usable by humans.  This little Excel tool reads each of these sets of XBRL instances and XBRL taxonomies above.

Now, there are two important ideas to understand here.  The first is the notion of "shape".  The second is the notion of "flow".  Read the two links to blog entries which explain these two ideas.

For now let me summarize by saying this:  It is impossible to have a great rendering tool and a poorly constructed XBRL taxonomy and get what you will desire.  It is likewise impossible to take a well constructed XBRL taxonomy and use a poorly constructed or poorly designed rendering tool and get what you want.  It takes two things to enable what most business users will want:  a good XBRL taxonomy and a good tool which leverages the XBRL taxonomy information to render XBRL instance information. (I would love to be proven wrong.  If you have a tool which can render these small taxonomies in a manner that a business user will be happy with, please let me know.  Until that time, I will assume that I am correct.)

I am going to stop here for now.  If you want to follow this thread of thoughts relating to rendering XBRL, I encourage you to thoroughly examine the metapatterns, business use cases, and the comprehensive examples shown above.  Part of this is having a look at the sets of XBRL instances and XBRL taxonomies via the little Excel tool.

If you went to business school like I did, you probably read the classic Harvard Business Review article by Theodore Levitt, "Marketing Myopia". The article explores the question of a business trying to figure out what business it is in.  It points out one tale of how railroads were devastated by the trucking industry because railroads thought they were in the "railroad" business when they were really in the "transportation" business.

"How is this applicable to XBRL," you ask? Many times people take a myopic view of the landscape. Another term commonly used for this is "tunnel vision".  Another is not seeing the forest for the trees.

What is XBRL? XBRL has been described as:

• A standard for exchanging business information.
• An XML language.
• A mandate from regulators.
• A means of modeling business information.
• A global initiative.
• A better approach to exchanging business information.
• A revolution for small investors.
• One of the Semantic Web's most successful metadata formats.
• The most revolutionary change in financial reporting since the first general ledger.
• A transformational technology.
• A market-driven global consortium trying to solve a business problem.

Which is it?  Well, XBRL is probably all of those things. But what does XBRL mean?  Here are some questions you may want to consider asking yourself.

• What does it mean if financial information used to be published in an unstructured form not readable by computers, but now with XBRL this information is published in a structured form which computers can understand?
• What does it mean for the US GAAP XBRL taxonomy and the IFRS XBRL taxonomy to organize financial reporting concepts in a manner that a computer can read and understand those concepts and relations. (As compared to historically this information is only understandable by humans.)
• What does it mean if business information exchange was made so easy it could be effectively automated on a massive scale?
• What does it mean if an entire body of knowledge for a business domain can be expressed in a standardized electronic format and exchanged with others?

Think about that last point.  An XBRL taxonomy contains the experiences, insights, rules, conventions and other knowledge of professionals who operate within a business domain. XBRL taxonomies today, such as the US GAAP and IFRS taxonomies, are filled with information.  As they mature they will contain even more information, making them more like ontologiesand less like the simple dictionaries which most XBRL taxonomies are today.

I personally had never heard the term taxonomy or ontology until about 10 years ago when we started building a taxonomy for XBRL.  Now CPAs are building taxonomies such as the US GAAP and IFRS and tomorrow they will be even more sophisticated than they are today.  Are CPAs going to need to be ontology engineers?

No one really knows what will happen in the future for sure, but there are clues.  Anyone who was paying attention when the Internet came into being saw the changes that technology can bring, many of the changes totally unexpected.

The point here is that sure, understanding what XBRL is can be rather important to business people.  But even more important is understanding what a world with XBRL in it will look like.  What business are you in?

I wanted to make my loyal blog readers aware of something before I passed this information on to others.  On this blog site there is a web page for the XBRL for Dummies book which is set to be in stores very soon (like next month).

The page is for the XBRL for Dummies book. The page has two things which may be of interest.  First, the organizes the links in the book into book chapters.  Therefore, you can get a better feel for the book using that table of contents information.  Second, lots and lots of links.  The links are good for two reasons:  (a) because they point to other useful information, (b) because it helps you realize the amount of information which is presented in the book.  The book condenses and organizes all that information into a useful and useable form, so you don't actually have to wade through all those links (there are about 350 links!).  But, if you want more detail, use the links to dig in deeper into specific areas.

Happy reading!  Thanks for your support of XBRL.

I have put together a prototype application for accessing SEC EDGAR information. I created this application for a number of reasons which will become apparent later, but the application is also quite helpful in seeing what is necessary to make such an application work and it demonstrates the potential of XBRL.

I cannot take full credit for this prototype. A number of years ago, the University of Kansas created a demonstration repository of XBRL based information.  For that project we created a little "analysis" tool which extracted and used that XBRL based information. I modified that tool, making it work with the current SEC EDGAR XBRL data.

Remember that I am not a programmer and the prototype is more of a proof of concept than an application which would be useful for analysis. It does work though. But keep in mind the following limitations of this application:

• It only works with a list of 408 XBRL submissions to the SEC and is not updated for new submission.
• The application does not make use of an XBRL processor.  An XBRL processor was used to pre-process a few things such as the XBRL taxonomies for each filer and the queries used to extract data.
• The application is not intended for analysis, it is intended to show what is needed in order to make an analysis application workable.
• The application is not a demo of the nifty features of Excel, it is a demo of extracting and using information on the Internet.

How to use the prototype

To use the prototype:

1. Download the ZIP file.
2. Open the ZIP file and then open the Excel spreadsheet.
3. On the "Analysis" spreadsheet, click on the button in the upper left hand corner.
4. Work through the form which comes up left-to-right.  It is pretty easy and it is hard to do things out of order.
5. Watch the Excel spreadsheet, that is where the information extracted is put.
6. Think about what is making this application work and what you might need within your systems to make then work as you need them to work (meta data, taxonomies, etc).

If you know now to write Excel VBA (macros), you can go even further...modify the application.  The application has a lot of good code examples which help you understand how to get at the information within an XML file or within an XBRL file without an XBRL processor.  Reverse engineering is a great way to learn!

I would challenge you to make the appliation work better.

How the prototype works

The application uses a number of XML files to pull information together which is then viewed within the application.  Here is a summary of these files:

• List of entities: First, you need some list of entities.  The list of entities in this application comes from the XBRL Cloud feed of SEC filings.  I read that list, grabbed the filings that I wanted to use, and publish my list of entities and related SEC filings here, which is the entity information used by this application.  This is the XML file.
• List of industries: Because the number of entities is so large, it helps to categories the entities into smaller more manageable groups.  This is done using SIC codes. Rather than having a human have to read the list like many publish this information; I republished the list of SIC codes in an XML file which I can read.
• List of queries: You want to be able to query the data in XBRL filings.  I am using a standard form for providing the list of fact values to grab: XBRL. I simply create an XBRL presentation linkbase which contains the concepts I want to analyze and then read that taxonomy to get the information I want to analyze.  Here is an XML file which contains the list of queries I created for the prototype. Here is one of the XML representations of the network relations. (Note that the XBRL taxonomy is pre-processed into an easier to query resolved set of relations.)
• XBRL instances: Of course, you want the filed information, that comes from the XBRL instances filed with the SEC.  Here is one of those.  The entity list above points to the filings of each SEC filer, that is how they are found within the SEC EDGAR system.
• Filer XBRL taxonomies: The filer XBRL taxonomies which you can see in the prototype are the filed taxonomies, pre-processed so they can be easily read by the Excel application without the use of an XBRL processor.  You can see one of those here.

The Excel interface simply pulls all this information together.  What the application can do is limited because it does not use an XBRL processor. Or rather, better said...an XBRL processor would make it far easier to make the Excel application do useful functions.  But as you can imagine, none of this happens by magic.  The application is driven by data provided to it. If the application has the data, such as the SIC codes to categorize entities into groups, the application can make use of that data to help the user.

Video of application

Here is a short video which shows the basics of using this Excel based application.