Blog: Financial Reporting Using XBRL

Calculation Inconsistencies Cannot Be Made to Go Away: Fact or Falsehood?

2009-11-21T14:50:44Z

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.

Criteria for Evaluating Investor Friendliness of SEC XBRL Filings

2009-11-19T16:17:31Z

For the first two quarters of SEC flings of XBRL documents I have taken a look at those documents to learn more about XBRL. What I am learning is quite helpful and the filings provide a lot of insight into the realities of using XBRL for financial reporting. I hope to document what I have learned to help those who desire to create quality XBRL filings.

Accounting Trends and Techniques, published by the AICPA, is a survey of the accounting and disclosure characteristics of corporate annual reports. Accountants have a notion called common practice which guides how some aspects of financial reporting are carried out, even though there are no laws pushing the practices. Technical people refer to these sorts of things as best practices. These practices are important to get the most out of XBRL. Accounting also has what is called a model financial statement which helps financial statement creators understand how to best put together a financial statement. We need model XBRL filings also; this is the closest to such a model that I can point to today.

So I started asking myself what these practices might be, what are the criteria one might use to evaluate these SEC XBRL filings and how might those criteria be communicated. One of the first things to pop into my mind was the Gartner Magic Quadrant.

I thought about what the axes of the magic quadrant might be. Perhaps technical interoperability/usability on the vertical axis and information comparabilityon the horizontal axis. What I mean by technical interoperability/usability is can best be seen by looking at one filing. Looking at one filing ask yourself, "How well can this filing be used across different software applications." By information compatibility look at a number of different filings and ask yourself "How well can one filing be compared to another filing." Maybe those are not the correct axes of the magic quadrant, I am sure that the correct axes will reveal themselves as this is looked at more.

I believe that the criteria for evaluating an SEC XBRL filing can be boiled down into one key notion: investor friendliness. How "friendly" is the XBRL filing? How easy is it for an investor to make use of to achieve what they desire to achieve?

But to really understand what I mean by investor friendliness, technical interoperability/usability and information comparability, it is best to look at some detail. Passing the minimum hurtle of passing the SEC XBRL submission validation is really only the beginning. First off, that minimum set of validation provides no real differentiation of XBRL submissions. Further, the SEC and in general most everyone is still learning about XBRL and how to best use it. The SEC use of XBRL pushes XBRL into new frontiers because of how the SEC is making use of XBRL's extensibility features. The SEC has added new validation rules each submission period, trying to understand the new rules which will most certainly be implemented is helpful.

So what might some of these criteria for evaluating investor friendliness be?

How easy is it for an investor to compare a filing with other filings?Some things make comparing information easier, others make them harder. For example, adding a bunch of new high level concepts to replace existing US GAAP Taxonomy concepts make comparability harder. Not doing so makes comparability easier.
Do the numbers add up?Trying to build a benchmarking model using information where the numbers don't add up because XBRL calculations have inconsistencies make is harder to use a filing, having consistent calculations make automating processes easier.
Do ALL the numbers add up?It is not possible to test all computations using XBRL calculations. XBRL Formulas are necessary to validate cross context computations such as those in a [Roll Forward]. Even if the SEC does not require or does not allow the submission of XBRL Formulas yet, it is almost a sure thing that they will. And even if they never do, creating such validation used in the creation of an SEC XBRL filing is prudent to be certain that all the numbers do, in fact, add up. It may be a good thing to take this one step further and make these validation rules available on the filer's web site.
Are filer extensions consistent with the underlying US GAAP Taxonomy?What reason would a filer have for not being consistent with the base US GAAP Taxonomy? Why would the US GAAP Taxonomy go through so much effort to, say, make the [Table]s in that taxonomy always have at least one [Axis] and always have [Line Items]; but then it be a good thing for an SEC XBRL filer to break that rule? This is not a good thing, even if the SEC does not have a validation rule requiring this practice. The same is true for [Roll Forward]s and other modeling patterns found within the US GAAP Taxonomy. Having a free for all in terms of how to model a taxonomy is not a good thing.
Are extension concepts well documented?This falls into the category of consistency with the US GAAP Taxonomy but is worth specifically pointing out. The US GAAP Taxonomy does a nice job explaining the concepts within that taxonomy using documentation and references to the US GAAP literature. The documentation is helpful in understanding the taxonomy. Seems logical that an SEC filer who adds an extension concept would document the concept they added and in certain cases explain why the concept they added was different than the existing US GAAP Taxonomy concepts.

