Implementing XBRL in-house – Different strokes for different folks - Part 1 - By: morlan

The December 2008 announcement by the SEC has been cause for celebration in the XBRL community, especially among the smaller software vendors who’ve been waiting for this reporting standard to be mandated for several years now. We should see the big software vendors like IBM, SAP, Oracle, and Microsoft jockeying for position as their customers begin XBRL reporting rollouts. However, it will be some time before we see consolidation in this marketplace. Even though XBRL has been around since the late 90’s, it’s only the recent SEC mandate and to a lesser degree, the roadmap for adoption of the IFRS standard, that is fueling the current interest in XBRL reporting. In speaking with CFOs, COOs, and Accountants of both public and regulatory companies, I’m finding that there’s still confusion about where to start with an in-house XBRL implementation strategy, what the main components are, or when to jump on the bandwagon. Furthermore, the needs of public companies are different from the needs of the organizations that regulate them.

As a Technology-based Solutions Consultant advising and delivering ERP, e-commerce, and Business Intelligence (BI) solutions for large organizations over the past 20+ years, I have seen first-hand, how easy it is to try to be all things to all people. A new technology evolves, vendors emerge in the space, and although each vendor has their unique strength, they often portray themselves as having the silver bullet, rather than working in partnership with each other in order to provide the best value for the customer.

In the financial services community, prospective customers of XBRL products and services typically fall within one of two classes – 1. public or regulated corporations and 2. regulators or other organizations involved in data collection and consolidation. (Let’s leave the average investor on the sidelines for now. As their only requirement is to view company reports, they’ll have their needs met by free downloadable XBRL report viewers.)

In this first of two articles, I will focus on the implementation needs of the public or regulated company. My follow-up article will focus on the XBRL implementation needs of regulatory organizations.

For companies that have to comply with regulatory bodies, (or private companies that may also be regulated and have to provide reports in XBRL format), the technology enablers for incorporating the XBRL reporting standard into their businesses are out there among the XBRL vendors - UBMatrix, Corefiling, Fujitsu, ABZ Reporting, Rivet software, Coyote Reporting, Snappy Reports, to name a strong core.

XBRL integration is fundamentally a three-step process. Import/extend a taxonomy (a business rules data dictionary) which creates the XBRL “tags” for your reporting structure; run your data through the tagging process, making use of your taxonomy; finally, render the data in a user-readable format.

The XBRL vendors have created three automated off-the-shelf products to help you complete these steps with minimal pain:

1. Taxonomy Designer – which provides a user-friendly online interface to allow you to build, import, and extend reporting taxonomies. This is your “tagging” tool. And there are a wide range of these tagging tools out there. You can even find a free one if you know where to look. I recommend you purchase a Taxonomy Designer that has drag-and-drop capability and allows you to import and extend a base taxonomy that is downloadable from the Internet or provided to you by an associated company or regulatory body. Make sure this tool also comes with built-in taxonomy validation at both the base and extension level.

2. Processing Engine – which uses your taxonomy to essentially map the conversion of reporting data from text, CSV, Excel, HTML, XML, etc. format into XBRL. I suggest purchasing an engine that provides for two-way conversion. So starting with XBRL, you can convert back to whatever source you began with, or to another standard format. Look for an Engine with built-in data validation functionality or make sure that data validation comes bundled with your Report Builder (next step), i.e., to flag unbalanced accounts. This will save you a lot of manual effort and frustration.

3. Report Builder – allows you to render (display) XBRL “instance” documents”, or individual financial reports in a user-friendly format for the web, in PDF, or to MS Excel or Word formats, etc. Again, this requires your taxonomy as input, along with the report data, in order to render the report in a format that people can read. These report builders differ quite a bit in terms of functionality. Some provide web rendering capability only; some render in multiple formats including Word, Excel, and PDF; others provide parameter-driven comparison capability. Be clear on the functionality you need. This puts you in a position to negotiate the price of the tool you finally select.

When speaking with the XBRL vendors, categorize each one’s strengths. Some may be better on the reporting side, while others may have more feature-rich processing engines. Some products require more IT integration than others. As I evaluate these tools I also consider how user-friendly they are and who in the company is going to be working with them. For example, Taxonomy Design tools vary greatly in terms of their ease-of-use. XBRL is pretty cryptic. Finding an intuitive easy-to-use tool can make working with this XML-based language that much simpler and faster to implement, especially for end-users that don’t have an IT background.

Along with the technology components described above, you’ll also need the glue to pull the pieces together. I suggest you hire a reputable Systems Integrator or consulting firm to help you develop a roll-out plan, support you through the vendor selection process, provide integration services, training services, and help you test and deploy this new reporting standard. Many clients that I have worked with put risk minimization at or near the top of their selection list – the good integration companies have depth of knowledge in technology, have practical experience in the financial services sector, and understand reporting systems from a technical and end-user perspective – they’ll help you mitigate your risk with this new reporting standard.

In my follow-up article, I’ll continue with a discussion of the other class of XBRL consumer – regulators or other organizations that collect reporting data and have to pull it all together. Their roadmap to success is quite different than that of individual companies.

About the Author

Mark Orlan is the Director of Technology at Ntuitive Solutions a company that specializes in helping clients improve business performance through Analytics-based decision making. He has been working most recently with Deloitte Inc. on XBRL integration solutions. He can be reached at 416-572-7551. Implementing XBRL | XBRL Consultants in Toronto

Article Directory Source: http://www.articlerich.com/profile/morlan/49453

Additional Articles From - Home | Business | Risk management