Bob Schneider is a Partner in 
Wilson So is the Director of Hitachi Consulting Corporation An Interview with Charlie Hoffman (Part II)
Charlie Hoffman, who is widely regarded as the originator of XBRL and has one of the most distinguished resumes in the field, kindly agreed to do an extensive interview with us. The second installment, beginning with question (4), appears below; part one was published on April 23 and part three will be published on May 5.
(4) Recently CFO.com quoted the CFO of a $50 million market cap company who estimates that taking XBRL implementation in-house would cost his company at least $50,000 for the first year, with that expense halved for subsequent years. Do those numbers sound about right to you? How do you see the cost/benefit equation for small-cap firms? Do you see any solutions for reducing the cost burden on small-caps?
As I see it, people focus on “cost” too much when they should focus on “net cost/benefit.” I heard these same types of arguments when people were considering whether they should move from a manual accounting system to a computer accounting system in the 1980s. Then I heard it again when people who had DOS-based accounting systems wanted to upgrade to a graphical user interface or a SQL database as compared to a proprietary data format.
The way I see this is quite simple. Look at the total costs, look at the total benefits, compare the two.
Most of my experience is with smaller private companies, not with public companies. These are companies with, say, $10 million to $50 million in sales. I can tell you without a doubt that every company I have worked for in that category can make use of XBRL and have a net benefit. I know this because I was doing some of the things which XBRL does, but using proprietary formats which were not even XML (this was back before XML existed and I knew nothing of SGML).
Also, a colleague of mine who is also a CPA and worked with me at the CPA firm where I first conceived of the idea of using XML in financial reporting currently uses those fundamentals in what he is doing for businesses. He is not using XBRL, but rather his own proprietary XML formats. But he is integrating workflows together; his customers are quite happy and keep hiring him to do more and more. There is simply no way that what he is doing cannot be done better and cheaper by using a global standard format (say XBRL) instead of his proprietary XML.
If companies are looking at XBRL in terms of how much it will cost them to file with the SEC they are making a fundamental mistake in my book out of the gates. But, if that is all they want then I would suggest that they simply have a service bureau create their XBRL for them. For example, Edgar Online and R.R Donnelley have a service that can, they say, already tag most company’s primary financials today.
(5) How do you see XBRL education developing over the next several years? Should XBRL be part of the required curriculum of accounting majors? How much technical, “angle-bracket” understanding of XBRL will the next generation of accountants need to have? How much, if any, XBRL knowledge should be tested on the CPA exam?
In my view XBRL education is directly tied to software. The software that exists today is not mature enough to have all the features needed by business users. What exists currently mimics the XBRL Specification well, and I guess this is a part of the natural progression of building software. What I mean is that if you pick up a copy of the XBRL Specification and you pick up XBRL software you would be quite happy with most XBRL software…it implements the XBRL Specification.
But there are two problems with this. First, no business user is going to pick up the XBRL Specification. Second, XBRL software is not the software which is needed…business reporting software is needed which leverages the characteristics of XBRL.
Now this probably is simply the first phase of getting to the right software: you fundamentally need to work with XBRL, build XBRL processors, build taxonomy creators, etc. Personally, I really wish this software would appear faster!
Another aspect of this situation is that XBRL itself needs to be simpler. This is what XBRLS is all about. Fundamentally, I think XBRL has too many unnecessary options which cause complexity (see my article on XBRLS for more information). There needs to be some adjustments to XBRL; when the right software starts getting built, the software vendors will be demanding these changes, because business users will be demanding software that works how they need it to work.
As I see it, XBRL has nothing to do with the fundamental principles of accounting, and I don’t think it belongs on the CPA exam. XBRL does have to do with how accounting is practiced. XBRL is a tool. What I mean is that it would be inappropriate to test how to use Excel on the CPA exam. How one does something, i.e., organize the solution to some problem using a paper spreadsheet or an electronic spreadsheet, has nothing to do with understanding the fundamentals of accounting and financial reporting.
It may be the case that accounting majors use tools which make use of XBRL to learn about accounting topics. It may be the case that some chapter in a course explains fundamentally what XBRL is, how it works, etc. But I would ask you: When you receive instructions on how to drive a car; does it include how an internal combustion engine works or how to give your car a tune up?
On the other hand, there will likely be a number of accounting specialists who get into the angle brackets. But how many marketing people do you know who understand HTML and Java Script? See my point?
(6) The recent Progress Report of the Pozen Committee recommended a phased-in approach for XBRL statements. In a letter of dissent, Peter Wallison of the AEI criticized this pace of adoption as too slow, and disagreed with the Committee’s recommendation that statements should initially be furnished, rather than filed. How do you see the relative merits of each course of action? What scenario would you find most constructive for XBRL adoption?
From what I know most production systems which replace some old filing format with XBRL end up having one format – XBRL. In my view, that is what will end up at the SEC eventually.
The “furnished” versus “filed” and the phased-in versus something else are all political decisions. This is a decision for others with more understanding of the dynamics of the politics, and it will depend on the resolve of the parties to replace the status quo with something that is new and improved. The FDIC has one format for everything; it was not phased in, but that was a different set of dynamics.
I predict that the end result will be everything in one format: XBRL. When that will happen, again, it boils down to resolve.
(7) The Progress Report also made mention of the use of extensions. The authors believe that, given the development of detailed US GAAP taxonomies, the need for extensions will decline in the future. Do you agree with that assessment? More specifically, do you think there will there be significant pressure on companies to limit the use of extensions, either to (a) insure that their statements will be comparable to peers’, or (b) avoid the possibility of raising “red flags” to analysts.
I agree that the use of extensions will decline over time. I don’t agree with points (a) and (b) above, however. I could be wrong, but I cannot see a company reporting in order to be comparable to its peers. Also the red flags exist today for analysts. XBRL does not change what is reported, it only changes the medium. Analysts know what the red flags are. Companies probably do also, I would speculate. XBRL may help the analysts get to the red flags faster, but XBRL helps analysts get to all the information faster…not just the red flags.
I believe the reasons for fewer extensions will be because the base US GAAP taxonomies will get better over time. Also, as users understand XBRL more and more, they will realize that a lot of the variability merely reflects personal preference. For example, what difference does it make if you call accounts receivable “Receivables, Net” or “Trade Receivables, Net” or “Accounts Receivable, Net” or “Receivables, Trade, Net”, and so forth. Also, I believe that XBRL will help tune GAAP to be less vague in the areas where it is somewhat vague. This is because having one taxonomy will add clarity in some cases where clarity was needed.
The discussions that are part of building taxonomies are interesting and insightful — for example, those about the order of the different breakdowns on the income statement relating to extraordinary items, discontinued operations, and accounting changes.