Day: April 27, 2005

The 11th International XBRL Conference–the happening thing at the Westin in Boston for the past two days–was full of first-rate presentations. But I did have a favorite. It was by Elmer Huh, Executive Director, Global Valuation Services at Morgan Stanley. Huh’s job is to look behind and beyond the numbers that companies present in their income statements and balance sheets to assess their REAL state of financial health. Putting his job in terms of used cars, he is professionally trained to look beyond that fresh coat of paint and new chrome to see the rust, body filler, and worn engine that is underneath. He showed the conference audience how they might use XBRL to do this with spectacular effect on a good number of companies.

To understand the full import of what Huh is saying, it helps to understand something about accounting. It is something that you have probably suspected all along:  Accounting is not about THE TRUTH. (See? You knew that …)

I am not suggesting that anybody is being dishonest. Further, for a great many things that are reported under Generally Accepted Accounting Principles (GAAP), what you see is pretty close to what anyone would judge to be the real state of affairs.

But there are a couple of areas where GAAP is in a state of flux, and
where–for historical reasons–accountants have decided that it is OK for
companies to report numbers that are substantially smaller than the actual liabilities that a company might really have.

One of these areas has to do with reporting on pension liabilities. It wasn’t long ago that companies did not report on these liabilities at all — they simply recognized pension-related expense as they incurred it. But, as future problems in dealing with pensions became more obviously important, it became clear that it was important to reflect SOME of this pension liability on a company’s balance sheet.

But is was also clear that if companies suddenly reflected ALL of this liability, all at once, a great many companies would suddenly go from looking like they were healthy to looking really burdened with liabilities. So, the accounting standard setters decided to create a kind of compromise, where companies must recognize some of this pension liability, but not all of it, all at once. The rules for pension accounting are, frankly, a kludge. They are an attempt to balance a number of concerns by using some arbitrary cut off points and special boundary conditions. The result is that the relationship between pension liability reported on the balance sheet and real liability is slippery, at best.

A second area where the rules of financial reporting can result in some strange distortions is with regard to accounting for operating leases.  If you work the numbers right, you can effectively buy something expensive, like an airplane, but not have it show up on your balance sheet. To which a good CFO says, “Cool.” All the advantages of productive assets and none of the unpleasant downside of having to report increased debt.

Elmer Huh focused in on these two areas of potential distortion in his analysis.  He showed graphs of debt to asset ratios using the reported numbers for companies — and then showed the ratios figuring in operating lease obligations and pension obligations.  The differences were dramatic and had powerful explanatory value when applied to a number of companies that “look” healthy but which are actually having trouble. It was a great, entertaining presentation.

But it was also a good presentation because it said something true and important about XBRL. The reason that Huh could do what he did is that most of the information you need to see the real picture is, by law, disclosed in the notes to the financial statements rather than in the actual balance sheet or income statement. The information that Huh was using was, for the most part, already there in the financial report, but presented in a way that makes it hard to find and use.

In this case, the power of XBRL is in its ability to break free of the standard accounting constraints to recast facts and relationships to see things in new ways. To that, I say “Cool.”

By the way, this same power to free content from presentation, and to rearrange it and present it in new ways, is the flip side of the headache that I described in an earlier posting this evening, about assurance.

One of the interesting things about the XBRL application space is the way that it takes some of the problems that have been around since the birth of SGML and XML and brings them into sharp focus. One of the “foundation” ideas behind XML — and, before that, SGML — is that the tagged file is the reference object–its the part you keep–and the printed output is, well … just output. You can always make another one of those. The idea, as everyone knows, that you save the document in one form, and then publish and deliver in many forms.

Now, suppose that what you are saving–in XBRL–is your firm’s financial statements.  Here is the question: When the auditors show up to offer their opinion as to whether your financials fairly represent the state of your company, which form of financials do they offer their opinion on?  The XBRL?  Or some kind of printed version?

It’s an important question. It is also something of a trick question. If you don’t answer “the XBRL version,” then it is pretty clear that XBRL is not really the version that matters. Oops.  So much for plans to really
submit financial statements in XBRL to the SEC on anything but a test basis … Right? But, if you DO answer “XBRL,” you quickly come face-to-face with the fact that nobody has any clear idea of just how you would do that.

What would auditing an XBRL financial statement mean?  Having accountants read through the actual XBRL?  Probably not, huh? So, they are dealing with something derived from the XBRL? How do they know that this output fairly represents the actual XBRL? How do they know that there isn’t something in the XBRL that isn’t showing up in the rendition that they are reviewing?

And … just what is the “XBRL document?”  The result of  XBRL that you can see does not come from just one thing. The representation that you see on the page draws from many linked files and uses processing capabilities scattered across other linked files. So, an audit couldn’t really look just at a single file — the opinion also depends on all the other stuff that is linked in that makes sense of the particular XBRL instance document.

I’m not arguing that this is not a solvable problem.  But I can say that it is not a SOLVED problem at the moment, and can also say that the solving of it is going to take some time and some serious effort.

In the meantime, what will happen in the real world is that auditors will express an opinion on financials that will be represented in PDF or HTML, and then someone will take those PDF or HTML pages and convert them to XBRL.

That’s fine — the XBRL is WAY more useful than the PDF or HTML — but is also an obviously flawed approach:

• The XBRL is just a translation of the “real” financials.  We are left with the question of whether it is really right and whether there were errors in translation.
• More fundamentally, the XBRL is not the official, normative document. It is, instead, some kind of shadow form of the real thing. That seems like a pretty poor basis for legally binding data interchange.  Someone, someday, needs to be able to provide a professional opinion about the XBRL, itself, as a fair representation that does not contain material misstatement.

Don’t get me wrong … this is not some kind of “fatal flaw” in the XBRL story.  But it is a real problem, and a really good illustration of kind of difficult problem that emerges, 20 years down the road, as we continue to pursue the SGML and XML ideal of separating content from presentation. As we have found again and again, the semantics depend on both content and presentation. Audited financials are just an extremely demanding application that underscores that point.