So those are the fundamental criteria which I might suggest as appropriate in evaluating investor friendliness of SEC XBRL filings. There are probably others.

What criteria do you see? Do you see some other overarching criteria which is even better than investor friendliness? If you were to create a magic quadrant, what would your axes be?

(Note that I have added a new category to my blog: Creating Investor Friendly SEC XBRL Filings. Watch for information on how to create high quality, investor friendly XBRL!)

Occurance of Fact Values in SEC Filings

2009-11-18T01:04:36Z

This Excel spreadsheet has a matrix of the SEC XBRL filers and certain concepts which I would expect to appear in an XBRL instance of a 10-Q or 10-K SEC filing. The spreadsheet is far from perfect, but it can help to see some things.

First, one error that I have in my spreadsheet is that I am looking for a specific period end date, in my case 2009-09-30, the ending date of the quarter. But there is a problem with this: filers don't all have fiscal year ends of December 31. The breakdown of my set of 403 filings is this from a query I created:

--12-31      345
--06-30      10
--12-26      9
--03-31      6
--05-31      6
--01-02      3
--01-03      3
--02-27      3
--07-03      3
--11-30      2
--12-27      2
--09-26      1
--09-27      1
--10-31      1
--01-01      1
--11-27      1
--04-02      1
--03-28      1
--12-25      1
--01-31      1
--12-28      1
--07-02      1

The strange looking fiscal year ends are 52/53 week year ends commonly used by retailers. This makes it harder to get data out of the filings because you cannot look up "all the third quater filings" as XBRL has no way to indicate "this is the third quarter. You have to figure that out.

The other thing which mucks up the data is extensions created by filers and flexibility in the concepts being reported. For example, whereas about 375 filers reported cash as the concept "us-gaap:CashAndCashEquivalentsAtCarryingValue", the rest did not; they used some other concept for cash which is other than what the US GAAP Taxonomy uses.

Is that flexibility a good thing or a bad thing? Well, from my perspective, what I see is that if there is not enough consistency at the high levels of financial reporting, there will be either little hope for compatibility and/or a number of software vendors (such as data aggregators) serving as middlemen to sort the inconsistencies out using software programs. In my view, that would not be a good thing.

I personally think that there should be a "superstructure" into which everything else fits. How much superstructure is what needs to be figured out. This is not about creating a fixed chart of accounts or a form, this is about exactly the opposite. It is about creating enought superstructure so people don't get fed up with the lack of comparability due to the inconsistencies.

Not a lot, things like perhaps:

Balance sheet (using an industry which uses a classified balance sheet):Current assets, noncurrent assets, total assets, current liabilities, noncurrent liabilities, total liabilities, total equity.
Cash flow statement: Net Cash Provided Operating Activities, Net Cash Provided by Financing Activities, Net Cash Provided by Financing Activities, Net Changes in Cash total, Effect Of Exchange Rate On Cash And Cash Equivalents, Net Cash Provided by Discontinued operations, and Cash an Cash Equivalents.
Income statement: This is a little harder but maybe Net income attributable to common stockholders, Basic earnings per share, Diluted earnings per share, weighted average shares outstanding basic, weighted average shares outstanding diluted, Income from operations, and such.
Policies and Disclosures: There are common ones, this may provide some clues. Different industries have different sets. Certainly thing such as revenue recognition, maturities of long term debt, and other standard stuff.

