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

2. 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

3. Consolidation, the textbook way  Algebraic addition across a worksheet Entity 1Entity 2Eliminations Consolidated Entity + - =

4. 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 + + -

5. What are Entity Maps???  Using the established technology of taxonomies  Schema  Linkbases  Applied to a different dimension  The Entity dimension  Not the Concept dimension

6. 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

7. 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.

8. Dimension Documentation in XBRL  Names are defined using XML Schema files.  Linkbases define  Inter-relationships  Definition, calculation, presentation  Resource relationships  Label, reference

9. 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.

10. 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!

11. Entity Schemas  As in Concept Schema, define names, IDs and other attributes using XML Schema.  <element name=“entity1” id=“entity1” type=“new:entityType” />

12. 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…)

13. 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.

14. 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.

15. 123456789 6643567

16. 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

17. In Detail (2)  A standard XBRL reference resource  A new role  http://www.kpmg.com/entity  Bending the rules of reference resources a little bit…

18. 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

19. 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.

20. 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

21. 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!

22. 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!

23. 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

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

25. XBRL 2.x  Item has the same dimensions BUT… The concept dimension has a special place.

26. 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.

27. Pivot???  2 entities, 5 concepts = 10 facts Becomes Now 5 contexts, before there were two.

28. 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!!!

29. 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!

30. 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.

31. 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

32. Still to come…  If we can do… Parent = North +South +East +West -Eliminations  Then we should be able to do Variance = Budgeted -Actual

33. Thank you! David vun Kannon Senior Manager, KPMG LLP dvunkannon@kpmg.com