Digital Financial Reporting

When creating a prototype I stumbled across something of interest which helps to show XBRL's ability to detect possible errors within a data set.  I am not saying that this is, or is not, an error.  But it does look like an error. I am trying to determine what is going on and am trying to find someone in the US Census Bureau who can help indicate what is going on.

So here is the deal.  The US Census Bureau makes summary financial information available for the US States. See the 2008 Annual Survey of State Government Finances here. More specifically, see under "Downloadable data" the summary table in Excel.  That is an Excel spreadsheet containing what amounts to an income statement for each US State, and an aggregation of the information for the total of the states in the column "United States".

I was using that data to create a demo and when I ran the XBRL validation against my data, I got some errors.  I will walk you through that in a moment.  But, here is an Excel spreadsheet which shows what could possibly be an error in the data.  If you don't have Excel, this graphic also shows the possible error.  What is going on is the line item "Insurance trust revenue" does not cross cast (i.e. the numbers for the individual states don't add up to the total in the United States column). That same discrepancy exists within Total revenue, of which "Insurance trust revenue" is part.

Now, I am not saying definitively that this is an error.  But, one of two things is going on.  (A) It could be an error or (B) the fact that the number does not add up like all the other columns is not documented within the data set.  It seems logical that others using this data might have the same question as I do given that all the other line items add up and given that it seems logical that everything should add up.

So why was I able to discover this?  Well, for my prototype, I was using that state financial information.  I created an XBRL taxonomy and in that XBRL taxonomy I created business rules which both document how things add up and allow me to verify that everything does in fact add up.  These business rules come in two forms. First, a set of XBRL calculations which show how the income statement adds up.  Here is a rendering which shows this.  Now, this is easier for a computer to read in the actual taxonomy. The result of running the XBRL instance information through the validation generates this report. That report shows first, how things add up and second the fact that the numbers do add up correctly in each of the 50 state income statements and in the total fur the United States as a whole.

The second test I ran is to use the fact that the 50 states do add up to the United States total, basically the relations shown here.  I created an XBRL Formula to express this relation, you can see that here but it looks rather ugly and I have not created a rendering of this. Computers can read business rules expressed in a global standard format and generate something like this, called a formula trace, this on generated by UBmatrix's XBRL processor.

This business rule generates this report which shows the descrepencies in the numbers. Now, you see four errors rather than two because I added two line items to the data set which calculated the net revenues over expenses and another concept showing the net Insurance trust activities.

Here is the bottom line.  I don't know if this is really an error or not, but the more important thing is that XBRL can document whether the numbers are supposed to add up and if the, in fact, do when the data is made available.  This report shows that the numbers foot. This report shows if the numbers crosscast (admittedly, this could be formatted nicer to make it more readable).  These reports are generated in off the shelf software.  The metadata communicating that the information adds up (or not) is made available with the information itself.  Here is the XBRL instance. Plug that into any off-the-shelf XBRL enabled tool and plug the XBRL formula in, and you will get the same result (the software does have to support XBRL Formula of course, many do).  That is right, not only can you validate the information, but the validation is portable between business software applications!

You can still get the data and read it, just like the US Census Bureau provides in in Excel.  This tool can be used to extract information using a very simple Excel macro. No XBRL processor was used, but that would make writing the already easy to write code (I wrote it, I am a CPA not a programmer) even easier.  (Note that there are a number of different formats you can extract the data from, find the tab "Financial - XBRL".)

XBRL often gets criticized for being complex.  Imagine that you had this simple set of data, a list of the U.S. states and their population.  What is complex about this (if you cannot see these files in your browser, try your view source option to see the file contents):

• XBRL Instance: This looks a lot like what someone who might create traditional XML would come up with.  (I know that there are many different ways this XML could be structured. That is just one commonly used way.)
• XBRL Taxonomy: This XML Schema looks a lot like what someone who might create a traditional XML Schema might come up with.  You can even validate this using an XML validator.

Anyone who can write an Excel macro could generate this form of XML. Why might you use this approach to creating your XML?  Well, you would be following a global standard rather than rolling your own form of XML.  XBRL provides a framework to work within rather than inventing your own.  There are other reasons one might consider this approach.

