Digital Financial Reporting

This is yet another iteration of the interactive information hypercube viewer that I keep fiddling with.  See this blog post for information on prior iterations.

This version is a major step forward because it actually works!  You can grab information about this prototype here. Read that overview document to understand what is going on.

Note that this version implements the financial reporting logical model (draft) that the XBRL International Taxonomy Architecture Working Group is working on.  The point of the prototype is to test that logical model so that I can provide input to that group.

I would encourage you to grab the Excel prototype application and check it out.  See that overview page for a link to a ZIP file which contains the prototype. If you fiddle with the application what I am hoping that you see is that the XBRL instance information renders quite nicely and is definitely very readable by humans. The rendering is driven by two things: the XBRL instance/XBRL taxonomy DTS (discoverable taxonomy set) information and logic in the Excel application which takes advantage of the financial reporting logical model.

This works even better than I had anticipated. I always thought the rendering would be 98% of what one might want, the user would have to do 2% of the work to adjust the slicers, rows, and columns.  But, I was able to get 100% of what I wanted automatically.  The roll forward is not quite what I desire but I know how to fix that without too much effort.

Don't be fooled by what might appear as the simplicity of what you see.  This is not a simplistic implementation of XBRL. In fact, it is quite robust. The US GAAP Taxonomy and SEC XBRL reporting can follow this model. The model is simple, not simplistic.  That is the idea: make it simple and easy to use.

I am getting more and more evidence and insight into what an XBRL application for financial reporting can and should look like. I am seeing that it is very possible to hide XBRL in the background.

The XBRL International Taxonomy Architecture Working Group is looking for software vendors to experiment with the financial reporting logical model.  If you are interested, send me an email or contact XBRL International for more information.  This is a great opportunity to not only experiment and learn more about XBRL.

Well, it seems that there was in fact an error in the Census data set which I thought might have existed as I mentioned in this blog post.

You can see the Census Bureau's revised Excel data set here.  (Or you can grab it from the State Government Finances page here. See the "Summary Table" [Excel, 43KB] link on that page.)

So let me summarize the chain of events:

1. I was creating an XBRL prototype I called the State Fact Book. The primary purpose of the prototype was to test the differences between XML, XHTML, XBRL and RDF.  See this blog post for more information. Here is the actual analysis.
2. This spreadsheet shows the error. This screen shot also shows the error.
3. For this prototype I used some publicly available data.  Part of that happened to be some data from the US Census Bureau (the link above).
4. In creating the XBRL, of course I wanted to make sure I was doing everything correctly, so I created several XBRL formulas to verify that I was not making any mistakes.  Here is the XBRL Formula file.  Here are the human readable rendering of the validation results. This was generated by the UBmatrix XBRL processor which supports XBRL Formula. Note the "notSatisfied" results.
5. Someone in government read my blog post and decided to investigate if this was in fact an error.  They wrote a letter to the Census Bureau.  Here is the letter.
6. The letter and this story was reported in NextGov.
7. This revised data set clearly shows the revision to the US Census data.

Could have this error been discovered using Excel formulas?  Sure it could have been discovered.  But, there are no formulas in that spreadsheet data set.  A business rule in a global standard format could have been created which is useable by both the creator of the data (here the Census Bureau) and the consumer of the data (in this case myself or anyone else using that data).  The business rules in a global standard format does not limit your use of those rules should you not use Excel.

The points here are as follows: (a) if you publish information and that information has numeric relations, it is important to publish business rules that both document how the information adds up and proves that the information adds up; (b) this is what XBRL Formula is for and as you can see it does work; (c) the key advantage of the global standard XBRL Formula is that the business rules are not application dependent, but rather can be exchanged between business systems independent of the system.

There is no intent here to beat up on the U.S. Census Bureau.  It just so happened that I stumbled upon this error because I wanted to be sure my system was not reporting incorrect information.  In my years of creating XBRL demos, I have run across this type of error before in SEC filings.  These information sets are complex. Other errors exist in publish information sets, you can count on that.  XBRL and XBRL Formula when properly used can improve data integrity.

In a blog post a few weeks ago I pointed out how I discoved a possible error in some U.S. Census data.  An update.

A letter was sent to the Census Bureau pointing out this possible error. Also, NextGov picked up on this in a story.

No word from the Census Bureau as of yet but the story says they acknowledge receiving the letter and is looking into this matter.

