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.

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 first installment appears below; parts two and three will be published on April 28 and May 5.    

(1) XBRL is still relatively unknown among the financial public, and business professionals who do know something about it have varying expectations of its utility. Some see it as the elixir for all our financial reporting ills; others believe it is merely a money-making scheme for consultants.  What benefits can financial statement users reasonably expect from the adoption of XBRL for financial reporting in the US?   

I don’t know if XBRL ever will or ever should be known among the financial public or most business professionals.  What most people will see is information being available faster, things being cheaper, functionality being better, staff doing less rekeying, and such.  Consider the US FFIEC (Federal Financial Institutions Examination Council) use of XBRL.  The typical bank has no idea that they are using XBRL.  This is probably the same for the typical FFIEC analyst who uses the data.  They do things pretty much like they did before using the same software.  But go talk to the software vendors and ask them how much easier it is to update the metadata for their applications.  They used to have to cobble together information from Excel, Word, and PDFs in order to update software if the FFIEC changed the data being reported — which they did not do often because it was so painful.

Or go talk to the analysts of the FFIEC.  What they do is the same, it is just that the data is available in two days rather than the average of between 60 to 75 days.  The analysts are also 10% to 33% more productive.   (There is more information specifically about the FFIEC on pages 31-33 of Charlie’s book Financial Reporting Using XBRL. )

XBRL is not “an elixir for all our financial reporting ills.”  XBRL is a tool.  Just like an electronic spreadsheet is a tool.  I lived through the change from paper spreadsheets to electronic spreadsheets.  There are a lot of similarities between that change and a change to using XBRL.  It is a well known fact that generally people don’t like change.  So some of them make up unsubstantiated statements such as “XBRL is merely a money-making scheme for consultants,” because they have no real facts to base their case on.

I am no expert on financial statement users.  Being a CPA I am more on the financial statement creator side of things.  But based on what I do know about using financial statements and what I have seen from the data coming out of the FFIEC project, I can highlight these benefits:

(a) Financial statement users will have data available faster (for example, the FFEIC system going from 60-75 days to two days , as cited above).
(b) Financial statement users will do less rekeying of information; they will be able to automatically extract information.
(c) Because of (b), financial statement users will have more choices of HOW they can see that information, because it is easy to extract data and repurpose it for other things.   And isn’t that why people exchange business reports, because someone has information which someone else wants to use for something?

To highlight the benefits to preparers:

(a) “Smart” systems will be developed to help preparers create the financial information.  This is because those systems will make use of the structured data, i.e., the metadata that will be able to drive the creation of the financial report or other business report.
(b) These same systems will be able to validate 100% of the computations within that business report using relatively inexpensive software.  Therefore, quality will be improved and the cost of achieving that improved quality level will be reduced.
(c) These same systems will be able to validate that the disclosures made are appropriate.  This is not about the actual information being disclosed — you cannot check that automatically.  This is about the type of things caught by a disclosure checklist, which today is a paper form that CPAs wade through manually to make sure everything is done correctly.  Leveraging XBRL, software will be able to use that same metadata to verify many of the anomalies discovered by a disclosure checklist.  Not everything — probably about 80% of what is currently in a disclosure checklist.  Here’s an example: “If Property, Plant and Equipment is on the face of the balance sheet, then the following disclosures are required: ….”  In other words, simple if, then existence checks.
(d) The entire workflow of creating a financial statement will benefit from XBRL.  Today it takes hours to work a change through a financial statement, such as an adjustment which impacts net income.  So many different parts of the report are affected, and all the different impact points need to be adjusted.  That process takes hours.  With XBRL, it will take seconds.  Also the consolidation process will be vastly easier because it will be more automated.

I could go on and on.  I have demos of most of these sorts of things.  I created these examples and use cases to be sure XBRL could do all these things during its development and to test to see if XBRL worked in the software being created.
 
(2) In your recent white paper titled What CFOs Need to Know About XBRL, you recommend that CFOs have their companies become early adopters of XBRL. What advantages will companies enjoy by adopting XBRL now rather than later? 

The primary benefit of tinkering with XBRL is that you will determine if XBRL is useful for you or if it is not.  That is what United Technologies did.  They spent a little time and money to tinker around with XBRL, seeing what it would do, learning what it would not do.  The results were good and they became more curious, so they did more.  (See this piece in the June 2007 Journal of Accountancy for more information.)