Eventually you will start asking some questions, or you should ask some questions.  How would you verify the data to be sure that the populations of the states add up to the total US population (see that total in the PDF).  Well, if you added a calculation linkbase XBRL could provide you with that functionality.  For example, if the calculation linkbase were provided you would get a validation report which looks something like this.  Sure, you could write your own proprietary validation routine...but that takes time and money.  Also, because you used your proprietary validation you will not be able to share that with anyone else because it is proprietary.

Another thing you might want to add to your XML is labels for the element names so you don't have to deal with things that look like "WestVirginia" (XML element names cannot have spaces), but rather "West Virginia" which most users might prefer.  No problem, you could write your own way to add labels to your XML and not use the label linkbase which XBRL offers.  What about providing USPS codes for the states such as "WV", and abbreviations like "W. Vir.", and other such labels.  And what about multilingual capabilities.  Sure, you could add all this to your XML.

Do you see my point here?  There are two.  The first point is that you could use XBRL without the linkbases.  That would make your implementation of XBRL significantly less complex, almost like tradional XML.  You would be constrained slightly in terms of what you can do, you would have to follow the approach of creating XML that the XBRL framework requires.

The second point is that you will run into issues such as how to validate computations.  That is why XBRL has XBRL calculations and XBRL Formula, not because people wanted to make XBRL more complex, but rather because the real world of business reporting has numbers and those numbers have relations.  XML Schema validation cannot handle the validation of computations.

Basically, if you rolled your own XML, you would end up creating a lot of the functionality which XBRL already has.  That is why the functionality is in XBRL, because the business people creating it needed the functionality.  Business reporting is complex. XBRL has to serve the real needs of everyday business reporting.

You don't need to use all the features of XBRL.  Start with only an XML Schema.  Experiment.  When you realize that you do need something like the calculation linkbase or label linkbase, you can add them later.  When you realize that you do need XBRL's extensibility, it is there waiting for you to discover.

Besides, XBRL is a global standard.  It is a framework.  Sure, it takes a little more dicipline to use XBRL than just writing your own XML.  That can be a good thing, or that can be a bad thing.  You can decide based on your needs.

If you believe XBRL is here to stay (there is plenty of evidence that will be the case), then it is time for certified public accountants and charted accountants to understand some things about XBRL. Even some attorneys will need to understand some of these details.

These are not details relating to the technology, rather they are details of financial reporting which the technology needs to be able to deal with.  This is not a list of all those details, here I am focusing on information being reported within a financial report which is expressed using XBRL. This may not seem important to you now, but keep in the back of your mind that one day the XBRL will be the source document which drives the financial information which is presented.  Today, most accountants look at XBRL as something additional you do after print your financial report.  That will not last for long, that approach is simply a step in the evolution of XBRL.

If you are expressing information in XBRL, you will want these details to be expressed correctly.  These details relate to expressing information correctly within an XBRL financial report.  The information you express are called facts.  These facts are described by other information which identify the fact and help represent the information you are disclosing.  There are various approaches to checking to see if what you expressed comes across as what you desired to express.

So, what exactly is a fact?  A fact is something you can observe.  For example, here is a fact with some of the information which identifies the fact and helps to express the fact:

Cash and cash equivalents amounting to $1,000,000 for the consolidated group for the end of the third quarter of 2009 which rounded to millions of US dollars reported in the financial statement released on February 18, 2009.

Again, that is only one fact, some of the information which helps identify that fact and other information which helps you to identify that fact.  You will have thousands of facts and there is various information which helps identify those facts and helps you represent those facts.  You have processes to help you be sure you expressed these details correctly.

Here is a fairly comprehensive list of identifying information and which helps you express that fact which you should be considering when you create your financial information in XBRL:

