Personally, I strongly believe XBRL will improve the transparency of financial reporting, which I believe should be the #1 goal of all of us in the financial reporting supply chain. In my opinion, the real debate seems to be in how to get there most efficiently.

Needless to say, being the first company found, as Michael says, “to have an incorrectly tagged XBRL document render to look identical to the paper document, but in fact distribute the data in a[] misleading way” would be bad. Very very very bad. Given the attention paid to large cap company financial statements, even in dead tree format, I doubt the big firms that represent the vast majority of public shareholder investment could get away with it. By the time smaller companies, which are a relatively tiny share of total market cap, are subject to the mandate, that software the SEC is looking to buy should be upgraded a few times. If we’re smart, technology to produce more reliable financial statements for smaller companies will soon be in place too, meaning the smaller companies, which produce relatively more new jobs, will have access to a fairer share of public capital, and therefore XBRL will help reduce the unemployment rate.

I’ve never sold short, but if I happened to have an analyst or two with extra time on their hands who could write software to help identify serious tagging problems before the rest of the market and the SEC, it might be nice to short companies with significant tagging problems ahead of their public disclosure. (Whether the SEC or the private sector is the first to publicize such discrepancies will be interesting to see.)

Finally, since the third party tagging system survives while the mandate only applies to companies with more than $5 billion in market cap, and there’s potentially a 30-day gap between the dead tree version and the XBRL version for first time filers, I expect some dead tree format financial statements will end up being tagged both by the company and by third party taggers. That could make make for some interesting comparisons between what investors have long thought companies meant by particular financial statement captions and what companies in fact mean when XBRL forces them to use judgment to tie their caption to a specific provision of GAAP. Of course, Michael’s uncertainty about cost effectiveness and sufficient concern to do such work apply here, too.

It will be interesting to look back in a few years to see what transparency hath and hath not wrought.

When input data itself is audited, wont the output be called audited also?

What ever data that is signed by auditors, the same is going to be used for filing interactive data.

Why is then confusion. Whats the need of fuss, for auditing interactive data?

It is true that one reason for the mandate was to give investors better information, which presumably they want. But because there were other reasons, the “contradiction” isn’t quite that. Other reasons included that tagging by people who know what they mean presumably results in better information than tagging by third parties, which continues to be the case for companies not yet reporting in XBRL. Establishing a sturdy, more useful, more widely used common computer standard in the world of public company disclosure has many benefits beyond improving the data that investors already use.

Computer standards competition can go on forever, and left to its own devices typically does. But until someone steps up to the plate and finally says, “enough,” the benefits of standards are limited. HTML got where it got mostly because it was the only game in town and Web browsers to use it were freely available. U.S. GAAP, on the other hand, because of the challenge of making it reliably machine readable in HTML or plain XML form, required a more sophisticated computer language — and the economic incentives to support the development of less expensive tools to use it. The mandate was intended to drive that development, although the leisurely phase-in has resulted in similarly leisurely software development. (Wealthy investors have long had access to costly XBRL tools to analyze financial statements tagged by third parties.) The facts that XBRL is being used in China, Australia, the UK, the Netherlands, Spain, and in many other jurisdictions for various data in the information supply chain, and the ultimate benefits of global business communication, were added features.

It’s also important to note that it’s the XBRL spec that is now at version 2.1, not any particular taxonomy. With respect to the U.S. GAAP taxonomy, we’re now at 2009. 2010 should be done early next year. One more reason investors and preparers might like XBRL: Their current software will work with updated taxonomies, as long as the spec remains the same. And since disclosure costs are paid from profits that would otherwise belong to investors, and investors benefit when the companies in which they invest can attract enough capital to expand their profits, long-term investors should like it when technology facilitates additional automation of financial statement preparation and auditing. After all, it’s a lot less expensive to build a computer program that can perform the same task repeatedly at zero marginal cost than it is to pay a person to do the same task repeatedly.

It’s the human controls that are most expensive and least reliable when it comes to SOX. Now that it’s possible to use technology to verify that data hasn’t been altered between the source and the output, auditors who take advantage of such tools should be able to bill their clients fewer hours and provide stronger assurances. The question isn’t whether investors will demand XBRL — you’d be pretty strange to have an abstract attraction to something with such a strange name — but whether management will demand better auditing using modern technology at lower prices on behalf of their investors.

A focus on human auditing of XBRL DOCUMENTS could, indeed, be expensive. That’s why machine auditing of XBRL DATA is important. If investors should demand anything, it should be that XBRL improves the business process of auditing. When the SEC Chief Accountant talked about faster, better, and less expensive financial information from XBRL back in 2005, he wasn’t talking about it for his own health. He was talking about it for the health of U.S. capital markets. Much of the newspaper profession didn’t see what the HTML standard would mean to them until it was too late for them to do anything about it. Auditors still have a chance to adopt to the XBRL standard before the potential onslaught of tools that will involuntarily change their work. Perhaps the clock is ticking before technology starts to make old fashioned financial auditing practices seem obsolete to many investors, just like technology has made old fashioned newspaper reporting practices seem obsolete to many readers.

The neat thing about predicting the future is that it’s tough to predict exactly how things will change. But it’s a pretty sure bet that things will change in ways we don’t expect. It seems like a safe prediction that a standard global computer language capable of supporting a revolution in the entire business information supply chain could result in things that even the experts who read and write this blog can’t anticipate. The best one can often do is follow the old Boy Scout motto: Be prepared.