Written by David vun Kannon Posted January 30, 2007
David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director for PricewaterhouseCoopers, LLP.
In my previous post on entities in XBRL, I covered a difficult issue: how to bring together data on the same entity that comes from different sources which use different naming schemes. XBRL taxonomies and linkbases were the answer. In this post, I'd like to expand on the idea of using XBRL taxonomies to represent business entities.
One of the main tasks in business reporting is to report on parts of an entity in other words, segmental reporting. The segments can be operating subsidiaries, geographic regions, or product lines. Segmental reporting is a part of external reporting to the capital markets and market regulators, and it is even more important internally to the management of a business.
In contrast to the previous issue of identity management, segmental reporting is driven by the issue of relationship management. However, it shares the same solution, namely, XBRL linkbases.
Just as we used abstract elements to represent business entities for identity management, we can extend that idea to cover segments of a business. A recent recommendation from XBRL International named XBRL Dimensional Taxonomies (XDT) provides the basic solution.
XDT is a complex specification for reporting segmental breakdowns of incredible complexity. For our purposes here, we don't need more than the basic idea of a dimension, built from a domain and domain members. A dimension can represent an entire segmental hierarchy for reporting. Several different dimensions can represent the many different hierarchies that businesses need and use regularly.
XBRL linkbases also allow the relations to vary in a hierarchy. In a common XBRL linkbase, such as the presentation linkbase or calculation linkbase, only one arc role is used to create the entire network of relations. In the presentation linkbase, this is the parent-child arc role. In the calculation linkbase, it is the summation-item arc role.
As an extensible specification, XBRL allows us to create our own arc roles for use in our taxonomies. (It also encourages users to reuse arc roles invented by other people through the Link Role Registry. Let's hold that aside for another post!) An example of that kind of custom arc role was the "identified-by" arc role shown in my previous post.
With custom arc roles, we can make the relationships of our business entities as specific as we want. For example, we can use "owns", but we can also use "majority-owns", "controls-management", "joint-venture", "investment-company-complex", or any other specific relation that meets our business modeling needs.
The tools of XDT and custom arc roles allow us to craft linkbases that connect the abstract elements which represent business entities. These linkbases are then part of the entire taxonomy of an enterprise, something that has been discussed for a long time within XBRL circles as the entity map.
An entity map is a powerful example of master data management. It resides outside of any specific application, in contrast to the consolidation hierarchies of some financial reporting tools. It can be managed and maintained as a separate unit of corporate intellectual property of value to dashboards, financial reporting and consolidation, and external reporting.
In the case of an entity map, the relations are as important as the objects they relate. That makes XBRL a good modeling choice when relationships matter.