• Concept: Every fact has a concept to which that fact relates.  The concept tells you what the fact is, for example "Cash and Cash Equivalents". Concepts have additional information relating to them such as the definition of the concept, labels, whether it is a debit or a credit, and so forth. There is much more to concepts, but let's stop there for now.
• Report date: Every financial report has a report date, most of the time being the date of the audit opinion attached to the report.
• Fiscal period: Information within a report relates to a fiscal period which you know might not be a calendar period.  Fiscal periods might not correspond to months, for example the retail industry uses a 52/53 week fiscal period in many cases.
• Reporting entity: The reporting entity is the entity reporting the information which may not be the entity which the information is about.  See legal entity which is next.
• Legal entity: The legal entity is the entity to which the information being reported relates.  It may, more may not be, the legal entity.
• Operating segment: The information being reported may be for the consolidated group or parent, or it may be for one of the operating segments of the consolidated group.
• Operations continuing or discontinued: The operating segment for which information is reported might be continuing or it may be a discontinued segment.
• Measurement basis: The information being reported could be reported at historical cost, amortized cost, fair value, or some other measurement basis.
• Restatement: The information could have been restated due to a change in an accounting policy or because of an error in a prior period report.
• Reclassification:  The information of a prior period may have been reclassified to match the classifications in your current financial report.
• Reporting scenario: The information being reported could be actual information, or it might be forecast information, or perhaps even budgeted information.
• Third party verification: The information reported could be covered by a third party audit report or it may not have been audited at all.
• Other descriptive information: All sorts of other details could be important to specific types of detailed information such as the class of long term debt or a specific category of subsequent event.  These details may, or may not, be important to communicate. 
• Value of fact: Information reported could be a number such as "1,000,000" or it could be a piece of text such as "First in-first out", or it might even be an entire paragraph of text describing an accounting policy.
• Rounding: If the information reported is a number, the number could be rounded to the nearest millions of dollars or detailed to the nearest cent.
• Reporting units: Maybe the units are not dollars at all, but rather Euros or some other currency.  Or, the number might not even be monetary but rather the number of employees or the barrels of oil within a reserve.
• Reason information is not reported: Sometimes for a number of reasons the information which is required to be reported is not available and you need to explain why that information could not be reported.
• Relations to other facts or concepts: Facts reported relate to other facts being reported.  For example the line items of a balance sheet add up or "roll up".  A cash flow statement not only adds up (i.e. the net change in cash), but it also communicates a "roll forward" of the beginning balance of cash to the ending balance of cash.  Or, maybe the fact is not a number and therefore not involved in a computation but is rather an accounting policy and you want to organize it with your other accounting policies.

Another question to ask yourself is how the analyst using this information interpreting the information?  Is the analyst going to have to imply any meaning because when you reported the information you were not being explicit.  Is that analyst going to correctly imply the right meaning?

Sometimes XBRL taxonomies don't help you understand how to report certain identifying information or information which helps you properly represent the information you need to report in XBRL.  If the XBRL taxonomy does not, you will still need to do something to be sure the meaning you are trying to articulate will be interpreted properly by users of the information.

The bottom line is to ask users of the information if they are having any issues making sense of your XBRL based financial reports.  But the CPAs/CAs who create this information, those who review this information, internal auditors who work with this information, third party auditors dealing with this information, attorneys who help prepare and work with this information, and others need to be conscious of what they are saying in their XBRL based financial reports.  Software can help you, but you are the one who is ultimately responsible for the quality of your XBRL based financial reports.

This is my next iteration of what I have been calling an interactive information viewer:  Interactive Information Viewer.

(Here are blog posts which discuss and can take you to prior versions of this prototype:  First version, Second version.)

In this most current version I have incorporated many, but not all ideas yet, from this blog post relating to the best ideas for getting the most out of your XBRL architecture.  I guess I started on this idea of what I am now calling an interactive information viewer when I was working on the US GAAP Taxonomy.  I took what I learned from that process, took it further, and came up with XBRLS which is basically a profile of XBRL. Additional ideas came from the COREP taxonomy and from the FINREP taxonomy.  What I called a "neutral format table" had evolved into "interactive information viewer".

