Blog: Financial Reporting Using XBRL

A Thought Experiment: Understanding XBRL Instances

2009-11-04T19:42:59Z

(Albert Einstein was famous for the thought experiments he used to explain complex situations using simple stories. The purpose of this thought experiment is to help you better understand how XBRL instances actually work. The first thing the experiment shows you is the important pieces impacting the usability of XBRL instances. The second important aspect the thought experiment shows is that the way business users implement XBRL determines the results received from that XBRL-based information.)

In chapter 18 of my book XBRL for Dummies (which is now shipping!) I use a thought experiment to help you see what it takes to make XBRL achieve what many business users tend to want from XBRL which is to reuse the information within some automated process. Now, if you don't care about information reuse, then you may not care about these sorts of things. But if you do, what does it really take to achieve reuse of information?

Let's look at financial reporting as an example.

Again, the ultimate goal you're trying to achieve with XBRL is to automate some process. You many times reap significant benefits from realizing this goal. I am NOT saying that all business processes are automatable or that all processes should be automated. What processes to automate and where to include humans is up to those creating business processes.

But, errors, inconsistencies, ambiguities, and other such factors sometimes keep processes that can and should be automated from being automated, requiring human intervention to execute the process. This is not because you want to involve humans; it's because you haveto involve humans due to errors, inconsistencies, ambiguities, and other factors. The humans need to resolve the errors, inconsistencies, ambiguities, and other factors which prevent the automation of the process. Again, this is should you choose to automate some process.

