Comparison Framework for EDINET, IFRS, and US GAAP XBRL Taxonomies 0.05

Public Working Draft 31 March 2009

Copyright ©2009 XBRL International Inc., All Rights Reserved.

This version:

<http://www.xbrl.org/Specification/TCF/PWD-2009-03-31/TCF-PWD-2009-03-31.html>

Editor:

Maciej Piechocki, IASC Foundation <mpiechocki@iasb.org>

Contributors:

Campbell Pryde, XBRL-US <campbell.pryde@xbrl.us>

Holger Obst, IASC Foundation <hobst@iasb.org.uk>

Atsushi Takeda, Japan Financial Services Agency <atsushi.takeda@fsa.go.jp>

Masazumi Takahara, Fujitsu Research Institute <mtakahara@jp.fujitsu.com>

Masatomo Goto, Fujitsu Laboratory of America <mg@jp.fujitsu.com>

Hiroaki Sakakibara, Fujitsu Limited <sakakibara@jp.fujitsu.com>

Makoto Koizumi, Fujitsu Research Institute <koizumi.makoto@jp.fujitsu.com>

Jim Richards, JDR and Associates <jdrassoc@iinet.net.au>


Status

Circulation of this Public Working Draft is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to tcf-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This Request for Comment (RFC) describes practices that should be considered when developing XBRL taxonomies and specifically when deciding on the design choices for XBRL taxonomy architecture offered by XBRL specifications. Traditionally XBRL taxonomies satisfied the XBRL 2.1 specifications [XBRL 2.1] and later the XBRL Dimensions 1.0 specification [DIMENSIONS]. As experience and knowledge in XBRL taxonomy development has grown, so has the emergence of different taxonomy architectures around the world. While being a reassuring sign that XBRL adoption is on the rise, this diversity of XBRL taxonomy architectures may result in interoperability issues between XBRL implementations.

Existing XBRL specifications offer a variety of ways to achieve similar, though not identical, objectives in regards to the architecture of XBRL taxonomies. The Financial Reporting Taxonomies Architecture (FRTA) 1.0 [FRTA] was one of the first attempts to align the possibilities offered by XBRL specifications, and it still remains a benchmark for a number of financial reporting taxonomies worldwide. Since the publication of the FRTA 1.0 in April 2005 more practical experience has been gained, particularly in the area of XBRL Dimensions 1.0. This requires updating existing best practices for XBRL taxonomy architecture or establishing new best practices.

This RFC identifies and analyses the similarities and differences between existing XBRL taxonomy architectures and solicits input from interested parties who have relevant experience to bring to bear. This RFC will be the basis for subsequently establishing best practices for the architecture of XBRL taxonomies.

Table of Contents

1 Goal
2 Executive Summary
2.1 TCF Sections
2.2 Comparison Criteria
2.3 Alignment Documentation
3 High Impact Areas - EDINET, IFRS, US GAAP Comparison
3.1 Project Information
3.2 Technical Alignment
3.3 Domain Alignment
3.4 Extensions and Instances Guidelines

Appendices

A References
B Intellectual property status (non-normative)
C Acknowledgements (non-normative)
D Document history (non-normative)
E Errata corrections in this document

Tables

1 Taxonomy Project Information, High Impact Criteria


2 Technical Alignment, High Impact Criteria
3 Domain Alignment, High Impact Criteria
4 Extensions & Instance Alignment, High Impact Criteria

1 Goal

The goal of this RFC is to identify the design decisions made in architectures of XBRL taxonomies worldwide. This RFC introduces a comprehensive comparison framework for three XBRL taxonomies (IFRS, EDINET and US GAAP) and their architectures. It will provide other taxonomy developers with information of the issues and choices available to them when developing their taxonomies.

2 Executive Summary

The effort to provide a comprehensive comparison framework is a deliverable of the Interoperable Taxonomy Architecture project (ITA). The ITA is a joint initiative between the US SEC, the Japan FSA, the European Commission and the IASC Foundation XBRL team, and aims to converge the XBRL architectures of three taxonomies: EDINET, IFRS and US GAAP. In the project's first stage, the three respective taxonomy developers agreed to develop a comprehensive framework which would provide a basis for comparison of the three taxonomy architectures. The result was the Taxonomy Comparison Framework (TCF). The ITA project assumed a scope of analysis limited to financial reporting in capital markets. Although XBRL taxonomies are often used in other reporting scenarios (for example bank regulation, statistical reporting or tax reporting) such usage of XBRL taxonomies was out of scope of the ITA and thus is not analysed in the TCF.

