Author: Bill Zoellick (Page 2 of 5)

XBRL is, in some ways, a funny kind of XML language. It doesn’t make much use
of the capabilities within XML Schema to express relationships such as
order, hierarchy, and so on. Viewed strictly as XML, XBRL looks pretty flat,
without a lot of contextual constraints.

But that’s nonsense, of course. Financial documents are highly constrained
and contain intricate interrelationships. XBRL expresses these relationships
within "taxonomies"–special XBRL constructs that define business
"concepts" and that relate these concepts to each other. The
relationships can, in fact, be really complex …more so than would be possible
within a strict XML Schema definition.

Once consequence of this decision to define the bulk of XBRL semantics
outside the range of standard XML semantics is that XSLT (XML Stylesheet
Language Translator) doesn’t work very well
as a way to transform XBRL documents into something that humans can read. Since
XSLT cannot
"understand" the information in the XBRL taxonomy, XSLT does not have
the information that it needs to present the "facts" in an XBRL instance
in a way that reflects the taxonomy relationships. 

So, how do people produce formatted output from XBRL today? In a Wednesday morning session at the 11th
International XBRL Conference, Raymond Lam of BlastRadius
explained that the usual solution is to hard-wire all
the necessary contextual information into the XSLT rules.  The result is an XSLT
stylesheet that contains nearly as many separate template rules as there are
separate facts to be presented.  Bummer.

Continue reading

When you cut through all the details of banking applications, specialized industry applications, special tools for formula processing, other tools for presentation, international applications, and more … there are really just two fundamental uses of XBRL.

Here is the first use: You start by producing your financial statements the same way that you always do. Once you have your completed financials in hand, you convert them to XBRL and send them out into the world. In this model, XBRL is for the benefit of everyone else. They thank you.

Here is the second use: You identify all of the fundamental transactions in your business according to a taxonomy expressed in XBRL. You use this classification of all the basic financial facts within your organization as a way to aggregate these facts, discover new facts, track activities, and produce reports. What you learn from this use of XBRL is your business. You’ve got yourself to thank.

It is possible to combine the uses, starting with the second use, using XBRL for your own purposes inside your company, and then moving to the first use, creating XBRL reports for the rest of the world. The possibility of combination should not obscure the differences between the two uses.

Not surprisingly, these two different uses of XBRL get separate treatment within the XBRL community. The first use–focused on external users–is supported by a set of “financial reporting” taxonomies,collectively referred to as “XBRL FR.”  The second, internally focused use has a taxonomy of its own, called XBRL GL (for “general ledger”).

If I were betting, my bet would be that the success of XBRL–the breadth of adoption–will depend on which of these taxonomies takes hold in the market.

More specifically, I would bet that broad use of XBRL depends on the eventual success of XBRL GL, or some descendent or variant of it. The reason is that internal use is the only way to get return on investment in XBRL. It could be used to automate internal controls, contributing to better internal decision making, better risk management, and more affordable, sustainable compliance. It could be used to radically reduce the cost of external audits.  It could be used to support management decision tools–dashboards, metrics, benchmarking–to help the organization become more competitive.

By contrast, it is hard to see where the payout is from tagging financial statements in XBRL only at the end of the process, for release to the analysts and regulators.

The people who would bet against me are those who figure that XBRL is going to be imposed from the top down, as a requirement by regulators. I don’t see that happening in the U.S. As the SEC’s Peter Derby said last Tuesday morning at the XBRL conference, XBRL is currently hard to do and U.S. regulators prefer to follow the market’s lead when it comes to technology. It could be a different story in Europe, where, for example, the need to bring 25 different national banking systems together under the direction of a single Committee of European Banking Supervisors really does appear to require something like XBRL:  If it didn’t exist, they would need to invent it.

Assume for the moment that I am right–that internal use of XBRL will be what drives this market forward, and that broad availability of XBRL FR, created automatically from the in-house XBRL GL, will be the consequence, not the cause of market acceptance. Given that assumption, you would be looking for evidence of internal adoption. Is it happening?

From the evidence at last week’s conference, the answer is “NO.”  The only country where there seems to be serious focus on internal use is Japan. Hitachi showcased a case study of an XBRL GL implementation for WACOAL, an apparel manufacturer, and PCA Corporation, which offers a Japanese financial accounting package that was described as being similar in scope and market reach to Quickbooks, has announced support for XBRL GL within their product.

What might broaden this activity?

XBRL GL is currently a technology looking for a good problem to solve. This is not to say, at all, that XBRL GL is not potentially useful. Look at the list–executive dash boards, more effective internal control, reduced cost of compliance–each of these outcomes is very useful. But XBRL GL has yet to demonstrate that it is the critical, secret sauce that makes any one of these good outcomes doable, affordable, or more effective than ever before. XBRL GL needs to move from a technology that could beused for any of these good things to becoming the critical technology that an organization must haveto make some one of these good things available and affordable.

I think this can happen.  It will be driven by an application that needs XBRL GL, and not from XBRL GL needing an application. There are a number of candidate applications. What remains to be seen is whether the companies building and using those applications will find that XBRL GL is the missing piece they have been looking for.

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.

XBRL is a business standard. The immediate users include financial executives, accountants, analysts, and financial regulators, as well as investors of all sizes. All the suits and ties in the audience fit the picture of this user community–this sure does not look like the same crowd that I see at web publishing conferences.

