In my first article about implementing XBRL in-house, I focused on companies that had to comply with regulatory bodies, and the components they needed in order to implement XBRL successfully.
This article will focus on the second class of XBRL consumer - regulators or other organizations involved in data collection and consolidation. When we think of this category of user, we think of reporting needs at the macro level. This group includes stock exchanges, regulatory bodies, filing companies, accounting firms, large corporations with global subsidiaries or multi-layered organizational structures that have or manage complex financial reporting processes. The main goal for these report consumers is to have an easy way to capture, validate, review, consolidate, store, and recall the reporting data from many companies, and then be able to quickly analyze this data for compliance and risk. Their view is a more global one.
If you fall into this class of XBRL consumer, the key technology components you'll need in order to implement XBRL in-house are:
1. Secure Portal - a front-door to your reporting system. It facilitates the authenticated login of filing companies to a secure online site where they can validate and download their reports for processing, render their reports for review, and optionally have a way of comparing their results with those of their peers. If you already have such a web portal, I suggest that you assess whether you are able to retrofit it for XBRL reporting. If you can, this will help you fast-track your implementation and save money. If you have to build or buy a new web portal, this could add significantly to your time-table and cost of ownership.
2. Data Capture Engine - the method by which member companies upload data into your system. It could be 1. web-based online forms-based capture built on technology such as XForms, Active Server Pages (ASP.NET), Java, etc., that may generate XBRL or XML in the background and/or 2. batch upload of XBRL, HTML, xls, csv, txt, etc., to an FTP site. An interesting observation: the way a regulatory company approaches Data Capture sends a message to their member companies, whether intentionally or not, about their attitude towards Customer Service. It's imperative that this Customer Service aspect is taken into consideration. Typically, those organizations that provide online web capture capability are perceived to be more supportive of their member companies. Those that institute batch input alone are often viewed as being more autocratic, basically sending a message to their members: "it's up to YOU (our member company) to get the data up to us - here are the guidelines - you figure out how to do it." I always recommend giving options to your member companies.
3. Processing Engine - the "black box" responsible for mapping and converting one data format into another. It enables the input, conversion, and output of reporting data from txt, csv, xls, HTML, XML, etc. format into XBRL. And optionally supports conversion from XBRL back into any of these standard formats. Be clear on your translation needs up front. This way you won't be sold on paying for functionality that you'll never use.
4. Taxonomy and Data Validator - the Taxonomy Validator validates the syntax of taxonomies that the member companies are using. This functionality may not be required if the regulatory body enforces its own taxonomy. As for a Data Validator, some type of automated tool is suggested to flag unbalanced accounts. This will insure the integrity of the data that is being collected.
5. Data Repository - a place to store all of the data you're collecting. The repository is actually a database that can store and facilitate the retrieval of reporting data either as native XBRL instances, or through a two-way mapping process into and out of relational tables. Storage and retrieval of native XBRL instances in relational tables is still evolving. While it makes good sense, I'm not convinced it's "ready for prime-time". Don't take the vendor's word for it. You have to dig deep to really understand the pros and cons of storing data in this native format.
6. Report Builder - allows you to render XBRL instance documents, or individual financial reports, in a user-friendly format for the web, in PDF, or to MS Excel and Word formats, etc. Please refer to my recommendations in my first article. The same recommendations apply for this category of users.
7. Analysis Tools - here's where the rubber hits the road. While some of the XBRL vendors sell desktop analytical tools that work with Excel, don't be sold on an Enterprise-analytics solution yet. The major Business Intelligence and Analytics vendors have yet to deliver the real capability to help uncover trends, detect fraud, assess risk, and uncover abnormalities based on native XBRL. (I'll discuss BI and XBRL in a future article.) So for now anyway, any cross-company analytics have to be done the old-fashioned way using Data Marts or Data Warehouses loaded from relational tables.
And, for many of the same reasons discussed in the first article, you would do well to work with a Systems Integrator to help you implement this new technology and manage risk.
Please use this list as a guideline for the most common components needed. Keep in mind that there is great diversity amongst public companies and regulatory bodies, so requirements will vary across the board.
As an example of unique requirements, I'm currently working on a proposal with a regulatory organization that has over 200 member companies that have to submit quarterly, monthly, and annual financial statements. All member companies are required to submit the same standard information, to a greater or lesser extent. The member companies currently file their reports by manually keying their entries into an online form provided by the regulator, and they also are given the option for batch submission. The regulatory company currently has a Report Writer application that is parameter-driven and allows peer group comparisons. Furthermore, the regulator also has a Data Dictionary that they've invested heavily in which is maintained by their small in-house staff. The Data Dictionary already supports many of the same business and formatting rules that XBRL would support. The regulatory organization now wants to make the move to XBRL and has asked for guidance.
What components of their current infrastructure do we recommend they keep? Which components should they replace? You have to consider organizational culture, technological sophistication, staffing, the learning curve of the member companies, etc. You want to add value through the introduction of XBRL, but you also want to do what's best for the client, especially if they want to keep a lot of their infrastructure intact. The point is, they have, as you will, their own set of unique requirements for implementing XBRL. Determining and honoring your specific XBRL requirements is key to a successful implementation.
So, as you consider implementing XBRL for your own organizations, you really have to balance practicality with the maturity of the solutions in this space. The scope of XBRL solution functionality is still evolving. As I noted earlier, analytical reporting and Business Intelligence still has a ways to go. But I can tell you first-hand, the big BI vendors are just chomping at the bit to break out with an elegant, high-performance solution in this XBRL space. Until then, take it one step at a time, and don't be afraid to mix and match the best components from the various XBRL vendor solution portfolios.
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. XBRL Implementation | XBRL Toronto [http://www.ntuitive.com/XBRL-services.html]
Author: Mark Orlan
Article Source: EzineArticles.com
Provided by: Guest blogger