Then, everything would fit into that superstructure. You could also change the superstructure maybe, but there would be rigid rules for doing so. It is that superstructure and the consistency it offers which enables the ease of use and comparability needed by investors and analysts. Flexibility would still exist.

The data that I see shows that we are actually reasonably close. We do need to figure out the extension process, being more clear on when, where, and how to extend.

Again, the point is not to create a chart of accounts. The point is to avoid a random free-for-all. And actually, I don't see a free-for-all, what I see in the filings I have looked at thus far is a lot of consistency and a few bad apples.

Cash Flow Statement: Issues XBRL Raises

2009-11-17T16:53:07Z

OK, this is a good example of something which I have seen over and over in building XBRL taxonomies relating to financial reporting. This issue is NOT just for the cash flow statement, but rather I am using the cash flow statement to point out the issue.

The question is this: How much leeway should those reporting financial information really be allowed? I am NOT saying that I know the answer to this question. I can say that I do have an opinion. What I have seen over and over in building the IFRS and US GAAP financial reporting taxonomies is that there are accountants who misinterpret reporting rules and create reporting inconsistencies as a result.

Here is the what I see. The US GAAP Taxonomy for the indirect cash flow statement looks like this (this is the commercial and industrial companies taxonomy, basically all the taxonomies look like this in the area being discussed). Here is a view of the calculation relationsto come up with the net change in cash from operating, investing, financing activities as well as the exchange gain on foreign currency transactions. (OK, so here is the presentation view in that same tool.)

OK, so now I am a little confused. If you look at line number 633 on the first report, you see discontinued operations. These concepts appear both within operating cash flows from operating (line 316), investing (line 495), and financing activities (line 661) AND separately (see line 664, 665, and 666 on the report).

From the taxonomy, you cannot tell with 100% certainty cash flows from discontinued operations (line 667) is included in the reconciliation of the beginning value of cash to the ending value of cash, it is not shown in the calculation linkbase. I think it should be included.

Two SEC XBRL filers reconfigured their cash flow statements. See Citigroup and General Electric XBRL taxonomies to see how they structured their indirect cash flow statements.

The issues here to me are:

The US GAAP Taxonomy provides a concept "us-gaap:CashAndCashEquivalentsAtCarryingValue" on the cash flow statement (and on the balance sheet) which is the cash balance being reconciled; yet some filers use different concepts in the reconcilation including: us-gaap:Cash, us-gaap:CashCashEquivalentsAndFederalFundsSold, us-gaap:CashAndDueFromBanks, us-gaap:CashCashEquivalentsAndShortTermInvestments
The US GAAP Taxonomy has the total amount being reconciled as the concept "us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease". Does that include or exclude discontinued operations AND should filers be allowed to CHANGE wheter that total includes discontinued operations?
The same deal seems to be happening with the exchange gain, us-gaap:EffectOfExchangeRateOnCashAndCashEquivalents, is that included or is it not? The US GAAP Taxonomy says that it is per the calcuation it shows. At least one filer does not include that in the computation, but rather moved the relation (and they did not redefine the concept by creating their own concept).

What I am asking is how should these situations be handled, what sort of flexibility is allowed and/or should be allowed, what sort of comparability between these is appropriate for investors, and so forth. What level of consistency is appropriate? At what level of a financial is consistency and comparability important?

XBRL will help see these issues. Based on decisions which are made or not made, a certain level of consistency and comparability will exist. Will that be the level which is desired? Who decides these things: CPAs who prepare these XBRL filings? The SEC? Investors? Analysts? No one?

Again, I am not providing my opinion here (I do have one), I am simply raising the question. This question can only be addressed appropriately once it is well understood.

And remember, this set of cash flow statement issues is an example, not the only issue. Similar issues exist in other areas of the US GAAP Taxonomy and SEC XBRL filings. Different areas of the taxonomy will likely require different criteria for arriving at a decision, but the issues are quite similar to the cash flow statement example shown above.

Analysis of Second Quarter of SEC XBRL Filings