2.1 TCF Sections

The TCF consists of four different sections: Taxonomy Project Information, Technical Alignment, Domain Alignment and Extensions and Instance Guidelines Alignment:

  • The Taxonomy Project Information section provides general information on each taxonomy project.
  • The Technical Alignment section provides comparisons of the three taxonomy architectures.
  • The Domain Alignment section addresses non-technical aspects of taxonomy modelling and design.
  • The Extensions and Instance Guidelines Alignment section compares guidelines for the preparation of entity specific extensions and instance documents.

A comprehensive set of criteria is defined and structured for each section. For example, the Taxonomy Alignment section categorises comparison criteria into physical definition, taxonomy design pattern, taxonomy modelling, schema, linkbases, presentation linkbase, calculation linkbase, definition linkbase, label linkbase, reference linkbase, dimensions, and the use of new XBRL specifications.

2.2 Comparison Criteria

Within each broader category, a set of specific comparison criteria are provided and each taxonomy is described according to each criterion. For example, for the criterion "custom datatypes" (4-2) in the Technical Alignment section the IFRS and EDINET taxonomies are not defined, while the US GAAP taxonomy refers to specific datatypes defined for the use in this taxonomy.

2.3 Alignment Documentation

Each TCF provides an impact level of each criterion (none, low, medium and high impact). The impact level represents a consensus amongst the ITA project. There are also comments for the decided impact level, current status (aligned, not aligned, not used) and priority for actions (low, medium and high priority). For each criterion a placeholder for action points is provided. While impact level, current status and priority for actions are useful descriptors for the ITA project partners, they do not necessarily reflect the individual viewpoints of individual taxonomy developers.

This RFC only contains the criteria that have been assessed to have a high impact level. The complete framework, fully populated with information about each criterion for a set of taxonomies, is published as a spreadsheet due to its size. Publishing in that format makes it more useful as a reference data set. For further details, refer to the entire data set found at:  Taxonomy Comparison Spreadsheet

3 High Impact Areas - EDINET, IFRS, US GAAP Comparison

This section only summarizes a few of the important results from comparison of the EDINET, IFRS and US GAAP taxonomy projects.

3.1 Project Information

Taxonomy projects differ as to the expectation of whether extensions are expected and what the source of those extensions will be. This has a high impact on the design of the taxonomy.

Table 1: Taxonomy Project Information, High Impact Criteria

#

Criterion

IFRS

US GAAP

EDINET

1-1

XBRL specifications at last release

XBRL 2.1, XBRL Dimensions 1.0

XBRL 2.1, XBRL Dimensions 1.0

XBRL 2.1

1-2

Access to the taxonomy

Public

Public

public

1-11

Quality assurance process, check rules & QA criteria

Tests incorporated in the development process, XQRT review and public review, tests with all availabe tools.

Over 200 tests run across all statements and disclosures on each incremental build.

design is in progress

3-3

Character of taxonomy extensions

Used as core taxonomy (extenders) as well as reporting taxonomy (preparers).

Internal industry taxonomies (maintained by US SEC) and company specific extensions. An extensive "Preparers Guide" (PG) focuses on the creation of reusable extensions.

Internal 23 industry extensions (maintained by JFSA) and company specific extensions. External extensions done by NTA and TSE are expected.

5-3

Strategy for immediate release

In progress

Final release on 28 April 2008, with a new release of the taxonomy on January 31st of every year.

Design is in progress

3.2 Technical Alignment

Although there are several technical differences that have an impact on the interoperability of taxonomies, whether the Dimensions specification is used, and the details of how it is used, has high impact.

Table 2: Technical Alignment, High Impact Criteria

#

Criterion

IFRS

US GAAP

EDINET

3-1

Usage of tuples

No tuples used, modelled using one string document or as an intersection table

No tuples; Tables (hypercubes) are highly constrained by style rules.

No tuples adopted

3-2

Intersection tables

20+ tables modelled by the means single element per cell (all movemenets and reconciliations tables).

Use Dimension Tables

Single element for each cell (Statement of Change in Net Assets)

3-3

Dimensional patterns

Used for segment/scenario oriented use cases.

Strongly determined by style guide rules and transformations from the presentation view. Hypercubes are Tables, Dimensions are Axes, each Axis has one Domain child and that domain child has any number of Domain Members.