Some companies are leaders, some companies are followers.  This is pretty much a fact of life.  If you want to be a leader, lead.  If you want to follow, there is nothing wrong with that.  United Technologies values leading in this area.  Also, they like improving their processes, making things better, faster, and cheaper.

I cannot go into detail, but I can say that United Technologies is doing even more with XBRL, and some of these activities have nothing to do with external financial reporting. So I guess the bottom line here is that the best benefit to being an early adopter is figuring out for yourself if XBRL has value and where, and using the technology earlier than others.

(3) As the Father of XBRL (I hope that title isn’t tiresome for you), you have been both a key player and observer of the development of interactive data since its inception. As you look back over the past ten years or so, has the pace of XBRL implementation in the US been slower, faster, or about what you had expected? Have there been any major surprises for you in XBRL’s reception, either positively or negatively? 

Frankly, I had no idea when or how XBRL was going to be adopted.  I was pretty much going along for the ride.  The past ten years have been pretty much one surprise after another.  Me, and a lot of others, just did what was necessary for adoption to occur if anyone chose to do so.  That had to be step one.

The biggest positive surprise was what the FDIC (Federal Deposit Insurance Corporation) did.  And I guess really it was not what they did, it was the timing.  The FDIC stuck its neck out and put it on the line.  They did not do this blindly.  They kicked the tires for about 18 months before they started a project; I know this because I helped them.  When they wanted information, I did the best that I could to help them get it.  So while risky, the risk was very well calculated and managed.  They did a great job and now they have a system which they are quite pleased with and, as I understand it, they are looking to use XBRL in more areas.

So my strategy was to go with the flow and learn as much as I could during the process because I knew all this could work.  And this is not to say that I did not do a little “pushing” here and there when necessary.

Probably the biggest major negative surprise is how much politics plays a part in this entire process.  I think I was just naïve and did not realize how the world works.  Playing those politics is something that I stayed out of.  There are others who may not really know much about the technology, but they sure understand how to deal with the politics.

Data Interactive, the Hitachi XBRL blog, recently upgraded its blog platform; our new URL is http://hitachidatainteractive.com. A majority of the blog’s feeds were automatically updated, but some apparently were not. If your feed isn’t working, one solution is to re-subscribe (you can use the Web Feed link in the upper right corner of the blog)  and then delete your old feed. Thanks for your cooperation, and we apologize for the hassle.      

Written by Bob Schneider     Posted on April 22, 2008

Here are a few XBRL items from recent days that are worth looking at:

(1) In an April 11 story, CFO.com says that “companies participating in the XBRL voluntary program have seen no improvements to their internal operations, according to Financial Executives International.” As Christian Dreyer notes on his European Pensions blog, for now XBRL statements are produced using the bolt-on (as opposed to the integrated) method, so preparers aren’t gaining additional benefits; at the same time, the additional costs are limited. But he also says the article’s characterization of FEI’s concerns about XBRL statements providing “excess information” (as the article puts it) is an “undue truncation” of a more nuanced point made on page 11 of the FEI’s comment letter to the SEC:

“We believe we may be creating a situation where preparers will be providing more information than the analysts want (versus key information/data), later than when they need it (to update their models), thereby missing the real window of opportunity which is likely when a company releases its earnings for the quarter.”

I do think using the phrase “excess information” in connection with interactive data is unfortunate: It implies XBRL adoption will require companies to provide financial information they have not already been supplying in other formats.     

(2) Another item of interest from the FEI:  In mentioning on its blog that the SEC has postponed its scheduled April 21 meeting on XBRL adoption to May 14, the FEI also notes there will now be an intervening meeting of the Pozen Committee on May 2. Thus there will be an airing of recommendations and testimony regarding the Committee’s proposals before the SEC’s interactive data announcements.

(3) Financial Week has a useful article on what the SEC’s proposals might entail.  I could do without their scary subhead, however:  “Regulator poised to hit companies with costly data-tagging job that it says will help clarify financials.” The “costly” description isn’t borne out by the content of the piece.    

(4) On the tenth anniversary of the genesis of XBRL, Charlie Hoffman has published on his blog a wonderful reminiscence on how he came to conceive of interactive data and describes the first steps toward making it a reality. (BTW, Charlie has graciously agreed to do an interview with us, which we’ll be publishing over the next couple of weeks.)  
 
(5) Finally, in case you haven’t seen it yet, the SEC’s Mutual Fund Reader is now available.  In my view, the best thing about the new viewer is that it helps create a critical mass of SEC XBRL tools which allows users to see the power of interactive data.