But, scratch the surface, and there is a lot that’s the same. The audience at this conference is mostly people who are building things. They are early adopters and vendors and integrators serving early adopters.

One of the most interesting talks in the first set of the Tuesday morning sessions came from Peter Derby, whose job is to make the SEC more effective and efficient. His title is Managing Executive for Operations and Management, Office the Chairman, US. Securities and Exchange Commission.

The SEC would like to be able to review the substance of a much greater number of financial reports with greater accuracy and greater reliability. Receiving the filings in the form of tagged data has obvious appeal.  So, last year the SEC put out a request for comment on a proposal to invite companies to make voluntary submissions of data in XBRL format. The voluntary program went live in March of this year.

And so far the SEC has received (drum roll …) THREE voluntary filings.

Gosh. That many!

To be fair, companies have been covered up with meeting Sarbanes-Oxley 404 requirements, which are sure not voluntary.  That could be one reason for the slow response rate to date. But Derby thinks there could be other reasons–and other problems for the XBRL community to solve …

• Not enough off-the-shelf tools:Derby’s view is that, at the moment, XBRL is just too hard. There are not enough tools for preparers to use, and there are not enough analytical and presentation tools for information users. There are too many people still looking at tags.
• Not enough internal use:One artifact of the way that XBRL has been driven by regulators is that much of the early activity has been focused at the end of the process: after a company produces its financial statements the old way, THEN they are broken into pieces and marked up in XBRL. Derby notes that these leaves out most of the potential financial benefit of the process. He suggests that the XBRL community needs to start making the case for use earlier in the process, when the XBRL might serve internal processes.
• Too much focus on boiling the ocean:  Derby said that he recognizes, of course, that XBRL is an international standard, and so needs to address a host of difficult problems as you move across accounting standards and practices. But, in his view some of this time would be better spent by focusing on pragmatic issues such as making XBRL easier for humans to read, and on change management.

In my view, Derby’s first two points are on the money. I am less in agreement with the last one. Particularly with a lot of the XBRL activity happening within the European Union, I think that getting the internationalization right is critical.  And … human readability? I thought we were going to focus on tools.

In speaking privately with Derby after his presentation, I asked him about the purpose of the voluntary program. His answer was that the SEC simply needs to find out what they could do with XBRL submissions. Further, he feels that this initiative must be largely market-driven, not regulator driven. His hope is that, perhaps over a period of three years, the SEC will begin to see enough volume in submissions to permit some real economies and new approaches to using and analyzing the financial filings.

Derby’s presentation was followed by Otmar Winzig, Vice president of investor relations for Software AG and Member of the Board of DIRK (German Investor Relations Association). After hearing about Derby’s three voluntary submissions, Winzig was suddenly feeling much better about his pilot program of 8 companies, scheduled to expand this year to 25.

Winzig made an interesting argument for small and mid-cap companies to get behind XBRL–disintermediation.  As the investor relations head at a mid-cap company, he recognizes that one of his big problems is getting analyst coverage.  He argues that 90% of the 10,000 companies traded on European stock exchanges are virtually unknown to investors. As a result, these companies are almost completely dependent on sell-side analysts to get the word out about the company’s performance–even when results are outstanding.

Winzig sees a possibility that broad adoption of XBRL, coupled with tools that allow investors to make direct use of XBRL, would allow small and mid-cap companies to take their good stories directly to investors, and, in the process, to become more independent of analysts who are also interest driven market participants.

All of this should be pretty familiar to readers who have watched SGML or XML market development — or, for that matter, almost any new market. The market needs more applications to grow, and the market is not big enough to attract substantial investment and application development. Put another way, it is precisely the kind of market where entering early with a relatively modest investment can produce a nice return.

I am writing at the end of day 1 of the 11th International XBRL conference in Boston. Over the course of the day I have seen a lot and learned a lot–which I will share with you in a moment.

But I wanted to start with this end of the day perspective: this is a really exciting area of activity. If I were starting a small XML company today, this market would be at the top of my list. It is an EARLY market–no question about it. It is the kind of conference where the vendors still feel obliged to show you the actual markup — early, early. But there is energy and opportunity here that is missing in many of the more mature areas that we cover for the Gilbane Report. This is an exciting place with a lot of problems yet to solve.

At the moment, the activity is being driven primarily by regulatory requirements–most importantly, European regulatory requirements. (Think in terms of all the members of the EU now wanting to find ways to transparently share information across what once were many different accounting standards and sets of national regulations.) The good thing about regulatory requirements is that they can open opportunities for small, innovative firms. I am seeing that happening here.

Apart from the regulatory requirements, consider that, as of today, financial analysts begin the job of understanding a company’s financial statements by cutting and pasting data either from an HTML version of the financial statements–or a PDF one–into spreadsheets.  That’s nuts. It can’t last.  There has to be a better way. XBRL is that better way. At the end of the day, there are many users other than regulators who want this stuff.

There are plenty of problems here too. As I dig into my notes from today’s sessions in more detail–in subsequent Blog entries–I will share some of what I see. But I didn’t want to dive into the critical viewpoint stuff without first saying that this is one hot area.  I am looking forward to day 2.