N/A

5-1

Custom arcroles

No custom arcroles

We have added arcroles for deprecated items in the definition linkbase. Item - Deprecated

5 custom arcroles: - Special - General - Gross - Net - Gross - Allowance - Gross - AccumulatedDepreciation - Gross - AccumulatedImpairmentLoss - Gross AccumulatedDepreciationAndImpairmentLoss

8-1

Characteristics of definition linkbase

The IFRS taxonomy uses definition linkbase to express dimensional relationships. The "traditional" arcroles for definition linkbase are not used.

There is one definition linkbase common to all GAAP statements, one common to all GAAP disclosures and schedules. The only relationships there are dimensional.

The EDINET taxonomy uses definition linkbase to describe relationship of all elements including: - Special - General - Gross - Net

8-2

Usage of definition linkbase for dimensions

Yes

Yes

No

8-3

Usage of definition linkbase for non-dimensions

No

No - But plan to implement in the future.

Yes. The EDINET taxonomy uses definition linkbase to describe relationship of all accounting elements

8-6

Custom role / arcroles in definition linkbase

None custom arcroles

None on the published taxonomy. But will define in future. Currently have arc roles for elements industry relationships in the development taxonomy. These are used to generate the taxonomies by industry.

There are 5 custom arcroles for Definition Linkbase: - Special - General - Gross - Net - Gross - Allowance - Gross - AccumulatedDepreciation - Gross - AccumulatedImpairmentLoss - Gross AccumulatedDepreciationAndImpairmentLoss

11-1

Characteristics of Dimensions

The IFRS Taxonomy uses a definition linkbase to express dimensional relationships. The modelling of axis information with dimensions is introduced in cases where the information clearly belongs to a context (can be either classified as a part of scenario or segment). The IFRS Taxonomy defines dimensions and domain members for listed relationships, thus using only explicit dimensions. The IFRS Taxonomy does not define hypercubes.

There are about 200 tables (hypercubes). Dimension is not "New", by the way.

No dimensions are implemented in the EDINET taxonomy so far.

11-3

Dimensional contexts container (segment/scenario)

Scenario

Segments

No dimensions are implemented in the EDINET taxonomy so far.

12-2

Versioning

The IFRS taxonomy uses the versioning solution as defined by the Versioning Working Group. The versioning solution is not part of the official taxonomy release but is additional information for each taxonomy release. The versioning solution contains information about the differences between two taxonomy releases enhanced with the versioning information about arts of changes. Currently html change log is in use.

We are committed to using the specification when finalized. Currently, the format is simple .csv change lists.

Versioning solution is really important for continuous taxonomy development. Thus, at current stage, JFSA provide comments for Versioning specification which is developed by XII.

12-3

Rendering

The IFRS taxonomy addresses rendering of taxonomy structures (particularly changes tables) with the use of two parallel presentation linkbases.

Not mandated, but the Architecture document clearly indicates that the preferred format for filings will eventually be Inline XBRL (called Mixed XBRL in the document). The PG contains rules of thumb for making text blocks readable using current generation SEC rendering tools.

Proprietary rendering technology is implemented in EDINET system. The concepts of this technology are: - Contain required information for rendering such as relationship among extended linkrole, context and raw number into instance document based on Document Information Taxonomy -Additional parameters such as raw label are set into the proprietary xml file.

3.3 Domain Alignment

At this time there are believed to be no domain related criteria with a high impact on the architecture.

Table 3: Domain Alignment, High Impact Criteria

#

Criterion

IFRS

US GAAP

EDINET

3.4 Extensions and Instances Guidelines

As noted earlier, expectations about the source and nature of taxonomy extensions have a variety of impacts on the details of the taxonomy.

Table 4: Extensions & Instance Alignment, High Impact Criteria

#

Criterion

IFRS

US GAAP

EDINET

1-1-1

Rules for taxonomy extensions

Rules stated in the IFRS Taxonomy Guide (Preparers Guide chapter).

Yes Stated in Preparers Guide

There are rules and guideline for corporate extension taxonomy development. These rules and guidelines are benchmarked and were revised as a result of the public comment phase and the 2nd pilot project.

1-1-8

Creating multiple financial document from single issuer at the same time (e.g. series fund, guaranter...)

Not explicitly addressed.

One statement can contain as many funds as desired, each with its own member along a series and class axis.

