Digital Financial Reporting

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.

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:

• SEC Rendering
• SEC Files
• Citigroup Taxonomy (Presentation relations)

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.

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.

(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.