Bob Schneider is a Partner in 
Wilson So is the Director of Hitachi Consulting Corporation XBRL: You Can Build It, But Will They Come?
Written by Michael Alles Posted on August 25, 2009
Dr. Michael Alles is associate professor at the Department of Accounting, Business Ethics & Information Systems at Rutgers Business School and editor of the International Journal of Disclosure and Governance, whose August 2009 issue is entirely devoted to XBRL. His specialties are continuous auditing, XBRL, and governance.
For a technology that is designed to increase the transparency of information, there is much that is still opaque about XBRL itself. Even as the firms that make up the overwhelming majority of market capitalization in the US begin reporting to the SEC using XBRL for the first time, fundamental questions remain about the demand for interactive data and how investors and others will make use of it.
Just a few weeks ago at an XBRL panel at the American Accounting Association annual meeting in New York, Bob Laux of Microsoft, which in early 2002 became the first technology company to report their financials in XBRL, said “I would love to know why it was that so few firms joined the voluntary filing program (VFP)." As Glen Gray noted in his talk XBRL: Solving Real World Problems:
Despite the potential benefits of XBRL only 137 companies (out of over 10,000 filers) participated in the SEC’s voluntary filing program (VFP). Less than 1% of the banks required to use XBRL for quarterly call reports to the FFIEC are also participating in the SEC’s VFP. XBRL adoption appears to be sitting on the edge of the chasm between the early adopters, who are tolerant of the issues associated with new technology and are less concerned about near-term ROI, and the majority of the potential market, who are more sensitive to costs, ROI, and ease of use.
Contemplating the low levels of participation in the VFP, Bob asked plaintively "What does that say about XBRL?"
What, indeed.
One is tempted to dismiss such questions about the VFP as obsolete now that XBRL is mandated, but that may be too facile. The fact of the matter is that XBRL is marketed as so self-evidently beneficial at so trivial a cost (“chickenfeed” is how Bob described the cost of the approximately 24 person-hours that he said it took Microsoft to tag its latest reports, down from 180 hours in the first year), so widespread in the efficiencies it would generate throughout the information value chain, and so clearly going to reduce the cost of capital for reporting firms, that people should have lined up around the block demanding XBRL. In fact, some of the original pioneers of XBRL, such as Eric Cohen, have mixed feelings about the government mandate for tagging, since they had always envisaged XBRL adoption as arising naturally as a market-driven phenomenon.
However, as Professor Gray points out, even as US banks have built up a deep familiarity with XBRL — given the early decision by the FDIC to require tagging of call reports — the bottom line is that almost no banks took the (what presumably would have been for them a trivial) extra step to also tag their financials. There is clearly something going on here — fear of litigation, lack of knowledge, lack of interest — that was not envisaged.
And demand is not the only unanswered question about XBRL. Take assurance: the SEC does not require it (as yet), but it does not discourage auditors from looking at tagged documents. On the other hand, for reasons best known to itself, the SEC does not allow the audit opinion itself to be tagged!
Of course, one can make the market efficiency argument for not mandating that mandated XBRL statements have a (mandated) audit opinion and, instead, letting the market decide the value of such statements, with firms providing voluntary assurance if they judge it warranted. But the contradiction between having to mandate XBRL statements because the market isn’t demanding them and then leaving assurance to market forces is fairly obvious.
While the position of firms on assuring XBRL reports may change as their two-year safe harbor provision expires, even if assurance proves desirable, the question remains about how that assurance will be provided. Ironically, here the apparently low cost of preparing XBRL statements works against their assurance. If it takes Microsoft only 24 person-hours to tag their reports, realistically how many audit hours will they be willing to pay to provide assurance for them? And even 24 hours may be an outlier, with Phil Moyers of Edgar Online claiming that, with his automated tagging approach, a typical firm’s statements can be processed in no more than 8 to 10 hours.
Contrast that with the elaborate framework Professors Alex Kogan and Raj Srivastava have come up with for aligning XBRL assurance with standard audit practice and their argument that no current proposal for auditing XBRL instance documents is consistent with auditing standards. Will audit firms be able to come up with an expedited low cost audit procedure for XBRL documents (i.e., low enough relative to the expected cost of repeated XBRL tagging that may be no more than a few tens of thousands within a few more years)?
It’s possible, but let’s not forget that Congress expected that it would take a typical firm no more than 90 minutes to comply with Section 404 of the Sarbanes Oxley Act, as opposed to the billions of additional revenue that it generated for the audit firms. The fact is that in the litigious environment of the US, no auditor will sign off on an entirely new statement with only the brief examination that low cost allows, while it is equally unrealistic for firms to pay more to assure a document than they pay to prepare it.
What these examples indicate is not that there is a fundamental problem with XBRL as a technology, but that it is now much more than a technology. It is becoming part of the fabric of US business life and hence subject to all the forces and pressures that occurs in business, from resistance to change to fear of litigation.
The latter may be the biggest hurdle that XBRL will likely have to overcome if it is to fulfill its promise, as evidenced by the tale of the extension tags. As far as the VFP is concerned, a very large proportion of tags were extensions. The story is apparently that lawyers recommended to filers that existing terminology from the firm’s financial statements be retained as an extension rather than allow even small changes in order to use an official taxonomy item. And there is much more use of extensions today than one might expect given that the current taxonomy has over 14,000 tags.
What is interesting is that this “better safe than sorry” argument was never apparently countered by the case that better tagging would facilitate better comparisons with peer firms and a more favorable reaction in the capital markets. Perhaps the latter argument will come to the fore as more firms file in XBRL, and the SEC is clearly pushing firms harder to stick to the standard taxonomy. But this example clearly demonstrates that predictions about how tagging will work in practice cannot be made on a purely technical basis alone, and hence, many more unexpected outcomes are to be expected as the mandatory program kicks in.
Perhaps the reality is that managers simply do not perceive tagging in the way that the IT specialists who have made it a reality do. One more story: academics have repeatedly pointed out that many of the VFP filings did not even do something as basic as validate, and often contained many other easily detectable technical errors. Hopefully, these problems will decrease with more experience and the SEC previewer feature will greatly help filers submit only valid instance documents (though the fact that the SEC felt obligated to offer a previewer in the first place is quite telling). But the question is why filers made such elementary errors in the first place, when voluntary filers most of all are surely driven by expectation about the net benefits of XBRL. Perhaps “good enough” is about as far as managers are willing to go with tagging and see no reason to give it a higher priority. That would disappoint many of the advocates of XBRL, but it is perhaps a realistic assessment of where tagging fits into the already overfull agenda of today’s CFOs.
With the SEC mandate for XBRL coinciding with the tenth anniversary of the birth of the standard, it is worth asking where tagging will be going over the next decade. Will it become the new language of business, as the AICPA put it in a recent publication, or will XBRL be ubiquitous in the way PDF is today: part of the plumbing of business infrastructure, essential certainly, but also unremarkable. Success may actually mean that it is both, but we should have no illusions that the road from here to there will be smooth just because we have a taxonomy that is 2.1 instead of 1.0. It is time that XBRL be seen by users, regulators, academics and preparers as a business practice, with all the complications and unknowables that this implies, and finally put aside the illusion of the technician, i.e., that if you build it they will come.
August 25th, 2009 at 8:53 pm
I don’t know any technicians who had illusions, but I do know that investors have used and demanded machine readable financial statements for quite some time and that many of those statements have been using XBRL for years. Investors just didn’t know it. The difference is that now the XBRL tagging is done by the preparer instead of by third parties “scraping” data off EDGAR and translating HTML and ASCII into XBRL.
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.
August 25th, 2009 at 11:28 pm
I have one simple query.
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?
August 26th, 2009 at 8:37 am
Punya, XBRL is the medium by which auditing financial statements will be distributed to end users. However, converting financial statements into a XBRL tagged instance document is not an automated process like converting a word document into pdf. Judgment is called for in deciding which tag should be used for each line in the statement and there is a large amount of other information that goes into an XBRL instance document. The question is whether anyone should check to see if the XBRL output is “the same” as the underlying financial statement. Moreover, it would seem that it is possible to have an incorrectly tagged XBRL document render to look identical to the paper document, but in fact distribute the data in an misleading way. Hence, assurance of XBRL documents is not a trivial matter, but whether it can be done in a cost effective way, or whether anyone cares enough to demand it, are different matters.
August 26th, 2009 at 9:32 pm
It looks like the SEC is in the market for software that could help its own staff use its tagging judgment more efficiently to evaluate company tagging practices. See https://www.fbo.gov/download/80b/80b2c2eb1311ad0affd22cbb4cf0211c/RFP_SECHQ1-09-R-9003-Amd-000001.pdf. Perhaps more than one SEC accountant will take some time to compare the paper statements they’ve worked with for years to the new XBRL data. Perhaps there will be performance incentives for finding discreprancies.
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.
August 27th, 2009 at 1:55 pm
I just want to make sure that the comment attributed to me (What does that say about XBRL) is not taken out of context. One of the main purposes of the XBRL panel at the American Accounting Association Annual Meeting was to discuss and encourage academic research in the area of XBRL. As noted in the blog, I raised the issue of whether academic research could help in figuring out why so few firms joined the voluntary filing program. Central to me raising that issue is whether academic research can help inform if a regulatory or voluntary approach to improving transparency is most appropriate, or whether (or if) a voluntary approach may be modified in order to improve transparency. I was fortunate to be approached by Virginia Cortijo who is an assistant professor of financial analysis at the University of Huelva, Spain, and has collaborated and researched at Rutgers University. She sent me a copy of her research that has been accepted for publication in the International Journal of Digital Accounting Research (A Delphi Investigation to Explain the Adoption of XBRL), as well as an article she co-authored in Online magazine (Implementing XBRL Successfully by Mandate and Voluntarily).
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.