Issuer prepares instance document for each individual fund.

2-1-1

FRTA compliance

FRTA waivers are documented. Entities may use FRTA for quality checks but it is not required.

Five waivers are documented, all of which have been reported as FRTA bugs.

-Extension taxonomy must be FRTA compliant with some exceptions -All 'AUTO' FRTA validations are done by EDINET system right before submission. -Issuer gets results of AUTO validations whether EDINET detects a FRTA violation or not

2-2-2

Naming convention

id my_entity_role-XXXXXX roleURI http://www.my_entity.com/role/XXXXXX definition [XXXXXX] Name of the statement or Notes | Dimension – Name of the note or name of the dimension

PG directs a naming convention in which the URI is derived from the taxonomy URI and its description is of the form "000000 - Statement - Statement of Income"

These are described in the "Framework Design Guide"

2-4-2

Rules for adding ELR

Three approaches (clean, reuse and mixed).

No restrictions. They are encouraged in the PG.

There are rules and guidelines are there: -adding new extended link role is prohibited

2-9-1

Rules for including dimension in extended taxonomy

New dimensions may be added.

PG rules and rules of thumb guide you to use these appropriately. Typed members shall not be used in extension taxonomies.

n/a

3-1-2

Rules for instance documents

IFRS Taxonomy Guide (Preparers Guide chapter).

PG identifies a number of Rules.

There are rules and guidelines for instance document creation. These rules and guidelines are benchmarked and have been revised as a result of the public comment phase and the 2nd pilot project.

3-2-1

FRIS compliance (overview)

Not addressed.

PG rules have the effect of enforcing various FRIS rules

-Instance document must be FRIS compliant with some exceptions -All 'AUTO' FRIS validations are done by EDINET system right before submission. -Issuer gets results of AUTO validations weather EDINET detects a FRIS violation or not

3-5-1

Precision/decimal for different scales

Rounded to thousands -3 Rounded to millions -6 Rounded to two decimal places 2 Exact numbers INF

decimal="-6" for millions; decimal="-3" for thousands, but the content of the element is of course the full number with all necessary zeroes.

Set "decimal=-6" to describe "in millions" and "decimal=-3" to describe "in thousands"

3-6-5

Usage of custom arcroles

Not used.

Will be used for disclosure of material and non material items

http://info.edinet-fsa.go.jp/jp/fr/gaap/role/: - NotesNumber - NumberPeriodStart - NumberPeriodEnd

3-7-1

Rules for creating instance document with dimension

According to XDT.

PG guides users to extend using only minimal changes in preference to others. There is a sequence of more invasive extensions including the selection of domain members, addition of domain members, addition of axes, addition of tables.

n/a

Appendix A References

DIMENSIONS

XBRL International Inc.. "XBRL Dimensions 1.0"
Ignacio Hernández-Ros, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm)

FRTA

XBRL International Inc.. "Financial Reporting Taxonomies Architecture 1.0 Recommendation dated 2005-04-25 with Corrected Errata 2006-03-20 "
Walter Hamscher, Mark Goodhand, Charles Hoffman, Brad Homer, Josef Macdonald, Geoff Shuetrim, and Hugh Wallis.
(See http://www.xbrl.org/technical/guidance/FRTA-RECOMMENDATION-2005-04-25+corrected-errata-2006-03-20.rtf)

XBRL 2.1

XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2008-07-02"
Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2008-07-02.htm)

Appendix B Intellectual property status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

Appendix C Acknowledgements (non-normative)

This document could not have been written without the contributions of many people including the participants in the Taxonomy Architecture Working Group.

Appendix D Document history (non-normative)

Date

Author

Details

20 February 2009

Maciej Piechocki

Providing executive summary for the Taxonomy Comparison Framework as a first rough draft.

23 February 2009

Maciej Piechocki

Adding explanation for capital market reporting context of the ITA and improving the wording.

01 March 2009

Made specific reference to XBRL taxonomies rather than general taxonomies. Changed working group to Taxonomy Architecture working group. Added extracts of high impact areas. Grammar and style edits.

14 March 2009

Change title, correct typos.

18 March 2009

Makoto Koizumi

Change contributors.

28 March 2009

Jim Richards

Grammatical changes and some formatting.

20 April 2009

Maciej Piechocki

Adding link to the spreadsheet and changing status to PDWD.

Appendix E Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Taxonomy Architecture Working Group up to and including 31 March 2009. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.