Senior Fellow Peter J. Wallison

It's such a familiar process by now that we are no longer surprised when a new technology completely transforms the way we live and work. When digital data processing was first developed for computers, no one could have predicted that the same technology would eventually give rise to fax transmissions, the Internet, e-mail, cell phones, and the many other products and services that are now an everyday part of our lives. When each of these products appeared, it started slowly but grew exponentially until it became an inevitable wave. This is often true of products or services that depend on networks for their power. The unique characteristic of a network is that its acceptance gains momentum as more people join it. Every new member makes the network more attractive to others. Fax machines and e-mail are classic examples; as more people used them, they became more valuable as a method of communication.

Extensible Business Reporting Language (XBRL) is a network product in this sense. As more people or organizations use it, the more will be attracted to it. For government agencies, it offers such extraordinary potential that must soon become universal. My purpose today is to explain why it is such a powerful tool, why I believe it addresses one of government's most serious current problems, and why it will soon transform the way government works.

To give you a sense of its significance, I'd like you to think about China in the 1980s, a country with 1.5 billion people and a telephone system that connected only a small fraction of the population. To permit voice communication among any substantial part of its population, China would have been required to install a hugely expensive infrastructure of poles and wires, and retrofit perhaps a billion homes and businesses. But suddenly the cellular telephone appears, allowing the country to leapfrog over 100 years of infrastructure development. There are now over 300 million cell phones in use in China. Imagine the investment in infrastructure and the time it would have taken to connect 300 million people with one another through copper wires.

Now think of all the legacy information systems that government agencies have already installed. Imagine how difficult it will be to get those separate systems to communicate with one another--so that, for example, the Treasury Department would be able to get economic data from the Federal Reserve in real time, or the FBI share information with Customs. For each of these systems to be integrated with any other system, special software would have to be created, at vast expense in money and time, to translate the different terms and protocols in each system so that they could be interpreted and used by the other. The whole process of integration, then, is thus roughly equivalent to installing the hardwired infrastructure of a telephone system.

But XBRL is to communication between government agencies what cell phones have been for China. It creates the possibility of communication that previously would only have been practical through a vast investment in money and time to develop and install integration software.

How is it, then, that XBRL can do this? Again, let me use an analogy. Let's suppose I am writing an article in English, but I am writing it for an audience that only reads French. After I complete the article, I am going to use my translation software to translate the article into French. My article is about bank regulation in the United States, and of course I use the word "bank" frequently. Now, the English word "bank" has several meanings. It is both a noun and a verb. As a noun, it can refer to the side of a river as well as a depositary institution; as a verb it can refer what an airplane does as it begins to turn in flight. How will the translation program know that I am not writing about the side of a river when I use the term "bank," so that the word is translated as "banque" rather than "berge"--the  French word for the side of a river? If the program is sophisticated enough, it will use context, and know that when I use the term bank regulation I am not referring to controlling the side of a river.

So it is context that is the key to accurate translation. It is relatively easy to translate a word from one language to another if we have a dictionary of all the meanings the word can assume in the language in which it was written, and then a way of denoting the context in which the word was used. That's what XBRL does. It supplies a universally understood context-based tag for every term or concept used in a system of data, and thus allows each word or term to be translated accurately into a word or term used in different data system.

As an example, let's go back to the Treasury Department seeking information from the Federal Reserve. The examples I will use are of course hypothetical, only for the purpose of illustration. Treasury wants to know how much lending was done by U.S. banks operating overseas in 2006. A Treasury computer sends that question to the Fed. The key words in the Treasury inquiry are "bank" and "operating overseas." The Fed's computer system can handle "bank" but it does not understand the term "operating overseas." The data on this question is kept at the Fed in the category "Non-U.S. lending." Under these circumstances, the two systems cannot communicate and the Treasury's simple question must be handled manually.

How would XBRL address this problem? Remember that I said that XBRL puts a context tag on every term. It is like the part of the French-English dictionary that says that in some contexts the word "bank" means "banque" and in other contexts it means "berge." It is also like the dictionary in the sense that it contains all the various ways that the same word, term or phrase can be translated or used. So the Fed can continue to keep its records for banks using the term "Non-U.S. lending," and the Treasury can continue to use the term "overseas operations" in its database. However, each term, whenever used by Treasury will be translated by XBRL into a digital equivalent that includes them all. Thus, the Treasury's question to the Fed goes in as "operating overseas" but comes out at the Fed as "Non-U.S. lending." These are not real words, of course, but the digital equivalents of those words or terms are readable by the servers in each organization.

So XBRL can be thought of as a kind of transparent universal digital dictionary. In theory, if representatives of all the written languages sat down and defined the meanings of all their words in context, XBRL would allow the translation of my article on banks into all those languages. But of course, in considering XBRL's capabilities for government, we are talking about something much simpler--a dictionary that would allow all the computer systems of all U.S. government agencies to talk to one another. Each agency could continue to keep its records as it always has; no changes would be needed there. But communication would be facilitated through a universal digital dictionary that translates the words or concepts from one computer system into the language used in another. It breaks down barriers that previously looked insurmountable--just like the cost of wiring China looked like an insurmountable barrier to communication until the cell phone came along--making it possible to overcome these obstacles at a fraction of the cost in money and time.

That's why the title of this conference is "XBRL: Making Information Portable, for Use Anywhere, by Anyone, between Any Systems."

