Consolidation and Entity Mapping: New XBRL Solutions David vun Kannon KPMG LLP

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 1Entity 2Eliminations Consolidated 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 1 Entity 2 EliminationsE1E2 ConsolidatedEntity Entity Map (Taxonomy) Con E1 E2 Elim + XBRL Processor Consolidated Data Consolidated 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  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.  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.

In Detail (1) <referenceLink xlink:type="extended“ xlink:role="  A standard XBRL reference link.  A new role 

In Detail (2)  A standard XBRL reference resource  A new role   Bending the rules of reference resources a little bit…

In Detail (3) <referenceArc xlink:type="arc" xlink:from="parent" xlink:to="DUNS" xlink:arcrole= “ />  A standard XBRL reference arc  A new arcrole 

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. + XBRL Processor

XBRL 1.0  Item has several dimensions  Concept  Entity  Unit  Period All dimensions were represented in the same way

XBRL 2.x  Item has the same dimensions BUT… 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 Becomes 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

Thank you! David vun Kannon Senior Manager, KPMG LLP