Written by Peter Boritz     Posted on July 7, 2008

Peter Boritz is the chief technology architect for Snappy Reports XBRL. In this first post of a two-part article, he offers an overview of XBRL software and advice on what to buy. The second part describing features to look for in XBRL products will be published next week.

Looking for XBRL software can be a perplexing task. Understanding XBRL and the many requirements necessary for you to run your business can be challenging, and software features can vary greatly among vendors. So how do you determine which is the right XBRL software for your business?  Some initial questions to ask include:

• What are the goals and objectives of your XBRL implementation?
• Where is your XBRL data coming from? How will you be delivering and processing it?
• What security issues do you have? How will you dissect and distribute tasks and privileges to authorized users?

Minimally, any program needs to be able to create instance documents and extensions in XBRL format. This is the end result of our labors.

Uses for XBRL generally fall into one of two categories: external reporting for regulatory compliance, or internal reporting for data consolidation and reporting.

External Reporting
External reporting applies to regulatory compliance with government agencies. An agency publishes a taxonomy that functions as the basis of the reporting. For the Securities and Exchange Commission in the United States, that taxonomy is either the US-GAAP or the ICI Risk Return.

Specific reports are built into taxonomies. These may include the basics, such as balance sheet and income statement, and may span out to a wide range of other items, depending on the nature of the information desired to be collected. Reports may collect a combination of numerical financial information, as well as text-based disclosures.

A good XBRL implementation allows users to work with taxonomies on a report-by-report basis. This means you might see the balance sheet in human readable format, and work with just the balance sheet or income statement as circumstance requires. The US-GAAP incorporates over 12,000 elements. To work without having at least a report display and filtering mechanism makes the process confusing and tedious. Being able to filter through taxonomies is imperative for any software product you choose. Better programs allow you to filter through specific sections of reports, such as just the payables portion of the balance sheet.

If you are entering numerical data into a filing, a good implementation displays totals in real time as data is entered. These totals can then be compared to the spreadsheet or other data source being used as the basis of the filing. When you see totals in the filing equal to that of your source document, you at least reasonably know that all values have been accounted for.

Internal Reporting
XBRL provides a very powerful process for data consolidation and reporting. Company policies and procedures can be expressed through one or more taxonomies that define business data and the relationships of the data from which the organization operates.

The problem of businesses operating through personal spreadsheets used privately by employees becomes a thing of the past. All business data can be consolidated and distributed to those authorized from a common repository design, based on business concepts expressed through one or more taxonomies.

Architectural Configurations of XBRL Software
XBRL software generally falls into one of two architectural categories.

1. Excel spreadsheet add-ons are accessible from within Excel. Many professionals using Excel in their jobs feel comfortable using software that supplements Excel features. The advantages of an XBRL ad-on are familiarity and ease of use.

Since this architecture is dependent on Excel to operate, Excel add-on programs are limited by the scope of Excel’s capabilities. Excel interface programs are single user programs, as Excel is. Data sharing is limited to distributing spreadsheets from desk to desk. They work well for single proprietor businesses or in cases where filings are handled by one person and one person only.

2. Standalone XBRL programs are designed specifically for XBRL. They are limited only by the functionality offered.

Key differences are how or if data is shared among users.

a. Single user standalone programs Single user programs are designed for single practitioners and companies having a one-person external reporting manager.
b. Enterprise programs  Enterprise programs allow for the exchange of ideas throughout the business. This includes business data, taxonomies, and extensions. Enterprise programs may take the form or either multi-user single database applications, or distributed databases accessed through an internet or network protocol.
c. Networked programs Networked programs are designed for a wider scope of development where users need to be able to access multiple independent databases and projects. This is distinguished from enterprise in that each project/database is independent of each other and each has its own access security, personality, and protocols.

Data Integration
Integration is the process of bringing data from your spreadsheets and financial systems into XBRL. At a minimum, software should be able to process spreadsheets, since spreadsheets are an integral part of any accounting professional’s toolkit. A good software product should also be able to import data from most business systems. Methods for importation of data can vary from product to product. Some products allow data to be imported once, and then re-used for multiple applications of the data. Others require a data import for each application, even if the data being imported is the same.

Seamless and Disparate Solutions
Software architecture can vary greatly. Some software products implement a seamless solution using a common data repository. This allows users to set up connections to enter content and others to retrieve and process data. Other systems are unable to do this. They may rely on third-party products to transform and transmit instance documents, and then re-transform them at the other end. For most applications, a seamless solution is preferable. Software that does not implement a common data repository or is lacking in taxonomy/data connectivity between servers must generally transform and re-transform instance documents as a substitute.

Add to Del.icio.us | Digg this

This entry was posted on Monday, July 7th, 2008 at 3:20 pm and is filed under General, . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.