Digital Financial Reporting

(A downloadable PDF version of these recommendations and the results of the analysis refered to can be obtained here.)

Helping to create XBRL, helping to create multiple XBRL taxonomies including the US GAAP Taxonomy, helping to create the US GAAP Taxonomy Architecture, helping to test the US GAAP Taxonomy, creating XBRL instances with the US GAAP Taxonomy, and being a CPA gives me a unique perspective when I look at XBRL instances and XBRL taxonomies.  I used this perspective to have a look at SEC XBRL filings.

This is a set of the  top 10 categories of errors found in SEC XBRL filings which you should consider avoiding.  This information comes from two sets of analysis of SEC XBRL filings.  You can see a summary of the latest analysis here on my blog.

But let's get right to it.  These are common mistakes which are seen in SEC XBRL filings and how to avoid them:

1. Don't use concepts when you should be using contexts to differentiate fact values: Specifically, you don't want to do something like creating the following two concepts: my:CashBeginningBalance and my:CashEndingBalance.  Bad, bad, bad.  You never see this in the US GAAP Taxonomy.  Of 403 filers, about 9 made this mistake.
2. Don't use concepts to differentiate where a concept is used:  Specifically, don't create concepts like this: my:Cash and then my:CashCF (meaning one cash concept for the balance sheet and another concept which represents the same thing for the cash flow statement).
3. Stick with US GAAP Taxonomy concepts where appropriate: There are some filers defining their own terms for things like "cash" and "net change in cash".  See this blog post for more information.  Only 4 of 403 filers defined a concept to replace the US GAAP Taxonomy cash flow statement which is supposed to contain the value for the net change to cash.  That is a pretty good clue (4 of 403 creating a custom concept) that the US GAAP Taxonomy is most likely the way to go.  This may not be true in 100% of situations, but from what I saw from those filings, I cannot see why they had to create a new concept.  If you do not follow the pack and you create a new concept, a good idea would be to make it clear in the documentation for that concept why you felt that was necessary.
4. Check your calculations: When you create your XBRL filing, be sure to run the filing through an XBRL processor which checks the calculations. You can see what the results of these checks looks liike here. This is an example of a clean filing with no calculation inconsistencies. This is an example of a calculation inconsistency which indicates which, if compared to the HTML filing, is really an error.
5. Prove all your computations: Prove to yourself that all the computations add up correctly.  This means not just the XBRL calculations, but also the [Roll Forward]s which cannot be validated by XBRL calculations.  Another category of computations which XBRL calculations cannot validate relate to aggregations across dimensions.  You need XBRL Formulas in these cases.  Use both of these, XBRL calculations and XBRL Formula, to prove that 100% of your computations are correct.
6. Follow the US GAAP Taxonomy: If you look at the US GAAP Taxonomy you will notice that it is constructed quite consistently and a in very specific ways.  You should follow that guidance within your filer extension taxonomy.  The SEC or XBRL US do not provide rules to enforce this currently, but they will eventually.  An example of what I am talking about here can be seen in this analysis. What this analysis did was to look at one specific area of the US GAAP Taxonomy information model: the [Table].  Per the US GAAP Taxonomy Architecture (see section 4.5 Implementation of Tables on page 38 of that PDF), a [Table] must always have at least one [Axis] and it must have exactly one [Line Items] concept.  Further, since the US GAAP Taxonomy uses [Table]s to express every primary financial statement, you would expect that there would be a [Table] for each of those.  This is what the test results would look like for a well prepared filing. This is what the test results would look like if you you are not following the US GAAP Taxonomy structure for a [Table]. If you want extra credit, model EVERYTHING within a [Table].  There are about 10 filers who already do this.  In my view, that is where the US GAAP Taxonomy will be moving to in the future. I will stop with that recommendation for now, if you want further information on this send me an email or read my blog.
7. Avoid rounding within the XBRL instance, take care of this when creating the filing: Of 403 filings that I looked at, only one showed a computation error as a result of rounding.  It is far better for filings to add up correctly within the filing than to force investors and analysis to deal with these rounding issues.
8. Don't stand out in the wrong areas:  Sure, if you have a great financial statement you obviously do want to stand out to analysts.  But you don't want to be a stand out for the wrong reasons. For example, of 403 SEC XBRL filers all but 8 followed the US GAAP Taxonomy computation of net change in cash.  These 8 seem to be making a mistake from what information I have accumulated.  You can decide if this is, or is not, an error for yourself, see this blog post. Far be it from me to say whether the 8 are correct, or the other 395 are correct.  Whether this is truly an error or not is not my point.  The point is, if you are not following the pack, you really should be able to explain and justify why.  If you are comfortable with that explaination you are OK.
9. Push for software interoperability: One software vendor, XBRL Cloud, says that 28 filers have filing errors, per the Edgar Filer Manual, in their filings.  Yet, the SEC accepted the filings.  How is that possible?  XBRL Cloud publishes its validation results that they on the web.  The SEC publishes a test suite. Other vendors have software and they test their software against the SEC's test suite.  Other vendors may disagree with the SEC test suite, I cannot tell for sure because they don't publish results on the web.  It will take time for all the software vendors and the SEC to get on the same page in this regard. Eventually, all software vendors and the SEC will all have the same validation results.  For now, just go for the least common denominator.  Check out the errors which are being reported.  If you can make them go away by fixing something, then I would suggest fix them.  Talk to your software vendor and ask them if they feel the errors are valid.  I predict that these differences in validation results will get resolved over the next six months or so.
10. Help investors use your information: In general, do things which make it easier for investors, analysts, and others to use your information.  Not quite sure what those things are?  Well, this list is a good starting point.  Asking analysts is another idea, help them automate their analysis models rather than throw things in that make it harder to automate their analysis.  Clearly you don't want to change the meaning of what you are reporting, you still need to properly reflect your financial information, don't change that.

