You could say that PricewaterhouseCoopers consultant Walter Hamscher began his work with the XML standards consortium XBRL International more than a few years ago while he was working on his PhD in computer science at MIT.

He was working with artificial intelligence and needed some data to feed the programs, but was frustrated by the lack of quality in formatting of the financial data available to him.

Years later he would help write the first version of XBRL (define), or extensible business reporting language, which is a subset of XML (define), the fundamental building block behind the Web services (define) movement to standardize and enable machines to share and interpret data.

As the organization explains, XBRL uses XML data tags to describe financial information for public and private companies and other organizations. XBRL International and other standards bodies work together to produce specifications and taxonomies that anyone can license for use in applications. XBRL is also available to license royalty-free worldwide from XBRL International.

He recently chatted with internetnews.com about the timetable of the XBRL revolution.

Q: Can you talk about the mission of XBRL International?

It has over 200 members around the world working on XBRL, which is an XML standard that is meant to facilitate the transfer of financial information along the business information supply chain.

The idea is by creating a common framework, a common XML standard, you can accelerate the flow of information to investors and other users.

Q: How would you characterize how business information is currently exchanged in the electronic world?

It's very grounded in a paper-based paradigm. The kinds of rules and regulations that accounting standards bodies put forward are often based on the presumption that the information is coming to the investor on an 8 1/2-inch by 11-inch sheet of paper. Today, the majority of information that investors get actually comes over the Internet.

The real difference here is between finding something that allows you to read a document versus actually being able to get at the data, to be able to make comparisons between one company or another, or to take advantage of financial information in a report that has structure to it, and cross linkages and relationships between pieces of data.

When you're working in a paper-based paradigm, however, you get a piece of paper every six months or every quarter. Consequently, changes from one piece of paper to the next are not that easy to detect. Whereas if you think of this as exchanging a small database every three months, it's much easier to spot trends over time and differences.

Q: Can you talk about the process of coming up with taxonomies, and provide some context on how they work with XBRL?

If you look inside any organization's accounting system, everything is consistent or it wouldn't work. The customer account number is called the customer account number, the employee number is called the employee number, and so on.

No accounting system exists in a vacuum. Many companies have a whole host of different financial reporting they have to do, that isn't always captured entirely within their accounting system. There's always supplemental information, regulatory reports, information for business partners -- so a whole host of different kinds of financial reporting occurs outside of that central accounting system. And the larger it is, the more likely that it has different reporting systems running.

XBRL creates a common language in which a data point like a customer number or employee ID, or amount or currency, are always called the same thing and so an app that needs to consume that (data) will know what to do with that.

In HTML, for contrast, you have designations like 'b' for bold and 'i' for italics. Well, in the financial world, there's a vast variety and a much larger vocabulary than that. With XBRL general ledger standards, for example, there are well over 50 different data items in order to capture what are called journal entries in an accounting system. A journal entry might be, say, a $1,000 credit to an account.

There is a lot of other business information that's often packed into those records, or entries. If you ever used a personal accounting package, there are the memo (data) fields, credits and debits data, and so on. The XBRL general ledger standard is basically a consistent way of naming all those different parts.

In the U.S., we have a GAAP (generally accepted accounting principles) taxonomy, which is what we call a whole collection of concepts encoded in XBRL, with well over 1,000 different data items. It's a very large task, something that's been in development for over two years, but it's nearing completion.

Right now, there's really not a piece of software that can go and extract the revenue recognition policy of one company at a given point, and then go and get the corresponding policy at another point. There is no reliable way to do that.

XBRL makes that possible. The reason that's important is because so much of what goes on in financial reporting isn't really about the numbers, but about the explanation that sits behind the numbers. If I tell you I have receivables of $1 million, you might ask, well, is that $999,999 from one customer? That's a very important question in order to understand the real value of those receivables.

So the development of XBRL is a base language on which these richer taxonomies of terms are then built. There are dozens of these taxonomies under development or already published. In Japan, for example, the (main) stock exchange is now accepting financial information in XBRL format, and they have a taxonomy that represents Japanese accounting standards. At the FDIC (Federal Deposit Insurance Corporation), they're developing a taxonomy for bank reporting, Britain's version of the IRS has one for British tax filings, and so on.

Then we have the largest of the taxonomies, the US GAAP taxonomies and what are called the international accounting standards (IAS), which are basically the accounting standards used by the rest of the world other than the US. It has its own very large taxonomies.

The point is that XBRL is a base language with an emerging large number of taxonomies built in XBRL in order to capture different accounting standards, just like the IT industry has its own, such as RosettaNet.

Q: Can you describe some of the more difficult issues you face with the accounting descriptions?

Take the term for (recognizing) intangible assets, which is a very big issue (in the accounting and financial industry). So you could say, 'look our 'vocabulary', our taxonomy is going to have the term intangible assets, period.' So if you create an XBRL document, you either disclose all the intangible assets as one; (or) the other philosophy is that there are 17 different kinds of intangible assets. List them all. Agree on the names for them all. Make sure they don't overlap too much. Make sure there's accounting reference literature that explains what each one is, and then include all those in your taxonomy.

You want to be able to drive down into detail as much as you can because there's a huge amount of variability in what people report in financial terms. If you force them to do what XBRL allows them to do, which is essentially to invent and publish new terms, then that can damage interoperability.

If it's ubiquitous, that is, if people always have a category of intangibles called patents, then you really ought to create an element called patents; same if you have s. But if you have biological assets, well, it's not clear that it is ubiquitous enough to put into a common vocabulary.

So take that kind of question and multiply it a hundred times over and consider all the interactions between all these terms. It's a complicated job. You really need experts (for the effort), people who live and breathe accounting standards.

Q: Why isn't the Securities and Exchange Commission mandating the use of XBRL?

Well, they have other things on their minds. All government agencies I think wisely follow the market and won't mandate technology standards until they have been widely accepted by the marketplace and will be successful. There's also a lot going on at the SEC, such as (enforcement of) the Sarbanes Oxley Act and reform of accounting rules.

But, speaking as the chairman of XBRL International, I think it's great that the SEC shows interest in XBRL. They're technically astute.

The FDIC, for example, collects quarterly information from all of the banks as part of its monitoring for possible bank failures. It's building a next generation system, which they expect to go live in 2004. It will be based on XBRL and deployed both inside the bank and with (banks') call reports that go to the FDIC and then back out again to the investment community.

There are other agencies close to the FDIC, such as the Federal Reserve Board and the Office of Thrift Supervision and so on that are also looking at XBRL.

In addition, the UK's own version of the IRS is going to be launching a corporate tax filing system later this year and they in fact will be mandating (the use of) XBRL sometime in the future. That's some years away with a period of transition. So the point is there are many agencies around the world at different places along that adoption path.

One of the most important uses of XBRL, we think, is actually as a way of integrating financial information within an enterprise, such as within a bank for credit analysis, or in its own internal reporting and consolidation.

Among (major enterprise) software providers building in support for XBRL in their products include PeopleSoft, Oracle, JD Edwards, Hyperion, which is considered the market leader in financial reporting and adoption of this. We currently have 26 software vendors out of 50 in the consortium that support XBRL in their products. So we'll be seeing the emergence of a variety of XBRL-enabled applications in the coming year.


Oak Grove Establishes BPM Reseller Channel
Is F# a Major or Minor Consideration for Microsoft?