Think of the Web. Imagine that every company in the world created quarterly and annual financial information and put that information in an XBRL instance on its Web site. Forget about whether you could get every company to make this information available or even if they should make it available. (It's a thought experiment, so just play along.) Imagine that you wanted to analyze all that information for some purpose.

Here are the challenges you would face:

Finding the XBRL instances: You need to find those XBRL instances. How do you do that? You have two possibilities: push and pull. Push means that in some way, perhaps via an RSS feed that pushes this information to you, you're made aware of each of the XBRL instances. Pull, for example, is when you discover the XBRL instances via a search engine and then pull the information to where you can use it. But somehow you need to discover the complete set of XBRL instances you need for your analysis. For our experiment, say that a search engine finds all the right XBRL instances, and only the right XBRL instances, and makes them available to you. So, you have all the information.
Having comparable concepts and relations: You have all the XBRL instances, delivered somehow by your search engine. If each XBRL instance uses a different XBRL taxonomy, comparisons between XBRL instances are more challenging. You can still compare information by mapping each company's XBRL taxonomy to an XBRL taxonomy you create as a master comparison taxonomy. You'd have to create this mapping for every XBRL instance in this case. An alternative is that every company agrees to use the same XBRL taxonomy. Say they did that; in fact, say every company used the IFRS XBRL taxonomy for financial reporting. But now say that companies are allowed to extend the base IFRS XBRL taxonomy. Thus, in effect, now each company is using a unique XBRL taxonomy, and you're back to having different concepts and relations again. However, for this experiment, say that extension isn't allowed, so you have perfect comparability.
Putting all the instances together: You have a complete set of XBRL instances, and you have only one XBRL taxonomy with no extensions allowed, so you have perfect comparability at the XBRL taxonomy level. You now put all the XBRL instances together into one massive, combined XBRL instance containing all information for all companies in the world. Easy enough: After all, XBRL's purpose is to achieve this sort of result.
Resolving entity conflicts: You pull all the XBRL information together into one big XBRL instance. Do you have conflicting contexts? Theoretically, no. Each company reports only its information, not the information of others. Each context should be of the reporting company; therefore, each company provides its own entity identifier within its context. Again, say that every company had one and only one unique identifier, and that every company can be effectively uniquely identified and identified only once (meaning no duplication). So, we can have no entity conflicts.
Dealing with period conflicts: What if companies had different fiscal year-ends? We all use the same calendar, right? That is because the world standardized on one calendar for the most part. (It was not always that way, however.) Well, in the real world run into the situation where different companies use different fiscal year-ends, not ending on the same calendar date. A fiscal year is some financial period (say July 1 through June 30); it may not be a calendar year. Further, many retailers use a 52/53 week year end. Let's ignore this. For this thought experiment, say that every company has the exact same fiscal year-end, which is December 31.
Handling unit conflicts: Different countries use different currencies; therefore all this information is reported in all sorts of different units, from U.S. Dollars, to UK Pounds, the Euro, Japanese Yen, or Chinese Renminbi, or something else. But say that you can convert to some standard currency - say, the Euro for this comparison. For the sake of this experiment, assume that this conversion was done in real time and accurately. As such, you have no unit conflicts.
Agreeing on standard metadata: For this thought experiment, say that you've standardized industry sector identifiers (identifying companies as being a bank, an airline, in retail, and so on), geographic areas (used to differentiate operations in Europe, Asia, and so on), standardized entity information for identifying parent companies as opposed to a subsidiary, and any other thing that can cause a comparability issue. Your meta data is perfect. As such, you can identify parent companies and which industry sector a company is in, you can differentiate between budgeted and actual information with XBRL instances, and so on. You use XBRL Dimensions to construct this dimensional information, which is totally standardized across all companies reporting information. (Remember, it's a thought experiment. Einstein pretended he was riding on a light beam, for Pete's sake!) So, all this meta data is standardized enabling comparability.
Coming up with an analysis interface: You have a huge set of information, all in XBRL, for all the companies in the world. All the companies are uniquely identified. All the companies use exactly the same XBRL taxonomy to report their information, and no extensions are allowed. Everyone uses the same fiscal period for reporting their information. All the numeric values use one standard currency. All parent companies are clearly identified, and all actual information is differentiated from any budgeted information. Basically, everything is perfect: You've achieved information comparability nirvana. You have an easy-to-use business-user interface that's even better than the popular Apple iPhone in terms of usability. It's the perfect business-user application! Isn't life grand!!!

So what is your point, you ask?

One point is that reality can be messy. Reality isn't perfect. All the issues pointed out in the list do exist. These issues are real issues which XBRL has to deal with.

Another point is that many things are possible technically but maybe not politically. Technically, you can do everything we mention as we walk through the issues to resolve each issue in some way with XBRL. In fact, that is typically quite easy. The harder part is actually doing it - for example, agreeing on a standard format like XBRL, standardizing how entities are uniquely identified, standardizing on industry sectors and geographic areas, and so on.

Some agreements are already being reached in the area of financial reporting. XBRL itself is a step in that direction. IFRS is another step. But financial reporting is only one business domain. There are many, many other business domains. Some are easier to create comparability within than others. Some desire comparability, others do not. The desire for compatibly is the responsibility of the domain. Technically, XBRL can deliver comparability, should some business domain desire it and work to create it.

This experiment points out the major moving parts of working with XBRL instances. I use financial reporting only as an example in our thought experiment. Each different business domain will decide how to employ the technology of XBRL within their unique domain.

Different Ways to View Taxonomy Network Information

2009-11-02T16:28:05Z

I have been doing some experimenting with different approaches to looking at XBRL taxonomies. This experimentation is more about ways to view the information in networks (i.e. presentation, calculation, definition). I am looking for a business user view of this information, more semantic related than XBRL syntax.

Here is some of what I have come up with. I am experimenting using two sample XBRL taxonomies and the related XBRL instances I have been maintaining for years, the combined XBRLS meta patterns and the comprehensive example.

The first view is really more for dynamic use of XBRL taxonomy information. Say you are wanting to write an Excel macro to do something with a XBRL taxonomy. Dealing with XBRL taxonomies at the XBRL level can be complicated, particularly when extension is involved. An XBRL processor knows how to do this, but XBRL processors are generally too complicated for business people who know how to write Excel macros to use. But, if you put the information into a simpler form, this can be much easier.

Here are easy to use XML views of the presentation and calculation networks of these two examples. It is not much to look at if you don't know how to program, but if you do, these are easy to use views of the networks of an XBRL taxonomy. These were created using XBRL Cloud which provides a way to generate these XML files from any XBRL taxonomy.

Again, not much if you don't know how to program, but if you DO know how to program a little, try reading these XML files into Excel.

More along the lines of what the majority of business users might want are renderings of the information in an XBRL taxonomy. I have created two views: static and dynamic. Each has their pros and cons:

So, I want to make some points about these different views of XBRL taxonomies.

You are not locked into one view. As an XBRL taxonomy is readable by computer programs and because it is a standard format, you can get literally any number of different views. Proprietary formats are generally the cause of the "locked into one view."
Why do you need three views (i.e. presentation, calculation, and definition)? Well, you may not. What if you could have one hybrid view which provided all the information about the taxonomy that you desired? That is what I am shooting for. Again, the XBRL taxonomy standard syntax is not the only way to look at XBRL taxonomies. In fact, they are more complicated than most business users can handle.
Look at the coloring in the static views. Notice the patterns of the colors. Text tends to be blue, numbers tend to be green and the hypercube, axis, domain, and member information tends to be shades of brown. The idea is to use color to help you understand the information. Others use icons, there are probably other approaches people will come up with. The idea is to make this easier in some manner, using patterns within the XBRL taxonomy.
You may miss this so I will explicitly point it out. Click hereand see where you end up in the taxonomy rendering. Notice how you navigate to a specific row in the static rendering. This idea came from the CoreFiling taxonomy viewer. In that application you can provide a URL and open the application and navigate to a specific spot in the taxonomy within a specific type of network. You can do that with the static and dynamic renderings by providing the ID of the line item. See the URL you clicked on, you can figure out how to do it.
What if the taxonomy did not look like XBRL taxonomies tend to look these days (i.e. trees of some sort), but rather what if they looked like an actual report. For example, take a look at this Excel spreadsheet. Or another example of this is the prototype interactive information viewer I created.
What if you could extend the XBRL taxonomy by simply adding a row or column into the interface and you are limited to specific points in the taxonomy where extensions are allowed (i.e. see this blog post relating to extension points)

The views of the taxonomy above are just interim steps in the process of getting to where I really think we need to be. People tend to look at XBRL far to much from the perspective of the XBRL syntax. Think about the semantics. That is what you really want to understand.

If you want to understand more about this, read the archive of blog posts. In particular, look at the category "modeling business information using XBRL".

XBRL Calculations in SEC XBRL Filings

2009-10-30T18:33:26Z

Continuing on with my analysis of the first set of 408 SEC XBRL filings, here I will summarize what I saw when I looked at XBRL calculations relating to those filings. This web pagepoints provides a summary of these results and a viewer which lets you look at the results of checking these XBRL instances against the calculation relations provided by the filer.

Of the 408 filings, every one provided a set of calculation relations.
Of the 408 filings, 302 had no calculation inconsistencies. (Actually, in the validator I was using 285 had no inconsistencies and 18 had a reported inconsistency relating to an inferred precision issue being addressed by the XBRL specifications working group. This was deemed not to be a calculation inconsistency.)
That left 106 with calculation inconsistencies reported. Of those: 12 filers had only one inconsistency; 38 filers had two inconsistencies (usually the same issue in two periods); 8 filers had 3 inconsistencies; 18 filers had 4 inconsistencies, and 49 filers had more than 5 inconsistencies.
The maximum number of inconsistencies was 34.

You can get a PDF or an Excel spreadsheet with this information from that summary page.

On the report the generator software used for creating the filing is provided, this comes from XBRL Cloud (as does the list of filings).

So, an obvious question was WHY the inconsistencies existed and where the inconsistencies were within the XBRL instance.

As to where, this is the breakdown:

Various: This means that the inconsistencies related to a number of different areas. There were 29 of these which inconsistencies impacted multiple areas. Here is an example.
Stray calculations: There were 2 of these. What this means is that calculations were being fired because of concepts provided by the XBRL instance. The network did not have a full set of concepts. This needs more analysis to see exactly why this is occurring, usually this relates to problems in constructing the XBRL taxonomy. Here is an example.
Income statement: There were 9 relating to the income statement.
Balance sheet: There were 22 relating to the balance sheet. This is a little surprising, the balance sheet is generally pretty easy because all the concepts have a balance attribute (i.e. debit or credit).
Cash flow statement: There were 28 which had cash flow statement inconsistencies. Generally, these look like polarity issues. This is where the filer entered a positive number but should have entered a negative number (or the other way around). This is usually because the preparer is obsessed with presentation of the number and does not seem to understand that for comparability reasons one way needed to be agreed on.
Changes in equity: There were 2 of these. Frankly I would have expected more.
EPS: There were 12 relating to EPS (earnings per share for you non-accountants) not footing. Now this is interesting. Seems like this should definitely foot. Not sure what the deal is. But, it this is NOT supposed to foot, then why are the calculation relations provided?

It has been my observation over the years, and I see nothing which changes this in the calculation validation results that I see, that if a filer cannot get to the point where they cannot get rid of all the calculation inconsistencies it is typically because the filer refuses to grasp how XBRL works. Basically, if the XBRL taxonomy says things should add up, then they should add up. If things are not supposed to add up, then don't put the calculation relations in the taxonomy. That is pretty straight forward. Presentation of the numbers in a rendering for humans is a totally separate issue and has absolutely nothing to do with calculations.

In general what I see is pretty encouraging. For 302 filers to get this right in the first filing period with the SEC not even checking these calculation relations is pretty favorable. Add the 76 who had less than 5 inconstencies which were very similar issues, that brings the total to 378, which is 92 percent of the total.

Here is a PDF which walks you through a few calculations inconsistencies and shows you how to compare the calculation report with the SEC rendering.

If you look at the consistency by generator you see that every generator application both has filings with inconsistencies and without inconsistencies.

In order for automated reuse of the XBRL information provided by the SEC EDGAR system, clearly the data cannot have calculation errors of any sort. XBRL calculations are not sufficient to prove that all computations in an XBRL instance work correctly, see the discussion of business rules in other posts on my blog such as this one.

I am pretty confident that accountants who create XBRL filings will eventually realize that they have a gold mine here in XBRL, rather than just yet another SEC rule that they need to comply with. Pressing one button to make sure that everything adds up, rather then have to put on those green eye shades! What is not to like about that. Further, using business rules to automate the disclosure checklists used to create a financial statement. These are not liabilities folks, they are assets. Pretty soon software will exist which shows this to be the case. Then it will be much easier for business users to understand why XBRL is so useful for not only external reporting, but more importantly for internal reporting.

Self Study Guide to Learning XBRL

2009-10-29T16:40:59Z

I am getting more and more questions about how to learn XBRL. Most people want some sort of self study option. Here are several steps which will get you well on your way to gaining XBRL expertise.

The probability that XBRL will be part of your future is increasing every day. If you believe that XBRL will be part of your future, you can make the investment of learning about XBRL and gain expertise which not a lot of business people currently posesse and you can use this to set you apart.

If you want to learn about XBRL, I would recommend following these steps:

Read XBRL for Dummies. Chapter 1 is a must, it provides in about 20 pages a comprehensive explanation of XBRL. Chapter 4 provides an XBRL Primer. There is a lot there for both business readers and technical readers.
If you want more detail, read Financial Reporting Using XBRL. This book is a little dated, but it provides the next level of deal for understanding XBRL. You can get a printed version (for the price of shipping) or download PDFs.
Get your hands dirty. Chapter 11 of Financial Reporting Using XBRL is called Modeling Financial Reporting Concepts in Taxonomies. If you build each one of these rather simple fragments of XBRL you will really begin to see what XBRL is all about and how to use it. You can see each of these small samples here.
If you need XBRL tools, see this web page. (See the section on XBRL software).
If you want to implement XBRL in production systems, be sure to read about XBRL Simple Application Profile. This helps you understand some realities about working with XBRL. These issues are also summarized in XBRL for Dummies, see Chapter 2 and Chapter 12 in particular.
Follow this blog. This blog is a source for the most current information, ideas, understanding issues, working around problems, etc. It may be a lot of work, but that is what it takes to become expert in anything: hard work. There are no short cuts.

If you want more or options when it comes to learning XBRL, check out Mastering XBRL.

To Add a New Concept or Not Add a New Concept: That is the Question

2009-10-28T14:55:07Z

SEC filings are providing good information relating to a question which has been asked and answered with differing views in the XBRL community for years: If I change a network, do I need to add a new concept?

Continuing on with my analysis of the cash flow statements of 408 filing to the SEC, this is what I see:

Of 408 filers, 358 follow the US GAAP Taxonomy exactly as provided to provide information relating to the change in cash in the cash flow statement. I created an XBRL Formula to test the computation of the change (beginning balance + changes in cash = ending balance) are properly satisfied by the XBRL Formula. Further, the calculations add up correctly (i.e. there are no calculation inconsistencies) for the net changes in cash for operating activities, investing activities, and financing activities. Two examples of these are 3M CO and ABBOTT LABORATORIES.
There were 5 filers (Allstate Corp, Citigroup Inc., The Chubb Corporation, Cablevision Systems Corporation, The Hartford Financial Services Group, Inc.) who added an extension concept to REPLACE the net changes in cash concept provided by the US GAAP Taxonomy. Of these 5: (a) 2 filers changed the concepts involved in the calculation, (b) 3 filers did NOT change the concepts involved in the calculation. (The question being, so why did they feel the need to add the concept in the first place?)
One filer (BIOGEN IDEC INC.) did not change the changes in cash concept, but DID reconfigure the placement of the effect of exchange gains on cash, moving it outside the net increase concept provided by the US GAAP taxonomy.
Of the filings I looked at here, only 1 filer (BIOGEN IDEC INC.) had calculation inconsistencies within the net changes in operating, investing, and financing cash flows. (Why couldn't they get things to add up, but everyone else could?)
One filer (DTE Energy) added a reconciling line item "Cash and Cash Equivalents Reclassified from Assets Held for Sale" and did not add any extension concepts. Seem like that concept is missing from the US GAAP Taxonomy.
One filer (Enterprise Products Partners L.P.) moved the effect of exchange rate changes but did NOT change the changes in cash concept. (i.e. this now adds up differently than what the US GAAP Taxonomy specifies.)

Basically, there is a lot of consistency in that 358 filers seemed to be able to make things work as is. However, there is inconsistency in the way filers where changing the US GAAP Taxonomy via their company specific extensions. Sometimes extension concepts were added but calculations did not change, sometimes calculations were changed and extension concepts were NOT added, sometimes calculations were changed and extension concepts were added in this one specific area of the taxonomy.

This begs the following questions:

When exactly should a new concept be added to an XBRL taxonomy and when should an existing concept be used.
If a calculation is changed, does that mean that a concept should be added because by changing the calculation you could be redefining the concept. For example, for the filer above who moved the impact of the effect of foreign exchange gains from the total net impact of changes in cash flows, has the user redefined "net impact of changes in cash flows"?
Should filers be allowed to redefine all calculations, or only certain categories of calculations? If so, why or why not and how does the desire for analysts to make comparisons across filers come into play here?
In the specific case of the cash flow statement, if the filer uses some other concept than "us-gaap:CashAndCashEquivalentsAtCarryingValue", should the filer use that concept from the balance sheet in the cash flow statement as the concept being reconciled? Some filers don't report that concept, but rather report the concepts "us-gaap:Cash" or "us-gaap:CashCashEquivalentsAndShortTermInvestements" or some other cash related concept.

Peer pressure could get the practices of filers more consistent, but it will probably take definitive guidance from someone on when it is appropriate and when it is not appropriate to add a new concept to a taxonomy. The examples of inconsistencies in the cash flow statements of filers is only an example of the issue, the issue really relates to every area of the US GAAP Taxonomy and this issue is not exclusive to the US GAAP Taxonomy - basically all taxonomies have this issue.

Some concepts in a taxonomy are defined by what they are. For example, "Assets". Other concepts are defined by how they are calculated, such as perhaps "Cash and Cash Equivalents, Period Increase (Decrease)". How are the two distinguished in the US GAAP Taxonomy? Is there a way to distinguish the two?

Here are some more specific examples of situations which might be encountered which points out many points in the spectrum of situations which might arise:

Say a filer adds a new balance sheet line item under current assets which does not fit into any of the other existing high-level balance sheet line items. Should the filer redefine the concept "us-gaap:AssetsCurrent". Probably not. Should filers even be able to add high-level balance sheet line items, or should they be limited to adding lower level line items only?
What if a filer does not agree with the way the income statement is organized and chooses to move things around. Would that impact those subtotals provided in the US GAAP Taxonomy which have specific meaning which is implicitly defined by the nature of the line items which they contain.
The disclosures of a financial statement have many, many different types of summary and detail concepts. How does one know when they are defined by what they are and when they are defined by how they are calculated?

Again, if you are an accountant or an auditor and you want to understand these issues better, send me an email and I can send you the details of the analysis which I created.

Example of Issues Accountants Will have to Deal With

2009-10-26T19:00:10Z

I had this idea for an analysis to perform on the SEC XBRL filings in order to see what they were looking like and to test some things I was fiddling with. The analysis vastly exceeded my expectations in terms of information it provides and it is incredibly useful to seeing the types of issues accountants are going to have to deal with. This blog post summarizes the results of that analysis. I have a detailed document which provides additional insight, if you want a copy of that send me an email and I may be able to get that detail to you.

The analysis looks at 408 SEC filings of 10Q's all filed after July 1, 2009. This is the complete list of filings: http://www.xbrlsite.com/demos/console/console.htm. This list came from XBRL Cloud's list of SEC filings.

I established a hypothesis that if I ran an XBRL Formula through each SEC XBRL instance (10Qs) that the formula (business rule) should either support the fact that cash reconciles or there should be some reason that the formula does not support that and there would be a specific reason as to why. Another way to state this is to say that "beginning balance of cash + changes in cash = ending balance of cash". The US GAAP Taxonomy states this, although implicitly; you can see that here in the US GAAP Taxonomy CI entry point. (What I mean by implicitly is that there is no official business rule which states this and there is only the implicitly way that a [Roll forward] is created which unofficially implies this, it could be explicit though.)

So, I created this business ruleusing XBRL Formulas. One of the first thing I recognized was that filers were using two different US GAAP Taxonomies (2009 and 2008) so I had to create another XBRL Formulafor the second taxonomy. I then used the complete list of SEC filings (mentioned above) and created a little batch file which grabbed the SEC XBRL instance from the list, applied the business rule, and spit out a validation report in XML which I then converted to HTML. I did this using the UBmatrix XBRL Processing Engine. This is a summary of the raw validation results.

The really interesting thing is that of the 408 filings, 358 passed validation first time through! I was truly amazed. That mean that 358 of the 408 filers provided the concepts specified by the US GAAP Taxonomy, that the numbers added up correctly, and that there were two periods reported. This part took very little effort to set up, it is just creating the formula, getting the list of filings to run the formula against and generate the batch file to automate the entire process.

The hard part was figuring out why the other 50 did NOT validate. That was the really interesting part o this analysis, but also rather time consuming.

Before I get to the observations there is something that I want to point out. While I did this analysis for the cash flow statement, the same type of analysis could be performed in other areas of the taxonomy. But if the analysis were to be performed, I speculate that the types of issues you would discover would be quite similar to the issues uncovered by my simple analysis. Keep this in the back of your mind as you read these observations.

High level observations

Here are the observations which I made:

Of 408 filings, the cash flow statement was extremely consistent at this high level. For example, all but 6 filers of the 408 total filings had used the concept "us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease" specified by the US GAAP Taxonomy for net increases or decreases to cash reported on the cash flow statement.
Of the 408 filings, the vast majority of the filers followed the US GAAP Taxonomy which calls for the concept "us-gaap:CashAndCashEquivalentsAtCarryingValue" to be used on the cash flow statement. (358 plus, did not to an actual count)
Filers who did NOT use the concept "us-gaap:CashAndCashEquivalentsAtCarryingValue" generally used another US GAAP concept which generally included one of the following: us-gaap:Cash (5 filers), gaap:CashCashEquivalentsAndFederalFundsSold (1 filer), us-gaap:CashAndDueFromBanks (8 filers), us-gaap:CashCashEquivalentsAndShortTermInvestments (4 filers).
Only 5 filers created extension concepts for the balance of cash. Of those, 4 created extension concepts which were different for the beginning and ending balance. (i.e. one concept for the beginning balance, a different concept for the ending balance). This is a big no-no in my book and the fact that only a hand full did this and that this is NEVER done in the US GAAP Taxonomy itself is pretty good evidence that creating two different concepts for the beginning and ending balance is not the way to go.
The vast majority of filers followed the US GAAP Taxonomy calculation and included the changes in cash related to exchange gains and discontinued operations within the concept "gaap:CashAndCashEquivalentsPeriodIncreaseDecrease"; however, there were a hand full which did not include cash changes from exchange gains or discontinued operations within that concept, rather they were additional reconciling items in calculating the total change. In is hard to believe that calculating this total change in cash should be done in two different ways, but that my just be me.
One filer had an additional reconciling item for VIE related changes to cash (PAPA JOHNS INTERNATIONAL INC). It may be the case that this concept needs to be added to the US GAAP Taxonomy.
Two filers (DTE Energy, PPL Corporation) has "Assets reclassified as held for sale" included in changes to cash. This may need to be added to the US GAAP Taxonomy. I do recall from my work with the IFRS taxonomy that this concept is part of the cash flow statement as these to filers reported.
Two filers (Symantec Corporation, NVIDIA Corporation) had a 52/53 period year end and used the wrong startDate which did not match to the instant reported, therefore the XBRL Formulas did not fire. When the startDate was corrected and the validation was rerun, the validation worked correctly. These are pretty obvious errors.
Of the 408 filings, only 2 filings had "rounding issues" which caused the computations to not add up correctly for this one formula. Personally, I belive that filers should make all these adjustments BEFORE they put their numbers in the XBRL instance because sure, it may be some additional work for the filer, but it will be even more work for all the analysts who make use of this information, trying to deal with these rounding issues. Again, that is my personal view.

It seems that comparability would be extremely easy to achieve for the high level of the cash flow statement. The biggest issue to comparability are (a) the use by a minority of filers of different concepts to represent the balance of "cash" than the US GAAP Taxonomy calls for and (b) where the exchange gains and discontinued operations really should be in the computation of the net change in cash. These are both accounting issues, not technical issues.

Further, looking one level deeper into the cash flow statement, a high percentage of filers (over 95%) report the concepts: us-gaap:NetCashProvidedByUsedInInvestingActivities, us-gaap:NetCashProvidedByUsedInFinancingActivities, us-gaap:NetCashProvidedByUsedInOperatingActivities. I may do some additional work to see more precicely what is going on with these concepts.

Example of Issues Accountants Will Have to Deal With

OK, so now to the example of issues accountants will need to deal with. I have my personal opinion on these, but clearly this is not my call. Someone will need to deal with these issues however. Not doing anything is an option, but I don't really thing it is the best option.

Take the issue of where the exchange gains and losses realating to cash are totalled, there seem to be the following options: (a) Force everyone to use the US GAAP Taxonomy computation, (b) allow for filers to change the computation but clearly document that change, (c) do nothing which is really implying that option "b" is the right choice. What sort of comparability should be provided? Who decides?
If someone does move the computation of "us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease", should they create a new concept or simply change the definition of the existing concept? This debate has existed for years in the XBRL community.
Should prepares be required to report the concept "us-gaap:CashAndCashEquivalentsAtCarryingValue" in their cash flow statement, even though they use some other cash concepts on their balance sheet and don't show that concept at all?
Should the concepts for the changes in assets held for sale and VIE related changes be added to the US GAAP Taxonomy?

Again, those are just a few examples. And remember from the point I made above, while the concepts you might be looking at and the considerations will be different in different areas of the US GAAP Taxonomy, these issues from the cash flow statement are likely quite similar to issues which will be discovered in other areas of SEC XBRL filings. These issues are not just for specific concepts, but more over arching principles which should be applied throughout the entire US GAAP Taxonomy.

Verifying Computations in an XBRL Instance

2009-10-20T19:27:28Z

OK, I have another way to explain what can be validated using XBRL calculations and what you need to use XBRL Formulas to validate.

Take a look at this PDF which has been annotated to show the validation of each computation in the XBRL instance.

For more background on the sample financial statement shown, see this blog post and this summary of all the things which need to be validated when creating an XBRL instance.

Seems like a lot of work! And it is. Good thing that a computer application will do the vast majority of the validation for you. What is the point of all this validation. Well, remember the saying "garbage in, garbage out". That is why. If you want to automate processes, these numbers need to be squeaky clean.

Using and Understanding SEC EDGAR XBRL Filings

2009-10-20T15:04:04Z

This blog post summarizes information relating to using the XBRL information provided by the SEC EDGAR web site. The target audience for this post is a business user who has a little bit of programming skills who wants to understand how to get at the XBRL information on the EDGAR system and to understand issues related to obtaining and using the XBRL information.

There are two approaches to using the EDGAR XBRL information. The first is manual. To me this is generally uninteresting, you can use the old EDGAR system to use the information manually. However, using the EDGAR information manually provides insight into how to use it in an automated manner. The second approach is a more automatedapproach using a computer application. I will use Excel as an application to look at the EDGAR XBRL data.

Manual Approach

The manual approach of getting the XBRL filings to the SEC is to use one of two methods.

Use the SEC Search page: The SEC Search page allows you to put in some information about an organization which must file with the SEC and then you can go to that information. For example, if you go to that search page, and type into the Company Name box "International Business Machines", and then press the Find Companies button, you would get this result. On that page you will see a blue button which says "Interactive Data". If you press that, you get this page which is a rendering of the XBRL created by the SEC. What you MAY not know is that you can browse the files for any filing. For example, if you go to the actual documents (the gray button next to be blue interactive data button), you get this page. That page lists a bunch of documents provided for that filing. Now, if you take the HTML page out of the URL, you will get this listing. This gives you a listing of all the files which are used to drive the SEC interface into the XBRL and other files. For example, take a look at this XML file. That file drives that Interactive Data viewer provided by the SEC. Look at the file names within that XML file and you see the detailed reports in an XML format. Those reports drive the HTML and Excel versions of the company filings provided by the SEC. For example, this is the XML file with infomation about Acquistions for IBM.
List of XBRL Filings: Now, you can use the RSS feed(see below) to get a list of the last 100 filings made to the SEC in XBRL. Regretfully, the SEC does not provide a list of ALL the SEC XBRL Filings. But, a software vendor, XBRL Cloud has provided a list of ALL THE SEC XBRL FILINGS. You can see that list of all XBRL filings to the SEC here. From that list, you can navigate to any of the pages pointed out above in "1" above. What I did myself is create a little short cut to the files that I wanted to deal with. Here is that list, I call it a "Mashup Console". I basically used the XBRL Cloud information to grab filing information, I used some other software I had laying around from Coyote Reporting which we used on the US GAAP Taxonomy creation project, I modified those, and I created some things like this rendering of the presentation linkbase of EVERY SEC FILER who submits XBRL. This is helpful because the SEC provides no way to take a look at the XBRL taxonomies provided for SEC XBRL filers. But you CAN get those from my mashup console. There is more available, but I will get to that under the automated processing portion of this discussion as that is what the other information is for.

Here are some other useful tools created to access XBRL related information from the SEC web site created using the files mentioned above and some automated processing mentioned below:

Automated Approach

To use the EDGAR information with any sort of software application, the first thing you need to do is find the XBRL SEC filings. There are two ways to do this: the SEC can tell you about the XBRL filings or you can go find them yourself. Finding these yourself is generally above the skill level of business users trying to get at the information; this is what programmers are for.

The SEC tells you about the SEC filings by providing an RSS feed. This lists the RSS feeds provided by the SEC at this point in time. The first RSS feed on the list is really the only list of XBRL documents filed but it really is not that useful as it only provides the latest 100 filings. Rumor has it that the SEC will provide a way to get at all the XBRL filings, but at this point that complete list does not exist.

But, a software vendor, XBRL Cloud, has gone through the effort of figuring out how to get all of the SEC filings and has made that listing publicly available. This is an HTML version of all XBRL filingsmade to the SEC. That HTML listing of XBRL filings to the SEC is interesting, but what is more interesting is an XML version of that listing. The reason this is more interesting is that you can write a very simple Excel macro to grab the list of all XBRL filings to the SEC.

So, really, there is only one practical way to perform automated processing of XBRL filings, from a list of such filings. Having to find them yourself would be really hard to do. You CAN do this. The SEC provides a number of interfaces into the information such as this which exists for every SEC filing(XBRL or otherwise). You can see the CIK number (a unique ID for every filer) and the Asseccention Number (a unique ID for every filing). These two numbers can be used to get at every filing for every filer.

Another way to get at all this information is to use FTP. This is a link the the SEC FTP interface to EDGAR filings. Here is information for FTP users provided by the SEC.

To get at the EDGAR information using a simple software application, see this blog entry. The code provided in the application (this is just Excel VBA) can provide a lot of insight as to HOW to get at the SEC data using automated approaches. The limitation of this tool is that it does not use an XBRL processor to access the information. An XBRL processor would make a lot of things much simpler, but you really need to be a programmer to use most XBRL processors these days.

Issues and observations

The following are issues and observations made as part of looking at the existing SEC filings.

These are the SEC's own observations of XBRL filings to the SEC.
Inconsistent vendor validation related issues. XBRL Cloud ran its validation against the SEC XBRL filings and found some interesting issues related to different SEC filings. The columns under the heading "Validation Report" summarize these issues.
Information model issues relating to [Table]s. This shows how SEC filers are extending the [Table]s in the US GAAP Taxonomy inconsistently.
Summary of filing errors. This Excel spreadsheet summarizes the SEC validation error in a number of different ways.
CFO Magazine artile about SEC Filings in XBRL

Business Rules: Their Role In Creating Quality Information

2009-10-19T15:00:23Z

Business rules are critical to creating quality XBRL. They are not sufficient, but they are necessary. And creating quality XBRL is important. Consider the article X Marks the spot, for Errors published by CFO.com which says:

Early results indicate that filing financial statements in XBRL is far from simple.

Well, I see this slightly differently. XBRL actually can be quite simple, if you understand the process (i.e. what the process is) and have good software to help you through that process and supports that process.

Today, most people don't seem to understand that process and software does not support that process in a workflow which is very helpful to business users. I think that this is just part of the normal evolution which XBRL has to go through.

So, what is the process? Well, I have a little work in progress which will eventually be articulated in a blog post. You can see what I have so far at this URL. I will explain this in more of a narrative form later, but fur now if you choose to, you can figure out the entire process. There are plenty of examples.

But the focus here is business rules and the role they play in the validation process. This is number 3 on the list above.

Business rules are expressed in XBRL using XBRL Formula. People have been discussing the need for XBRL Formula since the beginning of XBRL. Over the years there have been proprietary versions of XBRL Formula and even some prototype implementations. But now XBRL Formula is a global standard.

But, XBRL Formula and the business rules you can create with XBRL Formula is not used extensively in many XBRL taxonomies as of yet. For example, the US GAAP Taxonomy does not provide business rules, yet anyway. But, you do need them because whether you realize it or not, you have computations which XBRL calculations cannot handle.

For example, take a look at and consider the Movement in Property, Plant and Equipment [Roll Forward]in the US GAAP Taxonomy. This reconciles the beginning balance, the period increase or decrease to the ending balance of Property, Plant and Equipment. The reason XBRL calculations cannot validate this computation is because XBRL calculations only work if every concept participating in a calculation is in the exact same context. With a roll forward, you have three different contexts as each concept in the computation is in a different period. Thus, you need XBRL Formulas to express this business rule.

I forget the number of [Roll Forward]s which exist in the US GAAP Taxonomy, but it is a substantial number as these types of reconciliations are common in financial reporting. There are other types of computations which XBRL calculations will not handle, the [Roll Forward] is only one example to make the point.

You can see a more specific example of a roll forward (another term for roll forward is movement analysis) here in this set of examples. Look at number 4. Here is a PDF rendering of a simple movement (or roll forward) example in PDF, in the XBRL instance, the XBRL Formula, and the detailed validation output.

The XBRL Formulas looks complex, but because, for example, the US GAAP Taxonomy has a consistent way to express the information model for a [Roll Forward], a software developer can actually automate the process of creating a formula for every [Roll Forward] in the US GAAP Taxonomy.

There really is no reason to have to verify computations like these manually, computers are much more accurate than humans. XBRL US will likely provide XBRL Formulas for every [Roll Forward]. Until they do, you still need to verify your computations. You really don't want to show up with this type of error in something like XBRL Cloud's list SEC filer errors now would you.

Further, people have been talking about using business rules to automate as much of a financial statement disclosure checklist as possible for years. Thing like "If you have the line item 'Property, Plant, and Equipment, Net' on your balance sheet, then you must have...." You get the idea. These types of "if-then" statements are quite easy for an automated process to check. You will never be able to automate the detection of every possible error, but you can leverage XBRL to both improve the quality of what you do today, and you certainly can reduce the cost of getting to that quality level.

Business rules will even become more powerful as taxonomies become more like ontologies. But that story is for another blog post. Stay tuned for details!

Business Rules: What are they?

2009-10-18T15:16:17Z

My blog has a page which is dedicated to business rules. What this post and the next several posts does is help business users understand what business rules are and why they are important. I am in the process of updating the XBRL Formulas information from the candidate recommendation (CR4) to the actual released version of XBRL Formulas. This will be done over the next several weeks.

The ability to express business rules is probably the single most powerful feature of XBRL (other than the fundamental ability to express business information in a standard structured format).

The term "business rules" can be defined in many ways. A good resource for understanding exactly what business rules are is the Business Rules Group. You can see this URL for more information.

There really is no standard definition for what a business rule is. Here are some definitions which others use to help you get a sense for what business rules are:

A formal statement that defines or constrains some aspect of a business that is intended to assert business structure, or to control or otherwise influence the behavior of the business
A way of expressing the business meaning (semantics) of a set of information
A formal and implementable expression of some business user requirement
The practices, processes, and policies by which an organization conducts its business

Business rules exist in the form of relationships between pieces of business information. Some examples can help you better understand exactly what they are:

Assertions: For example asserting that the balance sheet balances or Assets = Liabilities + Equity.
Computations: For example, calculating things, such as Total Property, Plant and Equipment = Land + Buildings + Fixtures + IT Equipment + Other Property, Plant, and Equipment.
Process-oriented rules: For example, the disclosure checklist commonly used to create a financial statement which might have a rule, "If Property, Plant, and Equipment exists, then a Property, Plant and Equipment policies and disclosures must exist."
Regulations: Another type of rule is a regulation which must be complied with, such as "The following is the set of ten things that must be reported if you have Property, Plant and Equipment on your balance sheet: deprecation method by class, useful life by class, amount under capital leases by class . . ." and so on. Many people refer to these as reportability rules.
Instructions or documentation: Rules can document relations or provide instructions, such as "Cash flow types must be either operating, financing, or investing."

Today, it is quite common that business rules are application specific. But what if business rules were not locked into a specific software application? What if these rules could be exchanged along with the information. That is the power of business rules. What the exchange of business rules allows is the efficient and effective automation of information exchange across business systems.

If you have ever received an Excel spreadsheet from someone and had to rely on the information in that spreadsheet for something important but you really were not sure about all those cell formulas in the spreadsheet you will understand what I mean. Imagine if you could have insight into all those formulas in your terms, rather than rely on formulas provided by the spreadsheet creator.

More to come...