For those of you who are not SEC XBRL filers or support those filers, these same errors should be avoided in other uses of XBRL also generally, not just in SEC XBRL filings.  The point is that even if you have nothing to do with SEC XBRL filings, the list above is good information to know.

Want more details?  See here and here.

Analysis of the details of why the roll forward computations of the cash flow statement shows some very interesting results.  Also, the results are very encouraging because they show a very finite and solvable set of issues.

The details of my analysis can be found here. This test is explained on this page, it is item "C" on that list. To quickly summarize, what I did is create an XBRL Formula to test the cash flow roll forward to see what would happen.  That formula is "beginning balance of cash + changes in cash = ending balance of cash" per the cash flow statement.  I ran this against 403 filings.  I expected two "satisfied" results from each filing. If I did not get that expected result, I then went on to find out why.

Here is what I found for the 403 filings:

• 348 filings showed two satisfied formulas, which is what I would have expected
• 15 filings used some other concept than the concept provided by the US GAAP Taxonomy cash flow statement (us-gaap:CashAndCashEquivalentsAtCarryingValue).  These included: us-gaap:CashAndDueFromBanks, us-gaap:Cash, us-gaap:CashCashEquivalentsAndShortTermInvestments, us-gaap:CashCashEquivalentsAndShortTermInvestments
• 9 filings put the concept us-gaap:EffectOfExchangeRateOnCashAndCashEquivalents in a different place than the US GAAP Taxonomy in the calcuation (see this blog post)
• 8 filings did something really nasty, a bad practice in my book, but creating distinct concepts for the beginning and ending cash balances, rather than following what the US GAAP Taxonomy does literally hundreds of times which is creating one concept and using context to differentiate the balances at different periods
• 4 filings created custom concept for net changes in cash, replacing the US GAAP Taxonomy concept
• 4 filings changed the computation relating to cash flows relating to discontinued operations
• 3 filings added a concept for cash flows relating to assets held for sale (which probably should be a taxonomy fix)
• 2 filings had tagging errors
• 2 filings added VIE related cash flows (again, this probably should be an adjustment to the US GAAP Taxonomy
• 2 filings created custom concept for cash balance concept
• 1 filing had a zero balance for cash and did not put in a concept that cash balance
• 1 filing had a funky presentation of cash which I would have never anticipated and is different than all other filers
• 1 filing had a rounding error in both their human readable version and their XBRL
• 1 filing had cash classified as a liability because they had a bank overdraft, which was done correctly but I did not anticipate
• 1 filing did not disclose the balances of cash on their cash flow statement; they did have balances on the balance sheet, but a beginning balance which was needed to get two roll forwards was no where to be found
• 1 filing needs additional work, I cannot figure out what is going on, but something is causing the formula to not work correctly

Again, you can see the specific filings here and that page also provides links to the rendering, formula validation report, the XBRL instance, and some other information so you can take a look at these for yourself.

For me, this information yields good insight on how to create and analyse filings as well as how to build taxonomies.

The following analysis points out that of 403 SEC filings, at least 345 (could be more) calculate the net changes to cash and cash equivalents on the cash flow statement one way, 8 filers do this in a different way.

345 use this equasion: Beginning balance in cash + Net changes in cash = Ending balance in cash (i.e. exchange gains in cash are included in the net change in cash, this is also the approach used by the US GAAP Taxonomy)

8 filers use this equasion: Beginning balance in cash + Net changes in cash + Exchange gains (losses) from cash transactions = Ending balance in cash

The difference between the two approaches relates to whether the effect of exchange rate changes on cash and cash equivalents is included in the net changes in cash and cash equivalents.

To me, this raises several questions:

• Are there really two (or maybe even more) ways of computing the net change in cash?
• If so, why?  What benefit does this have to anyone?
• If there are two ways, what would it hurt to use only one way in order to have better comparability?
• Will peer pressure possibly motivate the 8 to follow the approach followed by the majority?
• Are the 8 filers correct and being more progressive than the other 345?  Should this "progressiveness" be encouraged?  Is this being progressive?
• Should the FASB or the SEC or someone address issues like this? Or, should the capital market deal with this in some manner?

This specific financial line item is really not that big of a deal.  And frankly it is pretty easy to do some things to make the 8 consistent with everyone else.  But focusing on this one line item would miss the bigger point which is that this type of issue exists not only where I pointed this out here, but in many other areas of the US GAAP Taxonomy and in SEC filings.  The fact patterns are different for the different areas of the taxonomy.

In some cases different ways of computing things is very important and does, in fact, differentiate one company from another.  In other cases, and I think in this case, the difference is not a significant differentiator.

Understanding graphs is important to understanding how to use XBRL. This is particularly true if you build XBRL taxonomies with any level of sophistication.

When I say "graph", I am not talking about an "Excel graph" or "chart", those pretty pictures which display information graphically.  Although, it seems to me that there is a relation between "graph" and information which is presented graphically. (But, let's not go down that path.)

A graph is defined by Wikipedia as:

Mathematical structures used to model pairwise relations between objects from a certain collection.

Key terms from above are "model" (i.e. build an XBRL taxonomy), "pairwise relations between objects" (i.e. such as accounting concepts), and "from a certain collection" (i.e. XBRL taxonmoy).

I am far from an expert in graphs.  In fact, I am a novice really.  But, I have been listening to technical people talk about graphs and graph related terminology for many years in creating XBRL that I have picked up a few things.

These are the key things that I have picked up:

• XBRL networks (presentation, calculation, definition) are graphs.
• What most people think of as a "tree" is a type of graph.  Not all graphs are trees.  But, all trees are graphs.
• This is a Wikipedia article with a good summary of graph theory.
• This tutorial is a great little tutorial which will help you understand the fundamental concepts of graphs. It helps you understand terms used in XBRL such as graph, cycle, path, and so forth.
• Here is a glossary of graph related terminology.
• Graphs are a way to represent relations.  Showing those in a "tree view control" is only ONE way to represent that information.  It is definitely not the ONLY way.  Most software developers building XBRL applications have not figured this out yet.  Some have.  Help them understand this, it will help the usability of XBRL software.
• Terminology such as cycles, directed cycles and undirected cycles become more meaningful when you understand graphs.
• You cannot build good XBRL taxonomies if you don't understand cycles.
• XBRL is part of the Semantic Web.  Realize that RDF expresses graphs.  For right now, just keep the term RDF (Resource Definition Framework).  You will want to know about that, but let's not get into that now. You will also want to know about OWL (Web Ontology Language).  I will get into these later, again, just keep these in the back of your mind and realize that they are important.

Feel a little overwhelmed and confused?  That is always the beginning point of learning, feeling overwhelmed and confused.  Just realize that if you really want to understand XBRL to be good enough to create quality information models with XBRL, you need to understand what graphs are.  Take the time to read the information above and work through the tutorial.

Not every business user needs to understand graphs, but if you want to build good XBRL taxonomies, you definitely need to understand graphs.  Hopefully this information will help you towards that end.  I don't have the expertise to explain this to others in detail at this point, that is why I am just  pointing you to other information.

There is a belief which has reached somewhat urban legend status about calculation inconsistencies in XBRL instances. The belief is that there are certain calculation inconsistencies which can never be made to go away no matter what you do, no matter how hard you try.

Is this belief that not all calculation inconsistencies can be made to go away truly a fact or is it a mistaken belief?

Let's look at some facts.

• A set of 403 SEC XBRL filings I looked at (the second quarter of XBRL filings with the SEC), 313 had no calculation inconsistencies. The 90 that have calculation inconsistencies are listed here.  That is about 22% of all XBRL filings.  That is an improvement from the first quarter of XBRL filings.
• The set of 408 SEC XBRL filings for the first filing period where XBRL was officially submitted there were 123 filings which had calculation inconsistencies.  That was 30% of all filings.
• Of the calculation inconsistencies which existed in the set of 403 filings mentioned above, when I try and figure out why the calculation inconsistencies exist; in 100% of the cases the inconsistencies resulted from either (a) an error in creation of the XBRL instance or (b) an error in modeling the XBRL taxonomy or (c) a combination of both.
• This is a PDF which shows two filings which I looked at and tried to figure out why the calculation inconsistencies existed.  It is not my intension to pick on these two filers.  I did need to show specific details to make my point, so it was necessary to pick specific filings.  It shows how I determined that the existing calculation inconsistencies, were in fact, unnecessary and could have been made to go away by correcting the XBRL instance or correcting the XBRL taxonomy.
• There seems to be a statistically significant relationship between the filing software used and the number of calculation inconsistencies.  If there were no relationship, then it seems to me that the inconsistencies would be evenly distributed between those creating XBRL filings.  But the data that I see does not show this.  Perhaps someone with a better background in statics can check into this further.  Here is the data from XBRL Cloud.  Here is my summary of this information. You look at the data and reach your own conclusions.
• There does seem to be a realization in the filings that there is a difference between the presentation of numbers in a rendering and how that number is put into an XBRL instance (i.e. mixing up the data and the presentation of the data).  This misunderstanding is NOT what is causing calcuation inconsistencies to the extent that it did before.  This is very, very good news.

Now, I would really like to make it through all 90 of the XBRL instances which have calculation inconsistencies to figure out why the calculation inconsistencies exist.  That would take a significant amount of time.  What I may do is wait another couple of quarters until filers fix what amount to obvious errors and then undertake that task, it would yield some good information.

In my personal experience, I have never found the need to create an XBRL instance that needed to contain calculation inconsistencies and have always found that my calculation errors resulted from one of two things: bad fact values in the XBRL instance or a poorly modeled XBRL taxonomy.

Now, don't get me wrong here.  Have I had inconsistencies in XBRL instances?  Absolutely.  Some inconsistencies were down right confounding.  This was particularly true when the validation reports were harder to read. (They are not that great today, but they are WAY better than they used to be!) For example, when I was helping to create the IFRS taxonomy I always tended to have problems getting the indirect cash flow statement and the income statement to both have zero calculation inconsistencies.  What I discovered is that I was making a modeling error in the taxonomy.  To make a long story short, this helped me reach the conclusion that it is critical to create XBRL instances when creating an XBRL taxonomy to be certain that you don't model the taxonomy so that it is impossible to create an XBRL instance which does not have calculation inconsistencies.  I learned a lot about creating XBRL instances from struggling to make calculation inconsistencies to go away.

However, I am not ready to say that it is possible to make all calculation inconsistencies to go away.  And, as such, I can certainly understand the risk management decision to allow calculation inconsistencies in SEC XBRL filings which the US SEC has decided take.  But at the same time I point out that allowing these inconsistencies with no ramifications for the inconsistencies promotes sloppiness.  Evidence of this are the 90 filings with inconsistencies, the two which I pointed out above which are clearly filer errors, and the 10 or so other filings I have been through and see no situation where I would not be able to make the calculation inconsistencies to go away.

Is more evidence necessary to determine if all inconsistencies can be made to go away for every filer in all situations?  I think so.  But should there be something to motivate filers to fix obvious inconsistencies?  Personally, I think that would be a good thing.

I know accountants.  I am an accountant. We accountants like things to add up, tick, tie, etc.  Personally I think that XBRL calculations are getting a bad rap for two reasons.  First, I have personally called XBRL calculations impotent.  Why? Well, they don't cover all the computational situations which exist in an XBRL instance for financial statements.  Roll forwards are an example of something they don't cover.  Cross dimensional aggregations is another.  Second, in the early days of XBRL there was a lack of understanding between calculation and other relations expressed in networks and the XBRL instance which caused poorly created XBRL taxonomies.  I know this because I made these mistakes myself.  A good example is hooking up both indirect and direct cash flow statement calculation networks to one XBRL instance which only has fact values for the indirect network of calculations.  I get that now, others do also.

So what is the conclusion here and what is the answer?  This is what I believe:

• All this will work itself out over time.  We clearly cannot have automated processes without things adding up correctly.  It would  be too difficult to create enough software which effectively overcomes the errors in numeric data where things need to add up to be useful.
• Filers should be more careful in creation of their filings.  Part of this is to become more familiar with modeling XBRL taxonomies.
• If you find yourself blaming XBRL for the calculation inconsistencies, you are missing the point and in my view are hiding behind XBRL in an effort to basically cover up your unfamiliarity with XBRL or sloppiness.  Don't fall into this trap.
• If you feel you cannot get the computations to be expressed correctly with XBRL calculations; fine, then use XBRL Formula.  Use something to help prove out your data.  You may not be able to submit the XBRL Formulas to the SEC, but what you will learn by going through this process are the taxonomy modeling errors you are making.
• Don't mix up poor XBRL taxonomy modeling practices and XBRL calculation inconsistencies.  For example, if you think you cannot make things add up because of "dimensional issues", ask yourself, "Well, do I have my dimensions expressed correctly?"  Generally you will discover that the problem is the taxonomy.
• Look at other SEC XBRL filings which have no calculation inconsistencies and see how they modeled their taxonomy.  Ask yourself, "If they can make the inconsistencies go away, why can't I?"
• This may be asking too much, but what the heck.  It is my belief that the SEC should not give filers carte blanc when it comes to calculation inconsistencies.  There should be something to provide an incentive to not have calculation inconsistencies.  Perhaps having to explain why they need to exist in an XBRL footnote in a filing or having to re-submit if the inconsistencies are subsequently found to be caused by an error would provide enough incentive.

If you do believe you have calculation inconsistencies which you simply cannot be made to go away, I would love to see the situation.  Knowing these situations will help figure out how to tame XBRL in this area.  Personally, I am taking the stance that until there is proof to the contrary, calculation inconsistencies can be made to go away if you try.