In my first article about implementing XBRL in-house, I focused on panies that had to ply with regulatory bodies, and the ponents they needed in order to implement XBRL suessfully.

This article will focus on the send class of XBRL nsumer - regulators or other anizations involved in data llection and nsolidation. 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 panies, aounting firms, large rporations with global subsidiaries or multi-layered anizational structures that have or manage plex financial reporting processes. The main goal for these report nsumers is to have an easy way to capture, validate, review, nsolidate, store, and recall the reporting data from many panies, and then be able to quickly analyze this data for pliance and risk. Their view is a more global one.

If you fall into this class of XBRL nsumer, the key technology ponents 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 panies to a secure online where they can validate and download their reports for processing, render their reports for review, and optionally have a way of paring 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 uld add significantly to your time-table and st of ownership.

2. Data Capture Engine – the method by which member panies upload data into your system. It uld be 1. web-based online forms-based capture built on technology such as XForms, Active Server Pages (), 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 . An interesting observation: the way a regulatory pany approaches Data Capture sends a message to their member panies, whether intentionally or not, about their attitude towards Customer Service. It’s imperative that this Customer Service aspect is taken into nsideration. Typically, those anizations that provide online web capture capability are perceived to be more supportive of their member panies. 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 pany) to get the data up to us – here are the guidelines – you figure out how to do it.” I always remend giving options to your member panies.

3. Processing Engine – the “black box” responsible for mapping and nverting one data format into another. It enables the input, nversion, and output of reporting data from txt, csv, xls, HTML, XML, etc. format into XBRL. And optionally supports nversion 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 panies 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 aounts. This will insure the integrity of the data that is being llected.

5. Data Repository – a place to store all of the data you’re llecting. 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 nvinced 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 ns 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 remendations in my first article. The same remendations apply for this category of users.

7. Analysis Tools – here’s where the rubber hits the road. While some of the XBRL vendors sell desk 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 unver trends, detect fraud, assess risk, and unver abnormalities based on native XBRL. (I’ll discuss BI and XBRL in a future article.) So for now anyway, any cross-pany 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 mon ponents needed. Keep in mind that there is great diversity amongst public panies 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 anization that has over 200 member panies that have to submit quarterly, monthly, and annual financial statements. All member panies are required to submit the same standard information, to a greater or lesser extent. The member panies 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 pany currently has a Report Writer application that is parameter-driven and allows peer group parisons. 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 anization now wants to make the move to XBRL and has asked for guidance. What ponents of their current infrastructure do we remend they keep? Which ponents should they replace? You have to nsider anizational culture, technological sophistication, staffing, the learning curve of the member panies, 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 suessful implementation.

So, as you nsider implementing XBRL for your own anizations, you really have to balance practicality with the maturity of the solutions in this space. The spe 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 ponents from the various XBRL vendor solution portfolios.