Bob Schneider is a Partner in 
Wilson So is the Director of Hitachi America, Ltd. 
Steve Adelman has been working at the intersection of financial services and technology for more than two decades. As the Managing Director of An Interview with Walter Hamscher
As many readers know, Walter Hamscher is an XBRL pioneer and one of the smartest people in the field. He is a co-author of the XBRL specification and several other XBRL International publications, a member of the XBRL International Board of Directors, Past Chair of XBRL International, and consultant to XBRL US contributing to the XBRL US GAAP Taxonomies. Walter is President and CEO of Standard Advantage, a consultancy that helps organizations to achieve the cost savings and increased flexibility available to them through strategic commitments to technology standards. He holds a PhD in Computer Science and Electrical Engineering from MIT.
In this wide-ranging interview, Walter offers both specific detail and broad perspective on key XBRL topics, including the SEC’s proposed mandate, the pace of XBRL adoption in the US and abroad, assurance issues, and Inline XBRL. Below is the first part of the interview; we’ll publish four more installments over the next four weeks.
(1) You once said that XBRL will allow financial data and those using it to assume “a content management view of the world.” Could you expand on what that means and how XBRL accomplishes that?
What it means is that, when you look at documents and documents being passed around and posted on sites and so on, you’re really viewing them in terms of their component parts and their linkages to each other. Notably, one particular part of what’s considered “a document” may actually change its content continuously. Different parts of the document may have different timeliness.
The canonical example is a website. You go to CNN.com or something like that and you see that in some sense the page never changes. But in another sense, the pieces, the headlines, the images and so on are constantly being updated within that framework. What makes that happen behind the scenes is a lot of either simple or complex workflow in which the pieces of the documents are essentially passed from hand to hand, from person to person, going through review cycles, and being checked for consistency with others, and tested, and so on.
When you look at accounting, it is striking that most accountants don’t really think about data as data in a database. It is actually much more about the report and the treatment of the accounting. Using the right accounting treatment is almost like a lawyer putting forward the argument for why a certain event should be looked at in a certain way.
So consequently, the way I look at XBRL documents is that they are much more oriented toward the integration of free-flowing text with numerical data that could stand on its own (“stand on its own” in the sense that you don’t have to have the original layout of the table in order to understand the data in it). That allows you to take a more content management view in which a single document, say, can really be a combination of three or four other documents all put together.
In other words, it is another perspective on reporting that says, yeah, the “reports” really are reports. They have some narrative, they have some explanation, they have some structure, and the data gets filled into the framework of that report. It is not just a data dump.
(2) It’s been about two years since you gave your fascinating XBRL GL webcast titled XBRL and SOA, in which you discussed how “XBRL taxonomies embedded within a Service-Oriented Architecture (SOA) are effective across a wide range of compliance processes both within the enterprise and within the related supply chain.” Have you seen any evidence that companies are beginning to recognize the usefulness of XBRL for meeting the enormous compliance challenges they now face?
I have, although not so much in the U.S. oddly enough. Let me explain why I think that’s true; this is obviously a personal viewpoint.
One of the things I have learned recently is that it seems to be very difficult for users –- i.e., almost anyone who is not a software engineer or computer scientist by trade, even some CIOs — to think about anything other than either an application or a database. But what’s key is actually the notion of data structure, of reference data that structures other data, and the formats it appears in as it moves from file into application, across a network, back into a file, and so on. How data is structured, as distinct from a particular structure such as a set of relational tables, is somewhat of an abstract concept, really, if you’re not a software engineer.
Yet XBRL is that third category. It’s not an application, it’s not a database; it’s conventions and a vocabulary for organizing data for a variety of applications. I think it’s hard for people to visualize, unless they are actually seeing something happen on the screen in an application. It’s also hard to visualize or appreciate what the possibilities are.
So what I see some companies doing in other markets like France and Italy, where the regulators have adopted XBRL for bank reporting, is that the software vendors there have begun to integrate XBRL as an input format into their consolidation packages. I would not say that any of them put XBRL front and center, but it’s no longer just an output format.
I think it’s just a question of timing; they are two or three years ahead of us here in the United States. I am not that familiar with the situation in Japan, but I do know there are companies there, the vendors themselves, who have started to use XBRL internally. Although, of course there are many other factors involved in any specific XBRL implementation that complicate that story a lot.
(3) Let me continue with that international perspective. Some observers have said that the pace of XBRL adoption in the US lags that of overseas, while other say comparing implementation and regulatory climates as different as those in the US and China is comparing apples with oranges. What is your opinion? How do you see the pace of adoption in the US vis-à-vis that overseas? Is there anything the US can learn from adoption in another countries?
Looking back on the beginning of XBRL in 1999 or so, I can look at my younger self and realize that I had a very US-centric view of all this. One of the things I didn’t appreciate was that some other countries have a much stronger culture of values like thrift and efficiency than the U.S. does. Consequently, it is a lot easier for some countries — the Netherlands has a thrifty culture, as does Japan — to look at something like XBRL and figure out pretty quickly that, yeah, this is good for everyone; it will be more efficient and therefore we will all benefit, so let’s do it.
Now, I am not saying it is trouble-free and that everybody in these countries has jumped on the bandwagon right away. But by contrast in the United States, so many other things pile on to our considerations around business and government decisions, things that really have nothing to do with thrift or efficiency. They have to do with history, and they have to do with fear of litigation that doesn’t exist so much in other countries.
In all my conversations in China, Hong Kong, and Taiwan, it was very clear that they had no concern at all about legal issues or anything like that. It was just a matter of: “Is this a better way of doing it? Can we take advantage of the fact that the standard has been developed?… Yes, let’s do it.” The words “safe harbor provision” never came up in the conversation. It was just something that they understood instinctively was a more efficient way.
There is such a strong cultural difference that I can easily see why someone would say apples and oranges. But it is really not apples and oranges; it is really the difference between engineers and lawyers, and that’s an attitude difference.