2009-11-16T20:58:52Z

Several weeks ago I published pieces of the analysis which I had done on the SEC XBRL filings where were being submitted to the SEC.

I am doing a similar analysis for the second quarter of SEC XBRL filings and you can find information on that here on my blog. I am doing this a little differently this time, learning from the past analysis. You can go look at the information, it is all summarized on that link above and you can drill into detail if you want. I will provide some information below to help you figure out how to navigate and read this information, see that below. I do want to thank XBRL Cloud for the base of my analysis. Without that list of all the filings and without some of the heavy lifting which is being done there, I would not be able to do as much as I can. So thank you to XBRL Cloud.

If you are looking for summaries, this is what you want to check out the following items on this page, which is the same link as above:

(A). Analysis Comments: Summary of analysis by filing. Shows interesting observations, issues, and specific errors identified within a set of 403 SEC XBRL filing. This is a complete list of SEC XBRL filings analyzed. (Note that this is updated periodically, so check back.)
(B). Reported Calculation Inconsistency Summary: Of 403 filings analysed, only 90 produced XBRL calculations inconsistencies. This shows a list of each SEC XBRL filing which has calculation inconsistencies reported by XBRL Cloud. This does NOT necessarily mean that the calculation are not valid, but rather point to filings which are being investigated further to determine if calculations are valid. See the analysis comments for a list of any confirmed calculation inconsistencies.
(C). Reported Test XBRL Formula Issues Summary: Of 403 filings analyzed, only 55 produced XBRL Formula validation results which were different than the expected results. This shows a list of each SEC XBRL filing which had an unexpected result for one XBRL Formula which was used to test the cash flow statement roll forward. This does NOT mean that the filer had an error, but rather it identified where a filer used different concepts then were provided for this roll forward in the US GAAP Taxonomy, or they changed a computation in some manner, or the added additional concepts to the computation for some reason. See the analysis comments above for resolution of these issues.
(D). Validation Errors Reported by XBRL CLoud Summary: Of 403 filings analyzed, only 28 produced XBRL Cloud validation errors. These errors were not detected by SEC validation upon submission for a number possible reasons including different interpretations of the EFM by XBRL Cloud and the SEC validator, different interpretations by a software vendor and XBRL Cloud, and other such issues. These issues should eventually be resolved as the SEC validation conformance suite continues to be built out, software vendors resolve these interoperability issues, etc. This list does NOT mean that the filer had an error, but rather it identifies possible software interoperability issues which should be resolved. See the analysis comments above for resolution of these issues.
(E). Information Model Summary: Of 403 filings analyzed, a hand full appear to have used the [Table], [Axis], [Line Items] concepts consistently with the way the US GAAP Taxonomy was created and consistent with the US GAAP Taxonomy Architecture (see section 4.5 Implementation of Tables, page 38). There appears to be no guidance coming from the SEC as to how to properly model [Table]s, thus the variety. This analysis is making no judgment as to what is correct or incorrect, only pointing out the wide variety that [Table]s are being used. It is likely there are similar issues relating to the [Roll Forward] and other patterns within the US GAAP Taxonomy.
(F). Excel Data Analysis Demo: This Excel spreadsheet allows someone to extract information from the set of 403 SEC filings. The macros used provide examples of how to get at the information in an SEC XBRL filing without using an XBRL processor. (Clearly you can do vastly more with an XBRL processor, but the point of this is to see what you can do without an XBRL processor.)
(G). Excel spreadsheet with XBRL Cloud Error Information Sliced and Diced: This Excel spreadsheet slices and dices the information reported by XBRL Cloud. It focuses on errors and calculation inconsistencies. No informational messages, warnings, and best practices.

I am thinking about taking this information, condensing it, and providing it in the form of a high level summary of this detailed information. Not sure if I will, or will not, undertake that task. If you have an opinion, let me know.

Seeing the Benefits of XBRL: Demo of Cross Company Comparisons