Fundamentally, I am stil pursuing the goal of a business user defining a data model (dynamic model where extension is an option, not a static form), articulating information based on that data model, exchanging that information with another business user within an automated process.  There can be zero ambiguity, the semantics need to be understood the same by both those creating and consuming the information, the information needs to be readable by a human and by a computer AND all this needs to be done by business users...no IT department assistance at all.  Clearly this cannot be done unless there is off-the-shelf software on both ends of this exchange and that software needs to be operated by a business user.  But before that software can be built, we need to know what is needed to make all these moving parts work together effectively in order to achieve this goal.

The SEC implementation of XBRL offers a lot of clues as to how to make this work.  It seems to me if the SEC can make this work (i.e. business users filing financial information with the SEC) then I should also be able to get this to work.

The term "interactive information viewer" comes from the following.  First, the SEC used a term "interactive data".  I borrowed from the SEC but changed the use of data to information because XBRL is really more concerned with information than data. (See this blog post for more information on that difference.)  The "viewer" part comes from the notion of the way you look at business information is more how a Microsoft Excel pivot table might work or how a business intelligence tool works.  Basically, there are two things that you gain.  First, the information on the report is not fixed, the user can move it or reconfigure it.  Second, you loose the two dimensional nature of paper meaning that a computer can present things in more than two dimensions.

So in this prototype, imagine you could reconfigure the columns and rows or take a column or row and move it to the "Slice" section in the upper left hand corner.  Again, much like an Excel pivot table or business intelligence application.  There are three things which make Excel pivot tables and current BI applications not do the job here: (1) They don't understand XBRL, (2) They like the aggregate things (i.e. the OLAP piece), (3) They don't handle text well (i.e. they are optimized for numbers, not numbers and text).  These things will be worked out I am pretty sure.

So, an interactive information viewer is configurable in that the consumer of the information can "pivot" things to see them how they desire to see them.  This blog post discusses more of the characteristics of such an application.  Here is a demo/tutorials of one software application which shows you some of the basic ideas here (see the "The Basics of Quantrix Modeler" or the video tutorial on the left side).  Remember, here they are only dealing with numbers; but imagine if you could use numbers or text in the models.

The key here is the XBRL taxonomy.  All this is very, very possible today...but the problem is that every solution is proprietary in that you have to use the data format of those applications.  So, you cannot exchange the data between applications.  If business users can agree on one way to create a taxonomy and if ever software application supported that format, then we would have what we need.  XBRL is capable of doing this, but XBRL "out of the box" is just too flexible, there are too many options. So, we just need to agree on a subset, a profile, of XBRL which is 100% compliant to the XBRL specification.  Then enough software needs to support that profile.

The following is a list of the top ten (or so) ideas for getting the most from your XBRL architecture.  These ideas are based on assessing how well a number of different well-thought-out XBRL architectures seem to be working. Also, as part of the XBRL International Taxonomy Architecture Working Group where these sorts of things are discussed, I believe these ideas can help improve any implementation of XBRL.

While these ideas are good to consider for any system which implements XBRL, the ideas are particularly important for systems which allow for the extension of XBRL taxonomies.

