Consolidation and Entity Mapping New XBRL Solutions David

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 1 + Entity 2 - Eliminations = Consolidated Entity

Consolidation, the XBRL way § Algebraic addition via calculation linkbase Instance Document Entity Map (Taxonomy) Instance document Entity Schema Entity 1 Data Entity 1 Context Entity 2 Data Entity 2 Context + Entity 1 Entity 2 Eliminations. E 1 E 2 Consolidated. Entity Con - + Eliminations Data Eliminations Context XBRL Processor E 1 + E 2 Elim Consolidated Data Consolidated Context

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=“entity 1” id=“entity 1” type=“new: entity. Type” />

xbrl. Dimension attribute § To distinguish a schema of concept elements from a schema of entity elements, we propose a new attribute. <schema new: xbrl. Dimension=“entity” … > § Value could be concept, entity, unit, scenario, maybe even period. § NB: attribute is on the schema, not each element § (could also appear on linkbase. Ref…)

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.

<reference. Link 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="White. Satin. xsd#parent" xlink: label="parent"/> <!-- arc goes here. --> <reference. Arc xlink: type="arc" xlink: from="parent" xlink: to="DUNS" xlink: arcrole="http: //www. kpmg. com/arc/element-identity"/> <reference. Arc xlink: type="arc" xlink: from="parent" xlink: to="CIK" xlink: arcrole="http: //www. kpmg. com/arc/element-identity"/> </reference. Link>

In Detail (1) <reference. Link 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) <reference. Arc 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. + XBRL Processor

XBRL 1. 0 § Item has several dimensions § § Concept Entity Unit Period <item type=“us: current. Assets” …> All dimensions were represented in the same way

XBRL 2. x § Item has the same dimensions BUT… <us: current. Assets …> 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: concept 1 context=“entity 1” … > Becomes <the: entity 1 context=“concept 1” … > 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… § Then we should be able to do Parent = North + South + East + West Eliminations FY-03 = FQ 1 + FQ 2 + FQ 3 + FQ 4 Adjustments

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

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