Many times when I hear people discuss XBRL or evaluate how XBRL is suited for a task I get the sense that they are looking at XBRL from what amounts to an incorrect perspective. This is particularly true to XBRL as it is applied to financial reporting.

The Big Picture

XBRL is a tool which must be applied properly to achieve an agreed upon set of domain objectives. If the domain objectives are ambiguous the results will also be ambiguous. Creating a logical model of a domain is a technique to ensure a technical implementation will work correctly. If a sound logical model is created, any implementation which follows that logical model correctly will work, no matter what technical implementation or syntax is used.  However if the logical model is either the wrong model (i.e. the logic is not correct) or ambiguous (i.e. multiple legal implementations can be created within the logical model because the model is flawed and allows undesired variations), undesired outcomes will be the result.

Some reasonable questions one might ask relating to the financial reporting domain might be:

• What is the logical model for financial reporting? 
• Who specified that logical model?
• Is that logical model the logical model which we desire?
• Is there undesired flexibility in that logical model allowing for undesired results which employs that model?
• How well do the domain master craftesmen employing the XBRL tool understand the tool?

XBRL is a Tool

The first important thing to recognize about XBRL is that it is a tool. Yes, XBRL is a tool, just like a saw is a tool. You can take advantage of a tool in different ways.  And while it may only take a few hours to learn how to use a tool, it can take more time to become competent with the tool and even more time to master the tool.

A saw is a tool.  You can learn the basics of using a saw in less than an hour. But does that mean that you have the skills to build a high quality piece of furniture?  Of course not.  In the hands of a master craftsman a tool can be used to create a beautiful piece of furniture.  In the hands of a lesser skilled individual, what they create with the same saw is likely not something that you would want to put into your living room.

Applying the XBRL Tool to Financial Reporting

Just like the person who has a saw and wants to build a piece of furniture has the responsibility of understanding what they want from that piece of furniture, any domain, such as the domain of financial reporting, it is critical to have a clear vision of what they want to get out of the tool.

What does financial reporting want to get out of XBRL? Well, the US GAAP Taxonomy Architecture explains this to a degree for SEC financial reporting. Section 2, the Domain Model explains what that implementation of XBRL wants out of XBRL. But is this what the financial reporting domain wants? And how do you know that the desired functionality will result, without undesirable characteristics?

That same document, section 3, explains the Logical Model employed by the US GAAP Taxonomy to help figure out the physical implementation of the domain wants from XBRL. Section 4 of that document goes on to explain the Physical Model. The physical model is basically the physical implementation of the logical model to meet the needs of the domain.

Logical Model is Key

The logical model is key to getting the implementation correct. If the logical model works well, any good implementation of that logical model can potentially work, no matter what syntax one uses.  If a physical model or implementation is based on a poor or an incorrect logical model, the physical implementation cannot possibly work as desired.

There are two moving pieces relating to that logical model. First, the logical model needs to be the logical model that you desire.  Is the logic of correct?  Is the logic the desired? Second, the logical model needs to work as desired. If the logical model is ambiguous and allows for undesired variability, two people using the same model can have two different end results.  Both are legal under the logical model.

Let me give an example using Microsoft Excel.  You have all used Excel spreadsheets.  Under that logical model a workbook has one or more spread sheets. A spreadsheet has rows, columns, and cells which are the intersections of a row and a column.  A workbook cannot contain a cell.  A cell cannot contain a workbook.

A Good Logical Model Can be Implemented in Any Syntax

A clue that a logical model is good is that it can be modeled in any syntax.  XBRL is a syntax. RDF/OWL is also a syntax. To a domain user, syntax is not really as relevant as consistent semantics (i.e. meaning). Inconsistent semantics is bad because you simply cannot make up for inconsistent semantics in any syntax.

Logical Model for Financial Reporting

What is the logical model for financial reporting? Well, in the case of SEC XBRL financial reporting, that is determined by the US GAAP Taxonomy Architecture since the US GAAP Taxonomy is based on that.  The logical model is also based on the EDGAR Filer manual and whatever else the SEC might allow.

Is that logical model the correct logic?  Well, that is for those in the financial reporting business domain to decide.

Is that logical model unambiguous (meaning can users create different and potentially incompatible implementations based on that one logical model)?  Inconsistent implementations are quite easy to see and evaluate against a good logical model.