2009-11-16T16:02:30Z

Here is a little demonstration of what one can do with XBRL. Take a look at this link. The link is to an interface which I created which lets you do cross company comparisons of information filed by a set of 403 SEC XBRL filers. Here I am focusing on text blocks used to report policies or disclosures.

What I did was look through the filed data, found text blocks which were reported a lot by filers, and then picked a set of them to show in this demo. I had to be a little selective to get the demo to work right. Some of the comparisons resulted in rather large files (22 MEG, for example with 332 filers reporting "us-gaap:SegmentReportingDisclosureTextBlock", so I did not use those large files). Rather than try and make this demo scale to work with large files, I simply did not use the large files. Again, this is a demonstration.

Using the XBRL in this way is not limited to analysis of the SEC filings by investors. Consider this the following other use case.

If you are an accountant, you have probably heard of the AICPA Publication Accounting Trends and Techniques. If you are not familiar with that publication, it is basically a survey of the reporting practices of about 600 filers, created by grabbing SEC filings and reorganizing the information to compare companies. Basically this is a form of best practices in financial reporting. I worked at Price Waterhouse years ago and we had an internal publication which was similar.

Leveraging XBRL, imagine being able to build an interface into the SEC XBRL filings and be able to automatically pull information from the filings. Imagine being able to organize this by industry (i.e. SIC code maybe). Imagine not being limited to the 600 companies selected for the AICPA publication due to the manual nature of that process. Both attorneys and accountants who create SEC filings use this information to help figure out how to create disclosures.

Further, this process is not unique to SEC filings. There are many, many other forms of reports and filings where a similar workflow occurs. Being able to slice and dice this filing information allows for all sorts of interesting possibilities.

* This is the list of text blocks I am using in my demo.

