XBRLrepresents one of those instances where the use of an XML dialect is driven by an undeniable mandate. Initiated in the late '90s to bring XML to accountancy issues, XBRL has now arrived in a rush for public
companies as the Securities and Exchange Commission (SEC) mandates XBRL compliance. Other financial organizations may have to follow soon, and they will learn about XML tools they never thought of before. Contributor Alan Earls spoke with Gary Purnhagen, director of compliance services at BusinessWire.com and a self-described XBRL evangelist. He offers context and advice for those that need to embrace XBRL.
SearchSOA: What challenges do people face in trying to implement XBRL and to succeed at XBRL taggings and mappings?
Gary Purnhagen: It is a complicated language. It requires a real understanding of accounting.
Why is that the case?
Purnhagen: With something as simple as the cost of goods sold, there are any number of variations of accounting concepts. Knowing the accounting concepts behind the reports is important in the mapping process, which is still pretty much a manual thing. There are a few software developers attempting to automate the mapping. But, finding the right tag is complicated, too. It seems to take an accountant to do this. At Businesswire we decided no one knows a company’s financials better than their accountants. So we do need accounting people involved. We try to work cooperatively with them. You can’t find XBRL people on the street – it is very rare – so you must train them.
Also, the software that is available is not all that strong; it still requires a lot of manual intervention.
If you look at the market today, roughly 80 percent of public companies are outsourcing this work.
Some are shipping this mapping process overseas and then there is often a real disconnect between the company’s knowledge of this and the person actually selecting the tags. So the quality of the data is of concern. Not only are there technical errors in filing but no one is looking at how accurately a company’s financial well being is reflected in the new format. Unfortunately, with companies phasing in this year, a percentage don’t really understand or appreciate this, they are just going for the lowest cost provider which almost guarantees that their financial statement will not be accurate.
What advice do you have for an application developer or integration manager starting down the path to XBRL?
Purnhagen: A technical person on their own needs to partner closely with the accounting people. What I find is that the vast majority of those who are tasked with this responsibility are not technical people, rather it is the financial reporting folks. There is also a taxonomy and specification available. All of that is in the public domain.
Are there tools available?
Purnhagen: They are pretty much in their infancy. There are some open source XML tools that can be applied to some extent. Tools can address this through three categories.
First, there is mapping. Working with the US Generally Accepted Accounting Principles (GAAP) taxonomy and financial statements and figuring out which tools are best can help but you could also go to the XBRL website and actually map your financials based on that.
The second is ensuring validation, in other words making sure that all the calculations are correct and ensuring that all the technical procedures are followed. Typically that can’t be done manually, you need a validation tool.
The third is tagging. This means taking the items you have created and associating them with updated numbers. For now, there are just six different files that have to be submitted to the SEC. The early software developers in this area tried to create a general tool. No one did it well. Some are strong on mapping and not other things.
We use a variety of tools here. It would usually not be cost effective for an individual company. We find about 20 percent of the companies are doing this internally; some new emerging tools are coming on the market that are related to either workflow or document building or financial consolidation. But they are still immature.
I’m sure I’m prejudiced but I think it makes sense of a company to outsource this process for the first two years. That is the overall ramp up period. The SEC mandate is still evolving. They already had several interpretive guidance releases over the last year. I would like to think that in two years the software will be in better shape to help this and at that point you can move from provider to in-house.
What new developments are on the horizon for XBRL?
Purnhagen: After June 15, all companies [required to report] will need to respond. Many companies have yet to address this at all. This takes a lot of time and preparation and, of course, they are responsible for their financial information. I think there will be great opportunities down the road. I think in the next six to eight years any software package involved with business information will need to be able to work with XBRL.
Eventually we will even tag narrative information so we can start to search it more effectively. Hopefully, there will be creativity in terms of looking at this as opposed to just looking back at paper as the model. Then we will see documents in a new light. XBRL is all about finding information more efficiently.
This was first published in March 2011