Written by Matt Kelly     Posted on April 21, 2008

Matt Kelly is editor-in-chief of Compliance Week, a magazine and online newsletter on corporate governance, risk, and compliance. Prior to his role at Compliance Week, Kelly was a reporter and contributor on corporate compliance and technology issues for magazines such as Time, Boston Business Journal, eWeek, and numerous other publications.

It seems the Securities and Exchange Commission is finally ready to make good on its promise to decide the fate of XBRL adoption in U.S. financial reporting. In its own bureaucratic way.

The Commission startled Corporate America last week with an announcement that it would vote April 21 on whether to amend its rules to require use of XBRL — and then just as quickly postponed the meeting until May 14. SEC spokesmen say the delay is merely due to unforeseen scheduling conflicts. It also gives commissioners time to hear more input from two (supposedly) important meetings: an April 22 congressional hearing on the state credit ratings agencies, and a May 2 meeting of the SEC’s own Committee to Improve Financial Reporting.
 
Regardless of whether the SEC’s stated reasons are its real reasons — and it’s always hard to tell with government agencies — the time has come to strap yourselves in. The SEC is actually going to start moving, and a rocky road lies ahead. The plain truth is that for all the past enthusiasm about XBRL, powerful and vocal skeptics still abound.

Granted, the Commission has already sunk a lot of effort into promoting XBRL, so I’m hard-pressed to believe the technology will not eventually become law of the land. But getting there will be a long, slow process. The problem? Well, the problem is likely to be the SEC itself.

Start with the agency’s long history of underestimating how complex its financial reporting reforms will really be. The star example here is, of course, the Sarbanes-Oxley Act, which requires companies to test and document their internal controls over financial reporting. In 2003, the SEC originally estimated that SOX compliance would cost an average of $90,000. Today for a large company, that bill routinely runs into the millions. XBRL proponents — who, in my observation, tend to come from the technical side of things —should be absolutely clear: Their counterparts on the corporate finance side bring up fears of another SOX disaster every time anyone mentions an XBRL mandate. The SEC needs the trust of the business community to pull this off. Right now, the SEC doesn’t have it.

Worse, to gain that trust, the SEC will need a deliberative, collective process to hammer out exactly what its XBRL mandate will say. That does not make for a swift implementation of anything, let alone a complicated new technology. Expect hearings, proposals, comment letters, more hearings, revised proposals, more comment letters, and then a final rule for some phased-in approach over a period of years — and that will get comment letters as well. There’s always the risk that someone from Congress could file a bill to slow (or even stop) the process, too.

All of this will last well beyond Christopher Cox’s tenure as chairman of the SEC, which expires in January. XBRL has had no stronger friend in the United States than he, so it’s worth wondering how much momentum XBRL can maintain when he’s gone. Whoever leads the Commission after Cox will have plenty of other concerns, including calls for reform of the financial regulatory system that would overhaul the SEC right out of existence.

Those are pretty formidable obstacles, and we haven’t even delved into the small detail that most companies either have not heard of XBRL at all, or couldn’t care less to implement it. So I’m not surprised that the SEC is off to an inauspicious, hurry-up-and-wait start of announcing its first XBRL meeting and then promptly delaying it. That may well be a the tenor of things to come for a long while.
 

Written by Gary Purnhagen     Posted on April 16, 2008

Gary Purnhagen has more than 30 years experience in helping firms in diverse industries meet document processing challenges, including SEC disclosure. His engagements have included responding to the SEC’s EDGAR program, use of the Internet and other digital media for information dissemination, and most recently XBRL. Over the past three years he has given dozens of executive briefings on XBRL and spoken about the standard at a number of professional seminars.

The SEC will soon release their proposed rules for mandating XBRL. If the SEC’s Voluntary Filing Program (VFP) and all the speeches Chairman Cox has given have not convinced the public that the SEC is serious about making XBRL a reality, these proposed rules should.

Since September 2007, when Chairman Cox announced he had requested rules to be developed for XBRL implementation, there has been much speculation as to what these rules would entail. The Advisory Committee on Improvements to Financial Reporting has provided their recommendations, and now we wait to essentially see how aggressively the SEC proceeds. There shouldn’t be any question as to whether these rules will establish that XBRL will be required and provide a timeline for mandated phase-in; rather, what will these rules look like and how quickly will companies be required to comply are the key questions.