us-gaap:InventoryDisclosureTextBlock (138 Filers)
us-gaap:ScheduleOfSubsequentEventsTextBlock (138 Filers)
us-gaap:SignificantAccountingPoliciesTextBlock (111 Filers)
us-gaap:BusinessCombinationDisclosureTextBlock (104 Filers)
us-gaap:DisposalGroupsIncludingDiscontinuedOperationsDisclosureTextBlock (89 Filers)
us-gaap:LongTermDebtTextBlock (66 Filers)
us-gaap:PropertyPlantAndEquipmentDisclosureTextBlock (65 Filers)
us-gaap:RelatedPartyTransactionsDisclosureTextBlock (53 Filers)
us-gaap:CashFlowSupplementalDisclosuresTextBlock (51 Filers)
us-gaap:DisclosureOfShareBasedCompensationArrangementsByShareBasedPaymentAwardTextBlock (49 Filers)
us-gaap:EquityMethodInvestmentsDisclosureTextBlock (43 Filers)
us-gaap:ScheduleOfVariableInterestEntitiesTextBlock (41 Filers)
us-gaap:OtherIncomeAndOtherExpenseDisclosureTextBlock (39 Filers)
us-gaap:LoansNotesTradeAndOtherReceivablesDisclosureTextBlock (35 Filers)
us-gaap:ScheduleOfGuaranteeObligationsTextBlock (32 Filers)
us-gaap:ScheduleOfGoodwillTextBlock (30 Filers)
us-gaap:ScheduleOfLossContingenciesByContingencyTextBlock (26 Filers)
us-gaap:AvailableForSaleSecuritiesTextBlock (25 Filers)
us-gaap:AssetRetirementObligationDisclosureTextBlock (23 Filers)
us-gaap:MinorityInterestDisclosureTextBlock (21 Filers)
us-gaap:AccountsPayableAndAccruedLiabilitiesDisclosureTextBlock (20 Filers)
us-gaap:IntangibleAssetsDisclosureTextBlock (20 Filers)
us-gaap:ProductWarrantyDisclosureTextBlock (19 Filers)
us-gaap:ScheduleOfLineOfCreditFacilitiesTextBlock (18 Filers)
us-gaap:ScheduleOfAccountsNotesLoansAndFinancingReceivableTextBlock (17 Filers)
us-gaap:FairValueByBalanceSheetGroupingTextBlock (16 Filers)
us-gaap:ScheduleOfBusinessAcquisitionsByAcquisitionTextBlock (16 Filers)
us-gaap:ScheduleOfSegmentReportingInformationBySegmentTextBlock (16 Filers)
us-gaap:ScheduleOfTreasuryStockByClassTextBlock (16 Filers)
us-gaap:TransfersAndServicingOfFinancialAssetsTextBlock (16 Filers)
us-gaap:ScheduleOfStockByClassTextBlock (15 Filers)
us-gaap:ShortTermDebtTextBlock (14 Filers)
us-gaap:OtherLiabilitiesDisclosureTextBlock (13 Filers)
us-gaap:MarketableSecuritiesTextBlock (12 Filers)
us-gaap:CollaborativeArrangementDisclosureTextBlock (11 Filers)
us-gaap:PublicUtilitiesDisclosureTextBlock (11 Filers)
us-gaap:InterestIncomeAndInterestExpenseDisclosureTextBlock (10 Filers)
us-gaap:PostemploymentBenefitsDisclosureTextBlock (10 Filers)
us-gaap:ScheduleOfRestructuringAndRelatedCostsTextBlock (10 Filers)
us-gaap:CommitmentsDisclosureTextBlock (9 Filers)
us-gaap:ScheduleOfDefinedBenefitPlansDisclosuresTextBlock (9 Filers)
us-gaap:ConcentrationRiskDisclosureTextBlock (8 Filers)
us-gaap:DetailsOfImpairmentOfLongLivedAssetsHeldAndUsedByAssetTextBlock (8 Filers)
us-gaap:ScheduleOfDerivativeInstrumentsTextBlock (8 Filers)
us-gaap:ScheduleOfOtherAssetsNoncurrentTextBlock (8 Filers)
us-gaap:AccountingChangesAndErrorCorrectionsTextBlock (7 Filers)
us-gaap:DeferredCostsCapitalizedPrepaidAndOtherAssetsDisclosureTextBlock (7 Filers)
us-gaap:EnvironmentalLossContingencyDisclosureTextBlock (7 Filers)
us-gaap:PartnersCapitalNotesDisclosureTextBlock (7 Filers)
us-gaap:UnusualOrInfrequentItemsDisclosureTextBlock (7 Filers)
us-gaap:DisclosureOfLongLivedAssetsHeldForSaleTextBlock (6 Filers)
us-gaap:FullCostMethodOfAccountingForInvestmentsInOilAndGasPropertiesDisclosureTextBlock (6 Filers)
us-gaap:RealEstateDisclosureTextBlock (6 Filers)
us-gaap:ScheduleOfRestrictedCashAndCashEquivalentsTextBlock (6 Filers)
us-gaap:CashAndCashEquivalentsDisclosureTextBlock (5 Filers)
us-gaap:DiscontinuedOperationsPolicyTextBlock (5 Filers)
us-gaap:EarningsPerSharePolicyTextBlock (5 Filers)
us-gaap:EquityMethodInvestmentsTextBlock (5 Filers)
us-gaap:FairValueOptionTextBlock (5 Filers)
us-gaap:PropertyPlantAndEquipmentTextBlock (5 Filers)
us-gaap:QuarterlyFinancialInformationTextBlock (5 Filers)
us-gaap:ScheduleOfDividendsPayableTextBlock (5 Filers)
us-gaap:ScheduleOfEarningsPerShareDilutedByCommonClassTextBlock (5 Filers)
us-gaap:ScheduleOfFinancialInstrumentsOwnedAndPledgedAsCollateralTextBlock (5 Filers)
us-gaap:ScheduleOfOtherNonoperatingIncomeByComponentTextBlock (5 Filers)

Seeing the Benefit of XBRL

2009-11-15T16:47:00Z