UML for Documentation of Logical Models

Many times logical models are documented with UML (Unified Modeling Language). UML is a communications tool.  It allows business domain experts to communicate with technical experts.

Where is the UML model for financial reporting? Here is a draft UML model for financial reporting. Is that the right logical model? This is certainly not for me to say. If the model is mine, than it is proprietary and therefore other proprietary models would likely be created and this would defeat the vision of one electronic model for financial reporting used globally.  Is there one logical model for financial reporting?

If you are interested, this blog post shows the sorts of things which one might include in a logical model. These have nothing to do with the XBRL technology, they have to do with the business domain.

Financial Reporting Domain is Responsible for the Logical Model

The financial reporting domain is responsible for creating the logical model they need for financial reporting. Technologists can provide the tools, such as XBRL, to implement that model.  Technologists can also help the domain users create their model.  But the logical model is the responsibility of the financial reporting business domain. The financial reporting domain needs to determine the logic.

This responsibility cannot be passed on to others, nor would you want to pass this important responsibility on to others. To do this some domain users need to master the tool to a certain degree.

The challenge here is that it takes a master craftsman to build such a logical model and most financial reporting experts are not also logical modeling experts.  That is the tightrope which must be successfully traversed.  It takes technical experts and business domain experts working together to create such a model. Applying the technology incorrectly is not the technology's fault. Ultimately, that responsibility rests with the business domain.

I have had several posts relating to what I call the "interactive information hypercube": here, here, here. The idea of interactive information hypercube grew from prototyping I was doing while testing ideas which I wanted to get into the US GAAP Taxonomy Architecture.  I was successful with many, not as successful with others. Frankly, I learned a great deal from the experience of working on the US GAAP Taxonomy Architecture group. (Go look at the authors of the document, those are XBRL heavyweights!)

I took what I learned from helping to create the US GAAP Taxonomy Architecture and took that to the next level and created what I called XBRLS with another XBRL heavyweight. Those ideas where summarized in the document XBRLS: How a simpler XBRL can be a better XBRL. In that document I called what evolved into the interactive information hypercube idea "neutral format tables".  These have also been referred to as "generic tables" and "general table format" among other things.

For my State Fact Book Prototype I created yet another iteration. This one actually works to a degree. You can get to that prototype from that State Fact Book Prototype link or this is a direct link to the prototype created in Excel. Here is documentation which walks you through the prototype.

Two other influences on this interactive information hypercube is the Interoperable Taxonomy Architecture (ITA) work I am doing with the XBRL International Taxonomy Architecture Working Group toward expressing a logical model for financial reporting. This UML model and mind map of the financial reporting domain are my input to that group.

I came up with the term interactive information hypercube in the following way:

• Interactive came from the SEC. I admit I stole that idea, it is a good one.  The SEC coined the term "interactive data". Heck, like Picasso said, "Good artists copy, great artists steal." But I did not agree with their use of the term data.
• I chose to use the term information rather than data because the hypercube are really about information, not data.  See this white paper Data, Information, Knowledge, and Wisdom to understand the difference.
• The term "cube" is used by the OLAP people, but hypercube is really a better term. A cube is three dimensional whereas a hypercube is n-dimensinal (any number of dimensions). Fundamentally, the flexibility of multidimensional model is what is important.  The ADAPT model and the OLAP Council White Paper. OLAP gets in the way as its focus is on aggregating numbers.  The interactive information hypercube can aggregate, but it does not have to.  Also, the interactive information hypercube handles text.  Most OLAP applications have a very difficult time handing text. In my view this is a limitation of business intelligence tools.

Keep all this in the back of your mind and use your imagination when you have a look at the prototype/demo. This is not a truly functional application, I took some short cuts which are explained in the documentation. I get more and more convinced that this is a good idea the more I fiddle with it.

If you look at a business report, such as a financial report, they are really a bunch of hypercubes strung together.  Here is an example of that I put together in 2007, stringing pivot tables together: PDF of a financial, same financial as Excel pivot tables.

You can achieve this today give the right XBRL taxonomy architecture.  The US GAAP Taxonomy is a big step in that direction but is still a little too inconsistent in the way it is built.  XBRLS provides better discipline in terms of how to structure your XBRL taxonomy.  Given the right architecture, rending seems both easy and it provides the "interactive information", the ability for the consumer to reconfigure the information and have it their way.