Thank you very much for that very kind introduction. It's an honor to be a part of this program.
There's one formality I have to get out of the way right at the outset. I'm required by our rules at the SEC to remind you that the views I express today are my own and not necessarily those of the Securities and Exchange Commission, of its Chairman, of its Commissioners, or of my colleagues on the staff. Those of us who work at the SEC are all required to recite that disclaimer whenever we speak publicly.
When I started practicing securities law, and for many years thereafter, public companies made their filings with the SEC on paper — today, we'd say "by hardcopy." In fact, as a junior associate, I was dispatched on a number of occasions to travel by plane to Washington, DC so I could personally go to the SEC's filing window to make an important filing by sliding a large stack of paper across the desk to the intake clerk. After the filing had been accepted, you went to the SEC's lobby where they had a bank of pay telephones so you could call everyone who needed to know the filing had been made. It was important to remember to bring a lot of change so you could place those calls. Cells phones were still off somewhere in the future.
In those days, one of the many advantages of working on public offerings in Los Angeles, as I did, was that the last commercial flights to Washington left around midnight. So, if a filing wasn't ready by midnight, you could go home — the offering couldn't begin the next morning (this was before Rule 430A, and we still were doing pricing amendments). Working in New York, on the other hand, you could work through the night and still catch an early flight from La Guardia to DC, getting into National in time to get to the SEC filing window before the markets opened. That meant the New York practice involved a lot more all — nighters.
And, back then, if you wanted to review a public company's SEC filings, you had to go to the public reference room at the Commission's offices, where they would let you make a photocopy. If you worked in Los Angeles, you could call up a service that would make the visit for you and then send the document to you by overnight air freight. Needless to say, that was very expensive, and not something many retail investors could afford to do.
Today, we've gotten so accustomed to EDGAR and the internet that we've forgotten how truly revolutionary they've been. Not only have they made filings much easier to accomplish, but they've provided any interested investor with nearly instant access to all the information filed with the SEC.
What a difference that makes!
My focus in my remarks today is on another development that I expect will offer similar benefits: interactive data. Perhaps to your surprise, however, I'm not going to spend much of my time describing the obvious advantages interactive data will provide investors.
Those advantages, though, are huge. In fact, just a few weeks ago The Motley Fool ran an article about interactive data entitled "The Most Important Shareholder Initiative in a Decade."
But because this is an audience of securities law practitioners, not investors, analysts or financial journalists, I plan to focus instead on what interactive data means to you as lawyers. Why? Because, as they say in the movie ads, interactive data is "coming soon to a theater near you."
You may have noticed a couple months ago that Chairman Cox announced in his remarks at the SEC Speaks program that he expects the SEC will this year adopt rules making interactive data a regular part of SEC filings.
Let me give you an update on that: I predict a release proposing that reporting companies be required to use XBRL in their filings will be considered by the Commission in the near future.
That means that if you haven't already become familiar with XBRL, you won't be able to procrastinate much longer.
Now, I think I can guess how many of you feel about that. Certainly, I know what I probably would have been feeling, had I been confronted with such a development not so long ago, when I was still practicing securities law in the private sector.
In all candor, I suspect I would have been none too pleased. After all, in a demanding law practice it's hard enough finding the time in any 24-hour day to provide high quality service to all your clients. Who has sufficient spare time to devote to learning about a topic like interactive data?
Moreover, the phrase "interactive data" sounds suspiciously like an effort to avoid using the original terminology, which of course we all know was — and is — "XBRL." Unpacking that acronym into eXtensible Business Reporting Language — with the second letter in "extensible" fashionably capitalized — doesn't make it much more appealing. It sounds complicated and technical and not very much fun — like the sort of thing only the geeks who spend their spare time programming in C++ would like.
So if I were back in my former life sitting where you are, right about now I'd probably be wondering how I could make this someone else's problem. Maybe I could somehow persuade my firm to start an interactive data group populated by junior lawyers — junior enough to be drafted for such a task. That would be the ticket. Then I could stick to my specialty — providing sage counsel — and offload questions about interactive data to the twenty-somethings.
And, in all honesty, if I were in your position, I might feel that way even if I thought The Motley Fool was correct to give its recent article that title: "The Most Important Shareholder Initiative in a Decade." After all, I'd assume that, however great the benefits for analysts and investors, the advent of interactive data could only be one big headache for me and my clients.
But if I did assume that, I'd be wrong.
And I'm bold enough to think I can persuade you of that in just the little time we have together today. We'll see if I'm right. You be the judge.
I'm going to try to demystify XBRL by explaining in some detail what it really is. We're going to lift the hood together and look in at the works. After which, I'm hoping you will conclude it's not something you or your clients should fear.
So let's get started. What is XBRL?
XBRL is just a set of rules for attaching identifying codes to items of financial information. In the jargon of XBRL, these identifying codes are called "tags." Think of it as bar-coding for financial information. It's that simple.
Of course, once identifying codes have been attached to each item of financial information in a company's SEC filing, computer software can search for and retrieve any of those items simply by searching for the corresponding tag — and do the same with hundreds or thousands of other filings more or less instantly.
And, of course, once software has collected information in this way from a filing — or a lot of filings-the software can do all the wonderful things software can do with the data it has identified: make graphs, charts, tables, plots, summaries, calculations, lists — whatever is useful to a user.
Now let's make that a little more concrete. After all, it's always easier to understand an example. I said XBRL is a just a set of rules for attaching identifying codes to items of financial information. How does that work?
Suppose a financial statement has a line item called "assets." And suppose the value of assets is shown as $1 million. Tagging that value in XBRL just involves putting a code called an "opening tag" immediately in front of the $1 million number plus a code called a "closing tag" immediately after the number.
As lawyers, in all probability you'll never need to know what the codes look like. After all, only computers, not humans, are supposed to read the codes. But the whole thing is less intimidating once you know how simple the codes really are. So I'm going to tell you a little about the codes, even though you probably won't need to read one.
As I said, they're very simple: an opening code — or tag — is just a name for the accounting item in question surrounded by angle brackets. So the opening XBRL tag for our line item "assets" might be just the word "assets" enclosed in angle brackets: "<assets>." The corresponding closing XBRL tag is the same, except that there's a slash sign after the first angle bracket. The slash sign enables a computer to tell the difference between an opening tag and a closing tag. So the closing XBRL tag for our line item "assets" might be just "</assets>."
So, after tagging, the number $1 million in the line item would have its opening tag in front of it and its closing tag after it. Software looking for a value for "assets" would just search the filing looking for the word assets between angle brackets: "<assets>." When it found that tag, the software would "know" that the number immediately to the right is the value of assets. The closing tag, of course, helps the software "know" with certainty where the last numeral in the number is.
That's it.
A financial statement that's been tagged in XBRL, then, is just a list of numbers, each of which has its corresponding opening tag in angle brackets in front of it and its corresponding closing tag in angle brackets after it. Each item in this list, of course, represents one of the line items in the financial statement (or maybe information in the footnotes). The tagging just makes it possible for a computer to search for and retrieve the data you want.
It couldn't be simpler!
Of course, I have to confess I've simplified a bit and a true-to-life example would be a little messier to look at. For one thing, the numbers in a financial statement represent the value of some accounting concept, like "assets," at a particular date or for a particular period. So the $1 million number in our example would also need to be tagged in a way that identified the relevant date for which "assets" are reported, say, December 31, 2007.
But that just means the tags take up more space than in my simplified example. Conceptually, it's the same.
OK. So tagging is easy: you just need some angle brackets, some slash signs and some names for the items you want to tag.
But let's suppose you had invented the idea of tagging and then were so proud of your invention that you decided you wanted to use your new idea to tag all the financial information of all the companies that file reports with the SEC.
What would you need to do to make that vision a useful reality?
Well, first you'd need to come up with a list — a really long list— of all the possible accounting concepts that would be found in all those financial statements. You'd need a lot more than just "assets" in your list. For example, you'd need items for "current assets," and "inventory" and "work-in-process inventory," and on and on and on.
Once you had assembled a list of every accounting concept US GAAP includes, then you'd need to define a unique tag — the name that goes between the angle brackets — for each one. Coming up with all those unique tags would take a lot of work — you'd be well advised to hire some help — but there's nothing particularly complicated about it.
And while you were at it, clever securities lawyer that you are, you'd probably want to add a few additional features to make it easier for users' software to do useful things with tagged data. In particular, you'd probably want to associate some attributes with each tag.
For example, you'd want any software that read a value tagged as "assets" by your new system to know that the value in question represents a number, not a date. Software, after all, handles calculations involving dates one way, and calculations involving numbers entirely differently. So any software reading your tags would need to be able to look up in your list to see what kind of information it was dealing with.
As another example, because your tags represent accounting concepts, you'd probably want any software that read a value tagged as "assets" to "know" that assets normally represent debit balances, not credit balances. Software reading your tags could make use of that additional information in various helpful ways.
So you'd probably end up adding some additional columns to your big list of all the tags to include these various attributes that it would be useful to associate with each tag you've defined. Next to "assets," for example, you'd have space for the information that the value of assets is a number, not a date, that it's normally a debit balance — that sort of thing.
But you wouldn't stop there. If you were inventing XBRL, and you wanted to make it really useful, there's even more information you'd want to add as well. In particular, you'd want to add information about the relationships between the various accounting items in your big list, as well as useful references to external resources.
For example, each accounting concept worthy of a tag is described in one or more places in the authoritative accounting literature. So it would be a really nice feature to have a database that, for each tag you've created, contained the relevant accounting literature references.
And how about this: it would be natural to expect that people all over the globe will want to use your new system because it makes finding and analyzing financial information so much easier. But they speak different languages in other countries — like French and Korean. So it would be a really nice feature to have a database that, for any supported foreign language, would provide the translation of the name of each tag you've created. That way people in France or Korea could use software to display the tagged information of a US company in their own language.
And here's another idea it wouldn't take you long to realize you'd like to implement. There's a hierarchical character to accounting concepts. For example, "work-in-process inventory" is a type of "inventory," which is a type of "current asset," which is a type of "asset." So users of data tagged with your new system undoubtedly would find it useful to be able to access a database that enumerated the various "parent" and "child" relationships between the accounting concepts you've provided tags for. That might help, among other things, in making elegant presentations possible, with, for example, the various kinds of inventory — raw materials, work-in-process, finished goods — indented under the heading "inventory."
And yet another idea: various accounting concepts have arithmetic relationships with one another. For example, equity equals assets minus liabilities. So your new system would be even more useful if it included a database that listed all the various calculational relationships between the various accounting concepts you've provided tags for. That way, among other things, software using your new system of tags would be able to check to make sure the arithmetic relationships are correct in any financial statement the software reads.
And so forth.
Well, once you had implemented all those excellent ideas — and a few more I haven't mentioned — you'd have yourself what in XBRL jargon is known as a "taxonomy."
An XBRL taxonomy is just a long list of tags for all the various accounting concepts, plus information about the attributes of various elements in the list — that's called a "schema" in XBRL jargon — plus databases with information about the external references associated with the various elements and about the relationships between the various elements — those are called "linkbases" in XBRL jargon.
And the good news is that all the work I've just described has already been done: there's now an off-the-shelf taxonomy for US GAAP ready and available for use. In fact, after a four-month public comment period, the most recent, updated edition is due out later this month.
So the data in US GAAP financial statements now can be tagged using this off-the-shelf taxonomy.
And here's another bit of XBRL jargon for you: the tagged information for any real life set of financial statements is collected in what is called an "instance file." When an SEC registrant makes a filing using XBRL, the instance file is just one of the exhibits to the filing.
And that's XBRL in a nutshell.
Now, there's nothing really complicated about that, is there? XBRL is just a way of putting the equivalent of bar codes on financial data — except XBRL tags are like bar codes on steroids because they are linked through the taxonomy to so much useful information.
It doesn't take a lot of imagination to envision that widespread adoption of XBRL is going to lead to the development of a lot of cool software to enable investors to exploit all that data and all that information in countless useful ways. In fact, some of that software already exists.
But I told you we're not here today to discuss the advantages of all this to investors. We're here today to discuss what this will mean to you and your clients.
So the obvious question is: how hard is it going to be for your clients to tag their financial data?
The answer is: not hard at all, even the first time. And easier thereafter.
OK, OK — you're forgiven in advance if you're a little suspicious of that conclusion, given its source. But by now, we've got a lot of real life experience under our belts. We've road-tested XBRL filings with a voluntary XBRL filing program. Those results are in. Plus, there's already been a lot of experience with XBRL around the world.
We'd like to think our capital markets are the most up-to-date on the planet, but when it comes to XBRL reporting, we're actually following in the footsteps of others. China, in fact, was the first country in the world to mandate XBRL reporting. China started in 2003 with 50 companies that voluntarily reported using XBRL. It's interesting that the Voluntary Filing Program we have here in the US includes about the same number of companies. In China today, the rules of both the China Securities Regulatory Commission and the Shanghai Stock Exchange require listed companies to file their quarterly, half-year and annual reports using XBRL. China's program now includes more than 800 companies.
And China's far from alone. In Japan, the Financial Services Agency now requires approximately 5 thousand companies and 3 thousand investment funds to submit their quarterly, half-year and annual filings using XBRL. It's the same story in South Korea, where all publicly held companies are required to file financial statements using XBRL.
By the way, this international experience shows one of the big advantages of XBRL. If you don't speak Korean, XBRL permits you to analyze a Korean company's financial statements in English. You just use the English linkbase — remember that terminology from a moment ago?
And it's not just Asia. I could take you on a world tour of jurisdictions that are adopting XBRL filing programs. My point, of course, is that financial reporting in XBRL is taking off around the globe. And today we have the benefit of all that experience as well as our own.
I don't have the means here today to give you a demonstration, but I've personally watched financial statements being tagged using XBRL. And it isn't hard — thanks to the magic of computers. You go line item by line item. The tagging software reads the line item description and suggests the tag or tags that are most likely to be appropriate. The software usually makes the right guess, but you can always search for a different tag if you need to. If you're not sure what to choose, you can click and go directly to the corresponding accounting literature descriptions. Trust me, a knowledgeable accountant is not going to have a difficult time doing this.
Beyond that, in time many companies will be using accounting software that includes XBRL data tagging as an integral part of the system. That will make it cheaper and easier for those companies to prepare their financial statements in the first place, with far less risk of human error. And the financial statements that are produced by that software then will have been tagged automatically.
Lawyers, of course, are unlikely to have much to do with any of this. So perhaps the best news I have for you today is that you're more or less off the hook. But you're nonetheless going to need to understand what's involved and know the jargon. So I'm hoping you come away from my remarks today feeling confident there's nothing mysterious or difficult about any of this.
And I hope you also don't miss the important global aspects of this. XBRL is a global language that knows no national boundaries. It's already been adopted in many jurisdictions and many more will follow. With it, you can readily display financial statements and related information in your own language — English in our case — even if the financial statements were prepared in another language. At the same time, we're also working to converge to a single global accounting standard. So it's not too hard to envision the day in the not-too-distant future when investors worldwide will be able to access, analyze and compare the financial statements of companies around the world using globally accepted tagging and accounting standards.
Frankly, I find that exciting. I hope you do too. It sure is a long way from flying to DC to push a stack of paper across the desk at the filing window.
Thank you very much.
# # #
http://www.sec.gov/news/press/2008/2008-48.htm