So how are banks doing these days? Let's take a look at the national banks who have filed XBRL with the SEC. Let's do an easy little comparison to show what you can do with XBRL, and to show one example of the types of issues we are going to have to deal with.

Here is the final result of my comparison in the form of an Excel spreadsheet and as a PDF. I made a few modifications to my Excel analysis tool which I made available and will provide an updated version soon.

What I did was simply grab the cash flow information for operating, investing, and financing activities for the first three quarters of 2009 and 2008. The time to grab that data using my little analysis tool was about 15 minutes. I used SIC code 6021 and grabbed these banks:

Citigroup Inc.
BANK OF AMERICA CORP /DE/
SUNTRUST BANKS INC
PNC FINANCIAL SERVICES GROUP INC
BB&T CORP
US BANCORP \DE\
WELLS FARGO & CO/MN
REGIONS FINANCIAL CORP
J P MORGAN CHASE & CO
KEYCORP /NEW/

I then did some calculations to check the calculations to be sure they added up, everything was great. The analysis shows that cash flows are up for these national commercial banks for the first three quarters of 2009 as compared to 2008. All in less than 15 minutes and it would have taken less than that if my programming skills were better.

As a comparison, I would challenge anyone to do a similar comparison manually or using some other approach to grabbing this data from the old legacy HTML/ASCII filings. How long would that take?

OK, so now for the issue. In the analysis you see "*** No Value Found ***" for Citigroup Inc. What is up with that? Well, Citigroup did not use the concepts that I was looking for, you can see those on the list. You can take a look at Citigroup Inc.'s taxonomy here (line 219). Citigroup reorganized the taxonomy a little. You can see the US GAAP Taxonomy for financial institutions here.

There is nothing wrong with this. This is particularly true, in my view, because Citigroup created a new concept which help you recognize that they change the definition of the net change in cash, you can see the concept they added to their taxonomy here (line 271). No big deal, I can adjust my model and even my tool for grabbing this information for how Citigroup configured this information.

Another thing I want to point out is the linking that I am doing here. See how I provided links to the US GAAP Taxonomy, the Citigroup taxonomy, and so forth. That makes for communicating these issues much easier. These are simple web pages with IDs in them or other useful mechanisms for hooking to a specific location in some information set.

Model SEC XBRL Filing: Citigroup

2009-11-13T20:36:30Z

Want to know how to do an SEC filing? Here is your model: Citigroup. I give Citigroup an A+. And as far as I can tell right now, no other SEC XBRL Filing gets an A+, only Citigroup. Here is why:

Citigroup has zero validation errors reported by XBRL Cloud's EDGAR validation report. See here. (Note that of 403 filings tested, a total of 375 had ZERO XBRL Cloud validation errors reported, 28 had one or more errors reported.)
Citigroup has zero calculation inconsistencies per XBRL Cloud and per UBmatrix XPE. See here for XBRL Cloud and here for UBmatrix XPE. (Note that of 403 filings tested, 313 had zero calculation inconsistencies, 90 had 1 or more calculation inconsistencies.)
Citigroup passed the XBRL Formula testswhich I created for the Cash Flow Statement [Roll Forward] using UBmatrix XPE. See the results here. (Note that of 403 filings tested, 377 filings passed the XBRL formulas validation, 28 did not for one reason or another which is still to be determined.)
Citigroup passed the test information model tests which I created for the [Table] style. See the results here. (Note that of 403 filings tested, sadly only about 16 passed this test, 387 did not. The test looked at the use of [Table]s, [Axis], and [Line Items]. For more information see this blog post.)
Citigroup added 50 concepts and the list of concepts looks reasonable. Here is that list. All the concepts added provide documentation if they are not abstract.

Clearly I have not tested every nook an cranny of the XBRL instance and taxonomy, but I have spent a fair amount of time on this and I also ran the instance and taxonomy through a comprehensive battery of testing. If you think you see something questionable, please let me know. I am doing my best to provide good guidance.

