consolidation and entity mapping: new xbrl solutions david vun kannon kpmg llp

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

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

Thank you!

David vun Kannon

Senior Manager,

KPMG LLP

[email protected]

consolidation and entity mapping: new xbrl solutions david vun kannon kpmg llp

Documents

schema of entity elements

concept schema

xbrl dimension

entity mapping

entity schemasas

entity maps

linkbaserefbut entity

schema of concept elements