consolidation and entity mapping: new xbrl solutions david vun kannon kpmg llp
TRANSCRIPT
The Internal Reporting Challenge Reporting starts at the transactional level Many non-financial measures to be reported Financial consolidation is known to be
Time consuming Error prone Not well automated Costly
Consolidation, the textbook way Algebraic addition across a worksheet
Entity 1 Entity 2 EliminationsConsolidated
Entity+ - =
Consolidation, the XBRL way Algebraic addition via calculation linkbase
Instance Document
Entity 1 Data
Entity 1 Context
Entity 2 Data
Entity 2 Context
Eliminations Data
Eliminations Context
Entity Schema
Entity 1Entity 2EliminationsE1E2ConsolidatedEntity
Entity Map (Taxonomy)
Con
E1
E2
Elim
+XBRL
Processor Consolidated DataConsolidated Context
Instance document
+
+
-
What are Entity Maps??? Using the established technology of taxonomies
Schema Linkbases
Applied to a different dimension The Entity dimension Not the Concept dimension
The Concept Dimension? Facts (items in an XBRL instance) have
Dimensions (with examples) Concept – Current Assets Entity – White Satin plc Period - 20021231 Scenario - Actual Unit – US Dollars
Attributes (with examples) Precision or Decimal - 18
Documenting a Dimension What names exist in a dimension?
Assets, Liabilities, Equity, etc.
How are they related to one another? XBRL can document multiple relationships.
How do they relate to other objects? Especially real-world objects.
Dimension Documentation in XBRL Names are defined using XML Schema files. Linkbases define
Inter-relationships Definition, calculation, presentation
Resource relationships Label, reference
XBRL 2.1 The Concept dimension is defined by the DTS
(Discoverable Taxonomy Set). Each instance document has its own construction
of the Concept dimension.
Important Point! The taxonomy (schema + linkbase) technology,
which was originally developed in XBRL to document the Concept dimension, can be used to document ANY XBRL dimension.
Using appropriate new roles and arcroles, etc.
Thank you, Walter Hamscher!
Entity Schemas As in Concept Schema, define names, IDs and
other attributes using XML Schema.
<element name=“entity1”
id=“entity1”
type=“new:entityType”
/>
xbrlDimension attribute To distinguish a schema of concept elements
from a schema of entity elements, we propose a new attribute.
<schema new:xbrlDimension=“entity” … >
Value could be concept, entity, unit, scenario, maybe even period.
NB: attribute is on the schema, not each element (could also appear on linkbaseRef…)
But entity in context is different! We need to relate these abstract entity elements
with the entity part of a context. In an instance document, the entity part of the
context uses real-world identifiers, such as DUNS number, ticker symbol, CIK.
Use a resource-type (label, reference) linkbase to make the association between abstract elements and real world identifiers.
Worked Example Next slide shows a small but complete Identity
linkbase. One abstract element is linked to two real world
identifiers D-U-N-S number CIK (Central Index Key) used by SEC.
<referenceLink xlink:type="extended" xlink:role="http://www.kpmg.com/identity">
<!-- references goes here. -->
<reference xlink:type="resource" xlink:role="http://www.kpmg.com/entity" xlink:label="DUNS">
<xbrli:entity scheme="http://www.dnb.com/D-U-N-S">
<identifier>123456789</identifier>
</xbrli:entity>
</reference>
<reference xlink:type="resource" xlink:role="http://www.kpmg.com/entity" xlink:label="CIK">
<xbrli:entity scheme="http://www.sec.gov/CIK">
<identifier>6643567</identifier>
</xbrli:entity>
</reference>
<!-- locator goes here. -->
<loc xlink:type="locator" xlink:href="WhiteSatin.xsd#parent" xlink:label="parent"/>
<!-- arc goes here. -->
<referenceArc xlink:type="arc" xlink:from="parent" xlink:to="DUNS" xlink:arcrole="http://www.kpmg.com/arc/element-identity"/>
<referenceArc xlink:type="arc" xlink:from="parent" xlink:to="CIK" xlink:arcrole="http://www.kpmg.com/arc/element-identity"/>
</referenceLink>
In Detail (1)
<referenceLink
xlink:type="extended“
xlink:role="http://www.kpmg.com/identity">
A standard XBRL reference link. A new role
http://www.kpmg.com/identity
In Detail (2)
<reference xlink:type="resource" xlink:role="http://www.kpmg.com/entity" xlink:label="DUNS">
A standard XBRL reference resource A new role
http://www.kpmg.com/entity
Bending the rules of reference resources a little bit…
In Detail (3)
<referenceArc xlink:type="arc" xlink:from="parent" xlink:to="DUNS" xlink:arcrole=
“http://www.kpmg.com/arc/element-identity”
/>
A standard XBRL reference arc A new arcrole
http://www.kpmg.com/arc/element-identity
Benefits of Identity Linkbase Enables many-to-one mapping of various real
world identifiers to a single abstract identifier. All other linkbases only need to point to the
abstract element, greatly simplifying construction and maintenance.
Some entities (such as Eliminations) may not have any real world identifier, but are still very useful for other purposes.
Created by an entity mainly for internal use.
Entity Calculation Linkbase Use CL exactly the same as CL for Concepts!
Defines which values to aggregate Relates the abstract entities to each other
Subsidiary entities have weight=“1” Correspond to real world business units
Elimination entity has weight=“-1” “Virtual” unit created to avoid double counting
Other Entity Linkbases Document various relationships that entities can
have with other entities. Legal ownership Management control Org chart
Use definition linkbase with appropriate roles and arcroles.
Presentation linkbase will also be useful. Can even cross dimensions!
Use of standard XBRL ideas Resource-type linkbases relate objects (chunks of
metadata) to abstract elements NB: Don’t try to store instance data in a resource
linkbase!
Relation-type linkbases relate abstract elements to each other.
Everything we have learned in the Concept dimension can be leveraged in the Entity dimension. And we can always learn new tricks also!
How to use the CL? We want to do more with the CL than just create
documentation. It can drive consolidation processing. But current CL processing only works on the
Concept dimension, which has a special place in the instance.
+ XBRLProcessor
XBRL 1.0 Item has several dimensions
Concept Entity Unit Period
<item type=“us:currentAssets” …>
All dimensions were represented in the same way
XBRL 2.x Item has the same dimensions BUT…
<us:currentAssets …>
The concept dimension has a special place.
One approach Reuse a Concept dimension CL processor Ensure periods are aligned.
And other sanity checks
Map entities to abstract entities. “Pivot” the instance document to exchange the
Concept and Entity dimensions. Process as previously. Pivot back to obtain the final instance document. Remap to a real world identifier.
Pivot??? 2 entities, 5 concepts = 10 facts
<my:concept1 context=“entity1” … >
Becomes
<the:entity1 context=“concept1” … >
Now 5 contexts, before there were two.
Suggestion If you don’t have a working CL processor, treat
the preceding slides as a nasty hack, rather than a preferred implementation strategy.
As a result of the pivoting (and the mapping) the document is no longer a valid XBRL 2.1 instance, but a CL processor should still be able to use it. The XBRL Infoset is still the same
The final instance IS VALID XBRL!!!
Consolidation in XBRL Incrementally extend and leverage standard
XBRL taxonomy ideas for entity maps. Use standard XBRL instance documents that
many systems will be able to export. Consolidation process is now:
Automatic Under control of metadata Much easier to document/audit!
Still to come… Creating the Eliminations entity data
Show that XBRL GL journals can be summarized into the trial balance and filtered to produce the eliminations.
Non-additive measures We need a Formula Linkbase to create these.
Still to come… If we can do…
Parent =
North
+ South
+ East
+ West
- Eliminations
Then we should be able to do
FY-03 =
FQ1
+ FQ2
+ FQ3
+ FQ4
- Adjustments
Still to come… If we can do…
Parent =
North
+ South
+ East
+ West
- Eliminations
Then we should be able to do
Variance =
Budgeted
- Actual