Bob Schneider is a Partner in 
Wilson So is the Director of Hitachi Consulting Corporation XBRL: The Power of Coordinating Financial and Controls Reporting
Written by David vun Kannon Published February 27, 2007
In my previous post, I showed how XBRL could be used to document the controls framework of a business. Starting from organizational units, XBRL taxonomies were used to capture the business processes, objectives, risks, and controls in use at an entity.
This form of documentation is critical to SOX and other internal control work. In this entry, I’d like to show how to make it even more useful.
To date, I’ve avoided discussing the most common use of XBRL, financial reporting. But now is a good time to bring in the topic, because it is the coordination of financial and controls reporting that is so powerful.
A fully developed controls hierarchy for a large company would contain thousands of controls. Is it important to test all of them for SOX purposes? No, there are two important ideas that help cut down the task to manageable size.
The first idea is that some controls are key controls. The hierarchy only needs to contain these key controls. The other idea is that the testing strategy should be driven by a concept called materiality. Materiality is a test of how important something is to the financial condition of a company.
A common test of materiality is whether a number is more than 5% of sales. For example, if human resources expenses were 6% of sales at a company, they would be material by that rule. On the other hand, losses due to shrinkage of less than 4% would not be material.
The effect of this materiality rule is that we need to know the relationship between business activities and reported financial results in order to drive our controls testing. As with key controls, testing can be focused on controls over material business activities. If the business activity does not pass the chosen materiality threshold, the controls can be given a lower priority.
This is where there is a big payoff from using the same technology for the controls hierarchy and for the financial reporting hierarchy. Since both hierarchies are represented as XBRL taxonomies, it is easy to link the two together.
To do this, I’ll create a custom arc role process-financial that can be used in the definition and presentation linkbases. Adding it to the presentation linkbase lets us create special renderings based on these relationships. Here is an example:
Definition linkbase
op:Cash Operations — ( process-financial ) fin:Cash and Cash Equivalents
In contrast to the examples in my previous post, this example specifies that it is a definition linkbase, and provides namespaces for the concepts. op and fin remind the reader that these concepts are from two different taxonomies.
Because it is linking together concepts from two distinct taxonomies, this linkbase doesn’t really belong to either one. It is a standalone linkbase. It is only needed when a report joins together financial and controls data.
Keeping this linkbase separate will help avoid some problems for applications that don’t need both taxonomies. By the rules of DTS discovery, including this linkbase in the DTS will force both the financial and operational taxonomies to be brought into the DTS. That is a lot of extra baggage for an application that doesn’t need one or the other taxonomy.
But for the application that does need both taxonomies, this linkbase is just the right solution. There are several uses for this kind of linkbase beyond SOX. However, this does show that delaying investigation of XBRL because SOX is more important right now� may be missing a powerful way of addressing those very same SOX headaches.