Now, I am looking hard for more A+ filings. Lots of filings get pieces right, but then don't do as well in other areas. More information on this in the coming week, but for now, nice work Citigroup and their filing agent which I believe is Merrill Corporation.

If you want to look at the pieces of the Citigroup filing, see my mashup viewer which pulls a number of the pieces together into one interface. Or, here are the pieces you might want to look at which are not listed above as single web pages if the mashup viewer does not work for you:

Should XBRL GL Move from Tuples to XBRL Dimensions?

2009-11-12T14:46:25Z

Whether or not XBRL GL should move from the use of tuples to XBRL Dimensions has been asked so much that Eric Cohen and Gianluca Garbellotto, two long time contributors to and proponents of XBRL GL, wrote a document XBRL Dimensions and XBRL GL: Why or Why Not (An Apologetic) 1.0 which discusses this issue.

Here is the abstract of that document:

XBRL GL makes extensive use of tuples, and a "dimensional" version of XBRL GL is not in the making. This document explains why, given the type of information that XBRL GL is designed to represent, replacing tuples with dimensions in XBRL GL's architecture would not be a good idea.

Any student of XBRL should understand XBRL GL, its relation to other forms of XBRL, the connection point between the two, and other such issues.

My personal view is that there is no real need for an XBRL Dimensions based representation of XBRL GL. Although, I also would not use XBRL GL for things which many people would, preferring the consistency of always using XBRL Dimensions.

The modeling approach XBRL GL uses is quite useful in many cases and gets in the way in others. The important thing is to understand the pros and cons of each modeling approach BEFORE you commit to one way or another. Each has it's place.

Peek at My Next Version of SEC XBRL Filing Analysis

2009-11-10T18:44:55Z

I am in the final stages of brainstorming and testing my next iteration tool which helps me take a look at the SEC XBRL filings. Here is a shell of that interface with a small subset of the entire filings which I am using for some final testing which I wanted to make available to my blog readers.

There are three "view" into the information listed below. There are three web sites where this information comes from: the SEC, XBRL Cloud, and information I generate. All this information is pre-processed, nothing is regenerated when you visit the page. I generated the information and interfaces using the UBmatrix XPE XBRL processing engine, the Coyote Reporting XRun application which I received as a result of working on the US GAAP Taxonomy creation project, and Microsoft Access which is my preferred programming tool. I use these three tools to process information and then generate the XML and HTML files which contain the information. You can download all these files and use them locally by grabbing this ZIP file. (Again, this contains only a subset of 16 filings. My analysis will be for about 400 filings.)

Here is a breakdown of the different interfaces into this information:

By topic. The first view is by topic. It allows you to focus on one topic. For example, if you wanted to take a look at the calculations validation of an SEC filing, you can use line item number (6) XBRL Calculations Validation Reports on that list. That takes you to a list of all the calculation reports for each filer.
By file. This is item (4) on the above list, but worth pointing out. Basically this is a matrix of every filer and every file available from whatever source. Look down the left side of the report for a filer, the columns for the report, and the intersection "cell" contains the report you might like to take a look at.
By filer. What this does is take a bunch of the relevant files and organizes time into a tabbed interface and lets you look at all the reports for one filer in one interface. You can basically focus on one filer here.

I am learning a lot about using XBRL from digging into these SEC filings. Like is said, there are two ways to learn: from making your own mistakes and from the mistakes of others. Digging into these filings really helps one learn about both the right ways and wrong ways to use XBRL. And this is not just related to creating XBRL. There is also a lot to be learned about building a system such as what the SEC has built, what works well and what does not. There is a lot to learn related to creating XBRL, best practices, and so forth. There is a lot for software vendors to learn from this in terms of features they need to provide or can provide to help filers and others. There is likewise a lot there which helps accountants and auditors who have to check over these filings.

What I think I am going to do is publish a comprehensive analysis of these filings which others in the groups mentioned above can use to learn more about XBRL.