Interview with Daniel Roberts, CEO of raas-XBRL (part I)
I was pleased to have an opportunity to speak to our old friend, Mr. Daniel Roberts at the beginning of this 2011. Daniel is CEO of raas-XBRL and has been at the heart of XBRL since 2003. He is the past Chairman of the XBRL US Steering Committee, and member of the XBRL International Assurance Working Group. He has a detailed knowledge of XBRL that comes from being deeply involved in XBRL for the past eight years.
1. The year 2011 is definitely the year of XBRL in the USA. The third phase of transmission of the XBRL data to SEC is approaching. Will the plans for this year be successfully accomplished and what are, according to you, the biggest risks of this not happening?
My own expectation is that 2011 will be a fantastic and fascinating year for XBRL, in the US and around the world. Of course, all eyes are on the third year of the SEC XBRL compliance mandate, and the SEC itself estimated that 8700 companies would be required to provide XBRL versions of their 10Q and 10K filings. I do expect a backlash, as the mandate approaches and companies realize they simply are not ready. We are seeing that already in the UK, and I’m very pleased to see HMRC come out and say that there will not be a delay.
On the other hand, as word of the effort involved with “detailed tagging” becomes more widely understood, I think the SEC is going to have to demonstrate the value that is actually being derived from the extra effort.
2. Perhaps it is too soon to talk about it, but how do you see the 2012. XBRL year in the USA and on the global scale? Will we still be dealing the same problems, or do you expect a new phase of the XBRL use?
Lets start with globally – 2012 will be a year of looking back on a successful completion of the first phase of the SEC’s compliance mandate and the first year of the HMRC mandate. Across Europe companies reports will be in XBRL (even if they do not know it), and across Asia the number of countries collecting data in XBRL will continue to expand.
Of course, the recent letter (1 Feb 2011) from the FEI (Financial Executives International) outlining examples of the cost and impact of detailed tagging makes grim reading. The letter discusses a survey of members by the FEI’s CCR (Committee on Corporate Reporting) in which at least one member indicated that detailed tagging had resulted in an additional 2000 hours per quarter of effort to create the XBRL. While I would expect that requirement will drop considerably, if that was for the first time creation of detailed tagged XBRL, that equated to 4 full-time additional resources for that quarter. What small business can afford to hire additional staff simply to produce one additional output format for the SEC filing?
So I predict that long before we get to 2012, the SEC will have deferred detailed tagging for the group-3 filers. It is that or face a wholesale rebellion by filers, and howls from hundreds of rented congressmen on their behalf.
3. This phase is most definitely the biggest challenge so far regarding the preparation of XBRL. On one hand, the companies in question are small, with small budgets, and on the other with a small number of employees who could dedicate their time to the preparation of the XBRL. What is your recommendation for these companies in terms of In-House vs. Outsource?
This may seem self servicing, but they should outsource. It is this simple – XBRL remains a “new” technology and as such will require too many hours of learning and training, coupled with the purchase of expensive software, for something that is a 4 times a year output process. There are vendors (raas-XBRL included) that are able to provide XBRL production services at far below the actual costs that any company would incur by brining the process in-house.
Certainly, companies need to be looking at how and when they can bring this in-house. And the key factor should be when their existing consolidation and reporting systems providers build XBRL into their processes as a standard feature. XBRL should not the catalyst for replacement of consolidation reporting systems – changes in the business, acquisitions and major process re-engineering exercises with demonstrated value through-out the internal reporting processes should be the drivers.
And in truth, bringing an 80+ hour process in-house right now does not make sense. But brining a few-hours process in-house in a year or two does.
4. Do you have the information as to what are the basic expenses for hiring an outside company as a consultant for the preparation of the XBRL? On the other hand, is it possible to assess how much effort (measured in days or money) is required to prepare the data In-House?
That’s possibly an unfair question, because I know that the pricing for XBRL production services ranges from around $6500 to well up around $30,000 plus (for the XBRL). The problem is that the price is not indicative of the value. I do warn people that the lower end of the pricing comes with all sorts of risks, and we are advising companies to ask some basic questions:
- How much work will we need to do? How much time do I really need to budget for our people?
- Do we need to learn XBRL to be able to do this?
- How much will your support (consultants, support, etc) actually cost us?
- How much time after “pencils down” do we have to budget to complete our XBRL?
The reason that it is an unfair question is because raas-XBRL does the work, clients do not need to learn XBRL, so we do not charge for additional support (because there really shouldn’t be any required beyond the agreed service) and we have minimal time after “pencils down”. Oh, and did I mention that, because of the absolutely leading edge technology and our process, we actually come in much nearer the lower end of the price-range. In fact, the average filings already with the SEC using this technology already show lower than average error rates, which has to be one of the key indicators.
5. Are you acquainted with the information of how the accounting software vendors have kept the track of the process of implementation of the XBRL? Have they supported the creation of the XBRL data within their application? Are you for or against using the “third party” software for the preparation of the XBRL data?
Well, there are at least a couple of questions there, so let me see if I can answer those. Clearly some of the vendors are building XBRL export as a natural function of their software. That’s a good thing. I fully expect to see that expand. Certainly in the UK you simply cannot be in the accounting software business without an iXBRL capability, and at least one vendor has seen some terrible press due to their failure to deliver their solution in time.
At the same time, I think the idea that a company might use XBRL as a key decision point in a software selection process to be as silly as making the ability to produce HTML as the key decision factor in selecting an accounting package. The operational needs of the business should be taken as a whole, and the most important capabilities should dictate or support the use or replace or upgrade decision, not a new reporting format that is non-core.
6. Previous years you have warned about the lack of real experts in this area. Has the number of experts increased in the USA during the first two phases of the data preparation? What happens if most companies decide to hire an outside consultant – will there be enough competent experts?
The simple answer is “No, there are not enough experts”. Absolutely not. And that it one of the biggest risks facing the 3rd year of the SEC’s program. I’ve said before and will repeat here – there are going to be a lot of ‘instant experts’ coming out of the woodwork. Google them.
Find out if the software you are offered or that your filing agent is using, has been used for actual filings. I’m coming across filing agents saying “we’ve built out own solution.” Or “yes, we have a solution that we’ve go from …. And we know them. Of course we are a bit of a beta site for them, but that makes them responsive.” I even heard one filing agent tell me that they weren’t going to be producing any calculation linkbases because “they are optional, so we’re ignoring them”. Time to check your facts.