Now, if all this sounds too good to be true, it actually isn't. You are all experts in the information systems of your respective agencies, so you are probably thinking that it can't be that simple. You know for example that in your agency the word bank has 49 different meanings. There are U.S. banks, Italian banks, Latin American banks, foreign banks in general, trade banks, custodial banks, trustee banks and foreign exchange banks. Your agency then breaks down these categories into still more subcategories, and on and on.

But this is not a serious problem for XBRL. The X stands for "eXtensible," which means that the digital tag that gives context and further meaning to the main word can be as long as you want. It's very much like the digits after the decimal point in Pi. In school we were taught that Pi is 3.1416, but as you know that's only a convention for high school mathematics, not the end of the matter. The numbers to the right of the decimal point in Pi can go on to infinity, as far as anyone knows, and each time a new digit is added the pi number gets more precise and the measurement of the circle gets more accurate when that number is multiplied by the diameter.
Of course, no one outside your agency may be interested in the fact that you have refined the term "bank" to include "foreign exchange banks operating in Vietnam between November 1945 and September 1951, with assets of more than 7 million francs." That detailed description would have a long tag, and each step along the way would make it more precise, but nevertheless it would still come under the most general category called "banks" and the second most general, called "foreign" and the third called "Vietnamese," etc.--all identified by a string of digital tags which make the description more precise with each step in the same way that adding numbers after 1416 make Pi more precise.

But XBRL, if you'll excuse the pun, is not pie in the sky. It is already in use in one way or another all over the world, through 550 organizations in 27 countries. XBRL-U.S., the U.S. affiliate, operates under the general umbrella of XBRL International. Active programs exist in the private and government sectors in Belgium, Demark, Germany, China, Japan, Netherlands, France, Korea, Spain and the United Kingdom, to name a few of the countries outside the U.S. where XBRL is in use for financial reporting to shareholders, for other reporting to government supervisors, or for communication among government agencies.

In fact, the United States is not the world leader. Other countries in the EU have completed the taxonomy--i.e., the dictionary--necessary for reporting financial information under International Financial Reporting Standards, or IFRS. In 2006, in order to stimulate the completion of XBRL for reporting by U.S. companies that use Generally Accepted Accounting Principles (GAAP) for financial reporting, the SEC awarded XBRL-U.S. a $5.5 million contract to complete the XBRL taxonomy for U.S. GAAP. At the same time, the SEC awarded another contract to re-engineer the database of information on which the SEC currently stores the information filed by public companies, so that it will be compatible with XBRL reporting. Although reporting up to now has been voluntary, the SEC has hinted that it may become mandatory in the future.

Perhaps the most significant current use of XBRL within the U.S. government is the Federal Financial Institutions Examination Council's mandating of XBRL for reporting by all FDIC-insured banks. Since October 2005, 8,300 banks have been filing their call reports in the XBRL format. This system, which began in 2006, has been resounding success, with the FFIEC reporting faster and dramatically more accurate data access. It also substantially increased productivity of data analysts at the agencies, reducing analytical processing cycle time from over 45 days to under 2 days.

By now, you've probably realized that XBRL is not only for reporting business information--although the acronym stands for eXtensible Business Reporting Language. In reality, it is a structure for reporting information of all kinds, permitting the interoperability of the software systems of many different kinds of reporting or communicating entities. For example, if your agency receives reports or information from state or local agencies, you know that much of this information either has to be re-keyed into your own data systems or analyzed for accuracy, or both. These functions are time consuming--delaying the availability of data for decisionmakers--and often result in data entry errors. The highly favorable experience of the FFIEC, which receives its information from 8,300 banks reporting 2,800 separate pieces of information, demonstrates clearly that XBRL can solve many of the communication problems associated with data reporting to the government from outside organizations.

For a concept that was developed less than 10 years ago, XBRL is growing fast. It was only in April 1998 that a CPA named Charles Hoffman at a small firm in Tacoma, Washington, conceived of the idea that the then new computer language eXtensible Markup Language, or XML, could be used for electronic reporting of financial information. The idea was quickly accepted by the AICPA, which formed a task force to develop a prototype. Upon completion of the prototype, 12 firms, including all the major accounting firms and business organizations such as Microsoft, formed a steering committee to move the project forward with funding from the AICPA. By late 2000, the SEC had become interested, and by the end of 2001 XBRL units were operating in almost every developed country. That same year the Joint Financial Management Improvement Program recommended XBRL for government use. Since then, the concept has broadened and deepened, as multiple uses became apparent.

The most serious obstacle to the implementation of XBRL in the United States is a lack of understanding about its capabilities and value. We are all inundated with information, both in our jobs and in our private lives. It's difficult to believe that there is something new we might have to learn. The mind reels. We resist the idea; we even resist learning about it. But change, I'm afraid, is coming. Like learning to use a computer--including word processing, spreadsheets, e-mail and Internet research--taking the time to learn a new skill will pay enormous dividends down the road.

But in reality we don't really have a choice. There are irresistible economic incentives to make our data systems more compatible, and the network effects will make their appearance. In the case of public company reporting, the companies that make their data available in XBRL format will be rewarded with lower capital costs because analysts will find it much easier to obtain, analyze, model and compare their financial and nonfinancial information. In the case of government agencies, the ones that most quickly make use of the advantages of XBRL will be the best performers for the public welfare. Congress and the public will demand it.

This conference may be your first opportunity to learn about XBRL, or you might be quite familiar with its underlying concepts and capabilities. But whichever it is, you are in for a truly exciting vision of the future. 

Peter J. Wallison is a senior fellow at AEI.