Bob Schneider is a Partner in 
Wilson So is the Director of Hitachi America, Ltd. What Features Should You Look For in XBRL Software?
Written by Peter Boritz Posted on July 14, 2008
Peter Boritz is the chief technology architect for Snappy Reports XBRL. In the first part of this article published last week, he offered an overview of XBRL software and general advice on what to buy. In this second and final installment, he provides a list of features to keep in mind when purchasing XBRL products.
1. A good software program should be visual and intuitive and easy to use. Although the tasks at hand may seem complex, a good software program dissects tasks down to an understandable array of accomplishments that can be completed through a step-by-step approach.
2. The software should be able to extend private and published taxonomies. A published taxonomy is most likely produced by a regulatory agency, as the US-GAAP is. Your business may create private, internal extensions to published taxonomies for specific uses. An example might be for a filing company that has many clients in the trucking business. It could create a taxonomy extension to the US-GAAP specifically for their trucking business clients. Each client could then extend the trucking business extension to the US-GAAP, as required.
3. Software should be able to create reporting period contexts and allow users to specify some basics, such as currency type (if applicable) and numeric precision. A reporting context defines (1) whose data is it (who) (2) the reporting period (when) and (3) a unit of measure, such as dollars or euros (what). The who, what, and when defines an XBRL object referred to as a context.
4. Software should be able to create reporting segments. A reporting segment provides additional information regarding a context.
5. Software should be able to extend taxonomies for new elements, labels, and references from within the program. This is very handy when the element you want does not exist and you would like to create it on the fly. A good mapping program should allow you to extend and map from the same dashboard. A good filing program should allow you to do the same. In both cases, extending an element not only refers to creation of an element, but also creating a corresponding label, and all necessary arcs and locators required to do the job.
6. Locators are more technical than users need to understand. A good program handles locators implicitly, without the need for users to know or understand what they are, or that they exist.
7. Arcs should be created indirectly through intuitive operations. Users shouldn’t have to know what an arc is or does. Users should be able to drag and drop objects into place and handle specific operations in relation to objects selected. Arcs should be created and maintained through functions users perform, not through a technical understanding of what an arc is and does.
8. Users should be visually able to see report totals, and be able to distinguish calculation arcs from dimension domain member totals. A good filing program will calculate and display totals as changes are made to the filing. Totals may take two flavors: (1) dimensional domain member totals, or (2) totals determined through calculation arcs. Real- time totals are necessary in order to quality-control your filings against your data source, such as an Excel spreadsheet or other document.
9. It should be able to create dimensional and calculation total (arcs) for newly extended elements. In many cases, when you extend for a new element, the newly created element has siblings. Those siblings have mathematical relationships that must be mirrored in the new element. For instance, if you create an extended element for construction payables, and that element is a sibling to accounts payable, construction payables must be included in all calculation arc totals that accounts payable participate in. The same is true for dimensional domain member relationships, defined in the definition link base.
10. It should be easy to drag and drop, type, or map business data into filings. Many Excel-based programs have users dragging taxonomy elements into Excel data cells. Stand-alone programs generally do the opposite. They drag data from spreadsheets or other data sources to elements in the filing. Both equally achieve the same purpose. Neither is preferable to the other.
A spreadsheet displays data the way users work. The process of dragging and dropping requires that elements be displayed side by side. The preferable format for displaying elements is in a format similar to the spreadsheet. This is not as difficult task as one may think. Software can display elements in one of many report formats. For instance, if you are working with a balance sheet or income statement in your spreadsheet, a good software program should be able to render the taxonomy as a corresponding balance sheet or income statement along side. This makes it easier to relate your data source to the taxonomy and provides excellent groundwork for maintaining quality control.
11. It should provide filtering mechanisms in order to narrow down the scope of possibilities. The US-GAAP contains over 12,000 elements. Possible flavors of filtering include:
a. Industry level filtering. The US-GAAP (March 2008) provides for filtering based on one of five industries:
• banking
• brokers and dealers
• commerce and industry
• insurance
• real estate
Most businesses would most likely fall under commerce and industry. Choosing the industry first filters out elements not specific to your industry of interest.
b. Role module (report) filtering. This allows users to visually display a reporting module within the taxonomy in presentation view (as it would be printed). For instance, if you have a balance sheet-related concept, role module filtering shows you the balance sheet and only those elements within the balance sheet.
c. Sounds-like filtering matches concepts to elements based on word pattern matches. For instance, if the concept contains the word revenue, a pattern matching filter might display all elements that also contain the word revenue.
12. Mapping and its corresponding data should be persistent. That means you load data and map once and you are done. A good program will allow you to load data once and re-use it against multiple taxonomies.
13. Mapping should provide an inventory of unmapped facts. Unmapped facts will never show up on a report, but they must be accounted for. Some facts are intentionally not mapped – for instance, if you are bringing data from your financial system or spreadsheet for total assets. If total assets is calculated within the taxonomy, mapping in a total assets value may multiply the result in some programs, others will do a comparison and generate an error if the two do not match. You must still be able to account for the fact that total assets is intentionally not mapped. There may be other data facts that are mistakenly not mapped. An audit list of mapped and unmapped data facts must be clearly displayed.
14. A good program makes the mapping process easier. You should be able to map based in relation to a report module. This means focus on mapping to the balance sheet or income statement, one at a time. You should be able to filter down to parts of the report as necessary. For instance, work with only the liabilities or payables section of the balance sheet. A good mapping program provides mechanisms to extend taxonomies by being able to create extended elements from within the mapping tool and then be able to map to those extended elements from a single dashboard.
15. Filing programs should be able to track the people who entered and made changes to the filing and the date and time of changes.
16. Reports need to be produced in human readable format. Popular possibilities include web, Excel, or Word. Other possibilities may include postscript.
17. Elements should be displayed in label view and be translatable to other languages. Language translations are built into the taxonomy. The US-GAAP is currently English only. The IFRS has translations for most languages spoken throughout Europe, including Spanish, French, and German and a host of others. You cannot expect people in foreign subsidiaries to work properly unless they can visually see elements in their native language.
18. Software should be able to map to elements relative to tuple attributes. Although tuples are not used within many taxonomies, they are still part of the specification and need to be addressed.
19. Software should ensure that abstract elements are not mapped to. Abstract elements are for organizational purposes only. They cannot be mapped to.
20. Software should ensure that published taxonomies, such as the US-GAAP, are not internally modified in any way by the program.
21. For internal reporting, be able to extend dimensional domain-members for proprietary business facts.
22. For the security conscious, only those users having logins and passwords should be able to have access to the software. Some programs allow administrators to grant and deny permissions to people for specific tasks, but not others. For instance, taxonomy developers may not have access to data or vice versa.
23. Finally, software should provide easy access to external references. Many programs display references through a pop-up tool tip that is displayed automatically as the cursor travels over a related element.