What can we expect? Beginning with the EDGAR program back in the 1980s, I have watched the SEC’s modernization initiatives for over twenty years. Based on that experience, here’s my best forecast on what we’ll be seeing in these proposed rules.

The big question is when, i.e., When will companies be required to submit financials tagged with XBRL?  I believe we’ll see the SEC propose that the 1,200 largest domestic companies in terms of market capitalization be required to furnish XBRL exhibits beginning in 2009. A company will not have to make its first submission of XBRL exhibits with its 10-K; rather, it will be able to wait until its first 10-Q. These filings will not be official, hence the word “furnished”  — just as the current companies participating in the VFP are “furnishing” their financials tagged with XBRL in exhibits.

Having the financials furnished will also alleviate the need to have them audited. Clearly, the accounting industry is not ready for that, and at this time having to do so would make this new ruling very expensive. The main difference between the current volunteers and the companies being mandated to submit XBRL exhibits will be that, under mandate, companies will be required to tag footnotes to financials on a block level.

The proposed rules will also offer a phase-in for the rest of the SEC registrants, probably giving this first group a 12-month period of time before the next wave of phase-ins. The SEC will break up the phase-in groups by:

• The rest of the large accelerated filers (market cap over $700 million)
• Accelerated filers (market cap over $75 million)
• Non-accelerated filers (market cap  less than $75 million)

What will be the SEC’s justification for this? It will claim that their VFP has been a success. Seventy-six companies have submitted XBRL exhibits with over 340 filings, and 18 funds have submitted XBRL exhibits for 24 risk/return sections of prospectuses. Volunteers submitting XBRL have reported that doing so wasn’t that expensive or difficult, and that after the first filing both the expense and time required to submit XBRL statements was reduced drastically. The SEC will emphasize the value of XBRL to disclosure documents, pointing to the online XBRL viewers that they have funded –The Interactive Financial Report, Executive Compensation, Financial Explorer, and now the new Mutual Fund Reader. The SEC will also argue that the value of these tools will increase exponentially as the database of XBRL financials grow.

I believe the publishing of the proposed rules will be a major trigger point for companies to begin volunteering in the SEC’s VFP. From numerous conversations I’ve had with executives of companies that are SEC registrants, they will not wait until they are actually mandated to begin submitting XBRL. The proposed rules will be the signal that the SEC is serious about a mandate, which these companies have been waiting for. Companies would rather begin as volunteers and not get caught up in a stampede.

As more companies add to the database of XBRL tagged financials, we’ll see more investors using it and more tools being created, which will lead to other companies, large and small, submitting their financials in this format as well. After all of the carrots that the SEC has been trying to offer to get companies involved, it will in the end be the threat of the stick that gets them involved.

Written by Bob Schneider     Posted on April 10, 2008 

On the (very) odd chance you’ve never heard of a FAQ, it’s a list of Frequently Asked Questions about a particular subject, along with their answers. According to Wikipedia, the first FAQ was created for the SPACE mailing list of NASA in 1983.  Now, of course, FAQs have become de rigueur as a device for learning about any new subject. In a field like interactive data, which is not immediately intuitive and has so many facets, a FAQ can be an extremely useful teaching tool.

One of the best FAQs on XBRL, even if its title doesn’t bear that three-letter abbreviation, is Charlie Hoffman’s What CFOs Need to Know About XBRL. Published just a few weeks ago, it covers key points such as an SEC mandate, who is using XBRL, what a taxonomy is, and what skills are required to prepare an instance document.

For XBRL Global Ledger, the XBRL GL Working Group has not only provided a text FAQ but a 50-minute webcast as well. Eric Cohen, who has spearheaded the development of XBRL GL, and Gianluca Garbellotto, chair of the Working Group, answer more than 40 questions, ranging from Why Is XBRL GL Needed? to What Competitors Does XBRL GL Have?, as well as addressing costs and benefits.

Here is a list of some other useful FAQs on interactive data:

• XBRL.org   A lengthy and wide-ranging FAQ from XBRL’s international consortium.

• IASC Foundation   A technically oriented list, providing descriptions of such terms as extensions, schema, and linkbases.  

• Grant Thornton   This excellent FAQ with 28 questions is a bit dated but still highly useful.

• XBRL Australia   This very detailed FAQ answers loads of technical questions. Although it requires significant updating, it is still helpful for basic technical facts.

• Microsoft   A short FAQ with some answers about the software giant’s adoption of interactive data.