1. Create a clear, unambiguous, formally documented information model. One of the biggest problems XBRL taxonomies have is inconsistent information models.  An information model is simply how the relations within a taxonomy are structured.  This is of particular importance when extensibility is employed within your system.  For example, the US GAAP Taxonomy creates structures such as [Table]s, [Roll Forward]s, and other such structures.  They explain how these structures are to be created.  You should do the same in order to be able to evaluate how your taxonomy is created and in order to explain how your taxonomy should be extended.  Taxonomies are simply not random.  Make yours clear, unambiguous, and formally document it so those extending your taxonomy can follow the rules.
2. Use either segment or scenario, there is no real reason to use both.  Eliminating unnecessary options makes things easier.  There is no semantic difference between using the segment context element and the scenario context element.  Besides, if different XBRL instance creators use different elements, comparability then becomes an issue.  You can avoid both of these problems by simply using one or the other. Which is as easy as tossing a coin really.  Using scenario seems to be the best, but the US GAAP Taxonomy suggests segment.  You can pick.
3. Tuples and XBRL Dimensions are redundant, pick and use one or the other; personally I prefer XBRL Dimensions. The biggest problem with using both tuples and XBRL Dimensions is explaining when to use one and when to use the other.  The primary reason I don't like tuples is because they significantly inhibit extensibility.  Basically, tuples add back the XML content model with XBRL worked to remove.  XBRL Dimensions can do everything that tuples can do, but tuples are not nearly as functional as XBRL Dimensions.
4. Don't mix dimensional and non-dimensional models; personally I prefer a dimensional model.  If you use XBRL Dimensions, then every concept should be attached to a hypercube thus requiring the dimensions of the concept to be explicitly identified.  Mixing a dimensional model and a non-dimensional model causes headaches which can be avoided by simply using one model or the other. Since business information is inherently dimensional anyway, I personally prefer a dimensional model, using XBRL Dimensions consistently throughout your XBRL taxonomy.  Mixing models also make using XBRL Formula much trickier.
5. Precision and decimals are redundant, pick and use one or the other; personally I prefer decimals. The precision and decimals attribute on a fact value serves the same purpose.  There is pretty much universal agreement that only one of these should have been created. Having both causes more work when working with XBRL instance information which contains both.  FRTA suggests that decimals be used.  So does the US GAAP Taxonomy.  I agree and suggest using decimals because it is easier for business users to understand.
6. Always differentiate dimension values and concepts.  When creating an XBRL taxonomy you don't want users of the taxonomy to mix up what is a dimension value (such as a domain or a member) and what is a concept which can be used to report a value.  The US GAAP Taxonomy diferentiates domains and members by appending "[Domain]" or "[Member]" to such dimension values and assigning those types of elements to a special type value of "domainItemType".  You could also use the substitutionGroup to differentiate these two types of XML Schema elements. That way, users don't get confused.
7. Make each hypercube unique. There are advantages to making each hypercube in an XBRL taxonomy unique.  Take a look at this taxonomy. Search for the line items which say "Statement [Table]".  You can see what I am talking about more clearly by looking at this. What is the point of using the same hypercube for each set of dimensions and concepts?  Why not use a different unique hypercube name for each hypercube?  This has a number of benefits, including making the extended link as any form of semantics unnecessary.  The FINREP taxonomy makes each hypercube unique.
8. Don't use complex typed dimensions. Complex typed members allow literally any XML you can think of as a possible value, except for XBRL itself.  It is way too much to ask for a software application to implement something like this.  Further, using it to compare to entities effectively can be quite challenging.  You can achieve the same results by using a number of simple typed members, which are much easier to build an interface for and easier to make work.  Complex typed members for dimension values are far more trouble than they are worth and should be avoided.
9. Don't be redundant in expressing taxonomy information. If you express things twice in two different ways, you create work in that you now have to make sure the two things you are expressing are in sync.  For example, expressing information in a presentation linkbase and also in a definition linkbase causes such redundant information.  The FINREP taxonomy figured this out and does not make a presentation linkbase available with its taxonomy.  In the short term this can be a bit of a challenge to effectively do because most software applications rely on the presentation linkbase.  Overtime and as software gets better, this will not be an issue.  First, realize that you are creating redundant information.  Second, if you can, you may want to consider not making this redundant information available in your XBRL taxonomy.
10. Give serious consideration to using XBRL Formula rather than XBRL calculations. XBRL Formula is several orders of magnitude more powerful that XBRL calculations.  Also, XBRL calculations have their idiosyncrasies.  More and more people are moving to XBRL Formula.  You may want to give strong consideration to abandoning XBRL calculations and using XBRL Formula instead.  XBRL calculations can be easier in certain situations.  The tradeoffs should be understood and evaluated in making your decision.
11. Be sure to require that all hypercubes be closed.  All hypercubes you create which have an "all" role should be closed (and all your hypercubes which have a "notAll" role should be open if you happen to use those).  Leaving a hypercube open basically lets anything exist in the context.  What is the point of that?  Be explicit and close all your hypercubes.

Understanding and using these ideas can make the systems you use XBRL within work better, more consistently, and with far fewer issues.  Consider them when you make your implementation decisions.