Comparability Business Requirements 1.0
Public Working Draft

2012-08-15

Status

This document is property of XBRL.

This report has the status of a Public Working Draft. As such it is not restricted to XII members.

Revision History

Revision	Date	Description	Author
0.6	2012-05-29	Updates from first round of feedback	Rita Ogun-clijmans. IFRS Herm Fischer And others
0.5	2012-04-10	A) With updates from first round of view - BPB conversation 2012-04-03 B) More clearly show that a comparison can run against multiple pools	Jordan Woodard Greg Soulsby
0.4	2012-03-30	First draft for review outside core team of three. Not for general distribution. Includes feedback from Jason Price.	Ray Lam Jordan Woodard Greg Soulsby
0.3	2012-01-31	Use Case and business rule updates following "final push"	Ray Lam Jordan Woodard Greg Soulsby
0.2	2011-12-05	Use Cases updated	Comparability Task Force
0.1	2011-11-12	Initial draft - composite of working documents to date	Comparability Task Force

1. Introduction

1.1. Purpose

Comparability enables XBRL instance documents, even from different taxonomies, to be compared and consumed.

This document is a tool for defining comparability requirements in detail, from a business point of view.

1.2. Scope

This report is the core deliverable from phase one of the comparability standard development. Formal business requirements are the most important content. Supporting these are detailed Use Cases and an abstract model.

Phase two is where the actual standard will be written. This document is a major input to that phase. References to technical issues in this document are abstract, not being intended to be prescriptive for following technical or standards deliverables.

1.3. Overview

The sections of this document are:
1) Executive Summary
2) Use cases: Typical use cases where comparability is required
3) Business requirements: Derived from the Use Cases
5) Appendix:

Abstract Domain model: Concepts, attributes, business rules and their relationships
Working Use Cases: from initial work exploring the Use Cases

Comparability language: How an end user may express a comparison. Includes examples of comparison result.

1.4. Outstanding issues:

Completion of the abstract model, first priority the definitions of concepts, like "pool".
Fill out the stakeholder map.

1.5. Stakeholder map

There are many existing threads within XBRL that relate to Comparability. The external standards and technology world also has many relevant projects and stakeholders. The greater the level of integration, compatibility and re-use the more effective and efficient Comparability can be both from the end users point of view and the standard development process.

Party	Relationship	Contact point
XBRL Function standard
XBRL GL standard	The GI will be a common taxonomy for assertion writers to use as it holds detailed information about an enterprise.
OMG	They have a number of existing standards which must be leveraged by XBRL Conformance.
Vendors	Their technology must implement the standard.
Power users		IFRS? Global Banks

2. Use Cases

This section describes the Use Cases developed by the team.

Note that the Use Case numbers are consistent between the diagrams

1000 Series for Instance document writing
2000 Series for pooling of instance documents
3000 Series for Assertion writing
4000 Series for Comparisons

These numbers are used within the Business Requirements section for cross referencing.

2.1. 01 Basic Comparison Use Case

Figure 1 - 01 Basic Comparison diagram

2.1.1. Report XBRL Instance

Use Case Name:	Report XBRL Instance		ID:	1000
Primary Actor:	· Reporting Officer
Goal:	[G010] To report company business information in XBRL format.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] XBRL taxonomy must exist. [PRE020] Company business information is prepared for reporting.
Post Condition:	[POST010]Existing XBRL Instance document is published.
Scenarios
Basic Flow of Events:		[BFE010] Reporting officer gathers and prepares company’s business information. [BFE025] Reporting officer maps company’s business information to elements (i.e. concepts) in the XBRL taxonomy. [BFE030] Reporting officer generates XBRL Instance document. [BFE040] Company approves the XBRL Instance document for publication. [BFE020] Reporting officer selects XBRL taxonomy to present company’s business information.
Alternative Flow of Events:		[AFE010] Reporting officer concludes that the chosen XBRL taxonomy is insufficient to meet the needs of the company and thus chooses to extend the taxonomy. [AFE020] Reporting officer generates XBRL extensions to the base taxonomy. [AFE040] Company approves the company-specific extensions for publication. [AFE030] Reporting officer defines, documents, and inserts company-specific extensions into the chosen XBRL taxonomy.
Exceptional Flow of Events:		[EFE010]Reporting officer needs to use more than one XBRL taxonomy to report company business information. For example: local (based on local GAAP) and consolidated accounts (based on IFRS) are published into a single in-line XBRL report. Consumer will use the in-line XBRL report rather than pooling the XBRL instance document. .

2.1.2. Write Basic Assertion

Use Case Name:	Write Basic Assertion		ID:	3000
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertions which state comparability between component of XBRL instance documents.
Assumption:	[A010] The Assertion provider is a reputable domain expert whose Assertions will carry authority in the respective domain for which they are providing Assertions.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider must be able to state authorship of the Assertion so that Consumers are able to verify the author.
Notes:
Narrative
Pre Condition:	[PRE010] XBRL instance documents are available. [PRE020] XBRL taxonomies are available.
Post Condition:	[POST010] Assertions are created and available to be applied in comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE050] The Assertion Provider releases / publishes the assertions for consumption. [BFE020] The Assertion Provider identifies gaps in comparability which can be closed through the provision of Assertions. [BFE030] The Assertion Provider uses the Comparability Specification to create the Assertions. [BFE040] The Assertion Provider tests the Assertions. [BFE010] The Assertion Provider analyzes the inventory of XBRL Instance documents and taxonomies which are available.
Alternative Flow of Events:
Exceptional Flow of Events:

2.1.3. Compare Basic XBRL Instances

Use Case Name:	Compare Basic XBRL Instances		ID:	4000
Primary Actor:	· Comparison Consumer
Goal:	[G010] To perform comparisons of XBRL data
Assumption:	[A010] There are challenges to comparability which reduces the intrinsic value of the XBRL data which is available
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE020] XBRL taxonomies are available [PRE030] Assertions are available [PRE010] XBRL Instance documents are available
Post Condition:	[POST010] Consumer has performed comparisons which have yielded a valid result
Scenarios
Basic Flow of Events:		[BFE010] The Data Consumer selects XBRL instance documents over which he would like to perform comparisons. [BFE030] The Data Consumer locates assertions that have been provided by Assertion Provider(s) to address those gaps in comparability. [BFE040] The Data Consumer applies the assertions to the comparability scenarios that he wishes to fulfill. [BFE020] The Data Consumer identifies gaps in comparability. [BFE035] The Data Consumer chooses from the set of Assertions that exist.
Alternative Flow of Events:		[AFE010] A pre or post condition of an Assertion fails. [AFE020] The Data Consumer is notified of the failure. [AFE030] The Data Consumer corrects the Assertion, such as choosing another Assertion. [AFE040] The Data Consumer re-runs the Comparison. [AFE100] XBRL instance documents are not public available, e.g. regulators may charge a fee to access data. Do we have specific assertions to handle IP and other entitlements? The same applies for assertion providers and external fact providers. [AFE150] Assertion providers and external fact providers are not public available, e.g. there may be a fee to access.
Exceptional Flow of Events:

2.2. 02 Investing Use Case

Figure 1 - 02 Investing diagram

2.2.1. Report XBRL Instance

Use Case Name:	Report XBRL Instance		ID:	1000
Primary Actor:	· Reporting Officer
Goal:	[G010] To report company business information in XBRL format.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] XBRL taxonomy must exist. [PRE020] Company business information is prepared for reporting.
Post Condition:	[POST010]Existing XBRL Instance document is published.
Scenarios
Basic Flow of Events:		[BFE010] Reporting officer gathers and prepares company’s business information. [BFE025] Reporting officer maps company’s business information to elements (i.e. concepts) in the XBRL taxonomy. [BFE030] Reporting officer generates XBRL Instance document. [BFE040] Company approves the XBRL Instance document for publication. [BFE020] Reporting officer selects XBRL taxonomy to present company’s business information.
Alternative Flow of Events:		[AFE010] Reporting officer concludes that the chosen XBRL taxonomy is insufficient to meet the needs of the company and thus chooses to extend the taxonomy. [AFE020] Reporting officer generates XBRL extensions to the base taxonomy. [AFE040] Company approves the company-specific extensions for publication. [AFE030] Reporting officer defines, documents, and inserts company-specific extensions into the chosen XBRL taxonomy.
Exceptional Flow of Events:		[EFE010]Reporting officer needs to use more than one XBRL taxonomy to report company business information. For example: local (based on local GAAP) and consolidated accounts (based on IFRS) are published into a single in-line XBRL report. Consumer will use the in-line XBRL report rather than pooling the XBRL instance document. .

2.2.2. Pool XBRL

Use Case Name:	Pool XBRL		ID:	2000
Primary Actor:	· · Data Aggregator
Goal:	[G010] To collect together XBRL data from a variety of sources, resulting in a single pool of XBRL data that can be consumed by assertions as part of discrete comparisons which would normally have been performed against just a standalone XBRL instance document.
Assumption:	[A010] The ability to pool XBRL data enables richer ways to analyze and consume XBRL data than is possible with separate standalone XBRL instance data. Pooled XBRL into a data base can provide performance enhancements for software consuming the data and simpler data access.
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE020] XBRL taxonomies exist. [PRE010] XBRL instance data exists.
Post Condition:	[POST010] Pools of XBRL data are available to consumers. [POST020] Pools have appropriate controls and access mechanisms.
Scenarios
Basic Flow of Events:		[BFE010] Data aggregator collects XBRL instance data together. [BFE015] Data aggregator provides an inventory or manifest of the XBRL data that is available. [BFE020] Data aggregator publishes the pool of XBRL data.
Alternative Flow of Events:
Exceptional Flow of Events:

2.2.3. Write Basic Assertion

Use Case Name:	Write Basic Assertion		ID:	3000
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertions which state comparability between component of XBRL instance documents.
Assumption:	[A010] The Assertion provider is a reputable domain expert whose Assertions will carry authority in the respective domain for which they are providing Assertions.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider must be able to state authorship of the Assertion so that Consumers are able to verify the author.
Notes:
Narrative
Pre Condition:	[PRE010] XBRL instance documents are available. [PRE020] XBRL taxonomies are available.
Post Condition:	[POST010] Assertions are created and available to be applied in comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE050] The Assertion Provider releases / publishes the assertions for consumption. [BFE020] The Assertion Provider identifies gaps in comparability which can be closed through the provision of Assertions. [BFE030] The Assertion Provider uses the Comparability Specification to create the Assertions. [BFE040] The Assertion Provider tests the Assertions. [BFE010] The Assertion Provider analyzes the inventory of XBRL Instance documents and taxonomies which are available.
Alternative Flow of Events:
Exceptional Flow of Events:

2.2.4. Assert Comparable Reporting Periods

Use Case Name:	Assert Comparable Reporting Periods		ID:	3100
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertion on reporting periods that can be compared and the reasoning for making such a comparison (for example, instant calendars within a 45 day span of defined date are comparable because they are close to the specified date).
Assumption:	[A010] Comparable reporting period assertion is being used to compare facts with reporting periods that are not equal.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider is writing reporting period Assertions that are relevant to the period type of concepts being compared in a comparison scenario.
Notes:
Narrative
Pre Condition:	[PRE020] Representation of periods must be in ISO 8601 format. [PRE020] Representation of periods must be in ISO 8601 format and XBRL 2.1 compliant.
Post Condition:	[POST010] Comparable reporting period Assertions are created and available to be applied as a component to comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE020] The Assertion Provider identifies gaps in comparing facts with different reporting period context that are comparable. [BFE010] The Assertion Provider defines the reporting periods to be compared based on knowledge of xbrl Instance documents and concept period types. [BFE030] The Assertion Provider uses the Comparability Specification to write Assertion on comparable reporting periods. [BFE050] The Assertion Provider releases / publishes the reporting period Assertion for consumption. [BFE040] The Assertion Provider tests comparable reporting period Assertion.
Alternative Flow of Events:		[AFE010] The Assertion on reporting periods yields partial results, Assertion Provider writes alternative reporting period Assertion to cover missing data points.
Exceptional Flow of Events:

2.2.5. Asserts Comparable Entities

Use Case Name:	Asserts Comparable Entities		ID:	3200
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertion on entities that can be compared and the reasoning for making such a comparison (for example, entity A, B, and C are comparable because they are in the same standard industry classification code 1600).
Assumption:	[A010] Comparable entities assertion is being used to compare facts with entity identifiers that are not equal.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider is writing reporting entity Assertions to make comparisons on entities with some logical grouping.
Notes:
Narrative
Pre Condition:	[PRE010] Entity identifiers applied to instance document facts are available. [PRE020] Entity and segment identifiers must be XBRL 2.1 compliant.
Post Condition:	[POST010] Comparable entity Assertions are created and available to be applied as a component to Comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE010]The Assertion Provider defines the entities to be compared based on knowledge of xbrl Instance documents and entity categories for logical grouping. [BFE020] The Assertion Provider uses the Comparability Specification to write Assertion on comparable entity identifiers. [BFE030] The Assertion Provider tests comparable entities Assertion. [BFE040] THe Assertion Provider releases / publishes the comparable eneities Assertion for consumption.
Alternative Flow of Events:
Exceptional Flow of Events:

2.2.6. Asserts Comparable Sets of Units

Use Case Name:	Asserts Comparable Sets of Units		ID:	3300
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertion on units that can be compared and the reasoning for making such a Comparison (for example, compare US dollars to Chinese Yen as the units are both used to express currency). Also provide to the public a function on units that can be used to report the value of multiple units in a single unit equivalent (for example, convert US dollars to Chinese Yen equivalent at a conversion rate of 6.294 Yen to Dollars).
Assumption:	[A010] Comparable units Assertion is being used to compare facts with units that are not equal.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider is writing Comparable unit Assertions to make comparisons on units that are comparable for some good reason.
Notes:	A few remarks on currency: a) Conversion rate may depend on item type. For example: income statement is converted at average whereas balance sheet is converted at year end rate. b) Investors may want to translate using different methods (latest versus historical exchange rates, fixed or flexible euro conversion rates) c) The conversion rate that an investor may want to use can be the one reported in the XBRL instance document by the company. Only if not available will an external rate be used. d) Currency re-denomination; it is possible that one set of data items need to be multiplied or divided with a different factor compared to another set of data items. For example: for the Turkish currency redenomination, all per share data and number of shares had to divided by 1000, whereas other monetary data elements had to be divided by 1,000,000. e) Major versus minor unit of currency. Pence may have to be translated into pounds and vice versa.
Narrative
Pre Condition:	[PRE020] Units declarations must be XBRL 2.1 compliant. [PRE010] Units applied to instance document facts are available.
Post Condition:	[POST010] Comparable unit assertions are created and available to be applied as a component to comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE010] The Assertion Provider defines the units to be compared based on knowledge of xbrl Instance Documents and available units and conversion rates between units. [BFE030] The Assertion Provider uses the Comparability Specification to write function to perform the conversion of a set of facts to a single unit equivalent. [BFE040] The Assertion Provider tests assertion on comparable units and conversion function. [BFE050] Assertion Provider releases / publishes the comparable units Assertion for consumption. [BFE020] Assertion Provider uses the Comparability Specification to write Assertion on comparable units.
Alternative Flow of Events:
Exceptional Flow of Events:

2.2.7. Asserts Comparable Concepts

Use Case Name:	Asserts Comparable Concepts		ID:	3400
Primary Actor:
Goal:	[G010] To provide public Assertions on concepts that can be compared and the reasoning for making such a Comparison (for example, Ifrs:BasicEarningsLossPerShare is comparable to us-gaap:EarningPerShareBasic because they represent a similar accounting concept. The differences in accounting include calculation inconsistencies because USGAAP calculates this concept as "The number of incremental shares is computed using a year-to-date weighted average of the number of incremental shares included in each quarterly calculation." whereas IFRS calculates it "The number of incremental shares is computed as if the entire year-to-date period were “the period” (that is, do not average the current period with each of the prior periods)." amongst other potential differences),
Assumption:	[A010] Comparable concepts Assertions are being created to link similar concepts and provide the reasons the concepts are comparable and the potential differences in concepts.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider is writing comparable concept Assertions to make Comparisons on concepts that are comparable for some good reason.
Notes:	For comparable concepts there may be a simple case and the more complex case: a) As reported. Concepts are comparable based on ‘meaning’ of the item. For example: pre-tax profit irrespective how defined or measured across taxonomies. b) Standardized. Concepts are equivalent based on meaning and child parent relationship. For example: pre-tax profit includes equity earnings for company A but not for company B. Adjustment is made to exclude equity earnings for company A based on default or customized rules.
Narrative
Pre Condition:	[PRE020] Concepts are expressed in compliance with XBRL 2.1 specification. [PRE010] Concepts (represented by and XBRL element) applied to Instance Document facts are available.
Post Condition:	[POST010] Comparable concept assertions are created and available to be applied as a component to comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE040] The Assertion Provider uses the Comparability Specification to write assertion on comparable concepts and alternative assertions for comparable concepts. [BFE060] The Assertion Provider releases / publishes the comparable concepts Assertion for consumption. [BFE030] The Assertion Provider defines alternative assertions for comparable concepts should the primary Assertion set provide null results. [BFE020] The Assertion Provider uses the Comparability Specification to write Assertion on comparable concepts. [BFE010] The Assertion Provider defines the concepts to be compared based on knowledge of XBRL Instance Documents, comparable concepts and their definitions. [BFE050] The Assertion Provider tests Assertion on comparable concepts.
Alternative Flow of Events:		[AFE010] Primary Assertion does not find comparable facts based on the Assertion scenario provided. The Assertion Provider creates a hierarchy of alternative assertions to reach the desired comparison. For example, no results were found for us-gaap:EarningPerShareBasic preform calculation for us-gaap:NetIncome divided by us-gaap:CommonStockSharesOutstanding.
Exceptional Flow of Events:

2.2.8. Asserts Comparable Dimensions

Use Case Name:	Asserts Comparable Dimensions		ID:	3500
Primary Actor:
Goal:	[G010] To write Assertions about comparable dimensions.
Assumption:	[A010] The Assertion Provider is writing Comparable dimensions because they know that a concept has been modeled with a concept (XBRL line item element) and a context axis/member.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider is writing comparable dimension Assertions to make comparisons on dimensions that are comparable for some good reason.
Notes:
Narrative
Pre Condition:	[PRE020] Dimensions are XBRL 2.1 compliant. [PRE010] Dimensions (represented in XBRL ContextRef) applied to XBRL Instance Document facts are available.
Post Condition:	[POST010] Comparable dimension Assertions are created and available to be applied as a component to comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE010] The Assertion Provider defines the dimensions to be compared based on knowledge of XBRL Instance Documents and comparable dimensions. [BFE020] The Assertion Provider uses the Comparability Specification to write Assertion on comparable dimensions. [BFE030] The Assertion Provider tests Assertion on comparable dimensions. [BFE050] The Assertion Provider releases / publishes the comparable dimensions assertion for consumption.
Alternative Flow of Events:
Exceptional Flow of Events:

2.2.9. Generate Investment Comparison

Use Case Name:	Generate Investment Comparison		ID:	4000
Primary Actor:	· Investment analyst
Goal:	[G010] For an Investment Analysts to compare Instance Documents using applicable Assertions.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PreC020] Has access to required Assertion Set/s [PreC010] Has access to the required Instance Documents.
Post Condition:	[POSTtC010] A comparison result has been published
Scenarios
Basic Flow of Events:		[BFE020] The Investment Analysts identifies the Instance Documents available from the firms. [BFE050] The comparison is run. [BFE030] The analyst identifies the available assertions based on the Taxonomy of available instance documents. [BFE040] The Instance Documents are sources. [BFE060] The result of the comparison is published to the Investment Advisor. [BFE010] An Investment Analyst identifies two (or more) firms requiring comparison. Analyst selects a group of companies (sector, country, user defined criteria such as companies with a market value greater than 1 billion in a particular country etc..) .
Alternative Flow of Events:		[AFE010] The comparison of one firm is against an external data source, not from another XBRL Instance Document. [AFE100] The author wants to force the comparison to be done in another currency than is specified by the Assertion Provider. <undefined>
Exceptional Flow of Events:		[EFE010] One of the XBRL Instance Documents does not have some of the information required by one of the Assertions.

2.2.10. Write Comparison

Use Case Name:	Write Comparison		ID:	4100
Primary Actor:
Goal:	[G010] To define a valuable comparison of XBRL Instance Document facts and define Assertion sets that maximize the comparison based on a set of Assertions.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE020] Instances are available. [PRE010] Assertion sets for data are available.
Post Condition:	[POST010] Users of the Assertion model have defined the entities, concepts, reporting periods, units, and dimensions to perform comparison. User defines Assertion set to maximize comparability and query results.
Scenarios
Basic Flow of Events:		[BFE040] The Investment Analyst defines Assertions (or Assertion set) to use when running the comparison (for example use the E&Y Assertion set for comparing US GAAAP to IFRS). [BFE030] The Investment Analyst defines entities to be compared (for example SAP to IBM). [BFE010] The Investment Analyst defines the concept (s) for comparison (For example us-gaap:EarningPerShareBasic). [BFE020] The Investment Analyst defines the reporting period for comparison (For example <xbrli:period><xbrli:startDate>2011-01-01</xbrli:startDate><xbrli:endDate>2011-02-21</xbrli:endDate></xbrli:period>). Assertion providers would have written business rules to ‘normalize dates’. For example: an user specifies as date the fiscal year 2011. A normalized business rule would return all companies that have a XBRL end date falling within a particular range.
Alternative Flow of Events:		[AFE010] The Investment Analyst could define units to be compare (for example <xbrli:unit id="USDPerShare"><xbrli:divide><xbrli:unitNumerator> <xbrli:measure>iso4217:USD</xbrli:measure></xbrli:unitNumerator> <xbrli:unitDenominator><xbrli:measure>xbrli:shares </xbrli:measure></xbrli:unitDenominator></xbrli:divide> </xbrli:unit>). [AFE020] The Investment Analyst could define dimensions to be compared.
Exceptional Flow of Events:

2.2.11. Run Comparison

Use Case Name:	Run Comparison		ID:	4200
Primary Actor:
Goal:	[POST010] Software is able to find all instances that meet the defined requirements of the Investment Analyst based on assertions set provided.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] Assertions set for data are available. [PRE020] Instances are available. [PRE030] Investment analyst has written the comparison.
Post Condition:	[POST010] A comparison of instance document facts and assertions required to make that comparison.
Scenarios
Basic Flow of Events:		[BFE010] The software scans instance documents for defined instance document attributes. [BFE020] The software pulls the facts that meet the requirements defined in the assertion from the Investment Analyst. [BFE030] The software scans instance documents for defined instance document attributes. [BFE040] The software looks to assertion set to see is assertion is provided for unattached data (for example SAP does not contain us-gaap:EarningPerShareBasic but assertion 1234 us-gaap:EarningPerShareBasic to Ifrs:BasicEarningsLossPerShare exists - use this assertion for writing comparison result.). [BFE050] The software does not return data that is not explicitly defined by Investment analyst or explicitly defined in an assertion.
Alternative Flow of Events:		[AFE010] Software scans instance documents for defined instance document attributes. [AFE020] software pulls the fact that meet the requirements defined in the assertion from the Investment Analyst. [AFE030] Software scans instance documents for defined instance document attributes. <undefined> [BFE040] Software looks to assertion set to see is assertion is provided for unattached data (for example SAP does not contain us-gaap:EarningPerShareBasic but assertion 1234 us-gaap:EarningPerShareBasic to Ifrs:BasicEarningsLossPerShare exists - use this assertion for writing comparison result.). [AFE050] Software does return data that is explicitly defined by Investment analyst, explicitly defined in an assertion, and data that has not been completely defined and is considered implicitly comparable.
Exceptional Flow of Events:		[EFE010] User has the option to re-run comparison to include companies that are not fully comparable. For example: user want to compare Q004 growth rates for all constituents of an European stock exchange index for the fiscal year 2010. One company changed accounting policies in Q003 but did not provide restated or cumulative Q003 data. Before publishing the result, the user is alerted to this fact and is asked if he wants to include Q004 data for this company based on original disclosed information only. User can select yes or no. If selected as ‘yes; and when result is published, a warning message appears. If selected no, no value is provided and the reason as to why no value is provided is given to the user.

2.2.12. Publish result

Use Case Name:	Publish result		ID:	4300
Primary Actor:
Goal:	[G010]Produce a report that points the investor to reported facts and assertions made on those facts to make them comparable for investing decisions.
Assumption:	[A010] Investor knows what they would like to compare but might not understand the complexities to make multiple facts comparable. Assertions on data yield more comparison results. Investor wants to know what was asserted on the data to make comparisons in order to make better investment decisions.
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] Comparable fact set exists. [PRE030] Assertions applied to context to create comparable result are known and linked to the fact. [PRE020] Comparison contexts are defined and tied to comparable facts.
Post Condition:	[POST010] Output of comparable facts. [POST020] Identification of context of fact defined in writing comparison (USe Case Number 3100). [POST030] Identification of context of fact defined in run comparison that utilized assertions set artifact. [POST040] Produce a report for Investment Analyst that shows the comparison requested and assertions made on data to yield expected results.
Scenarios
Basic Flow of Events:		[BFE010] – Report comparable facts. [BFE020] – Report context details defined by the Investment Analysis in the Write Comparison use case and link them to the facts. [BFE030] – Report Assertion set used to make comparison. [BFE040] – Write assertion used on comparable calendar and link them to the facts that they apply to. [BFE050] - Write assertion used on comparable entities and link them to the facts that they apply to. [BFE060] - Write assertion used on comparable units and link them to the facts that they apply to. [BFE070] - Write assertion used on comparable concepts and link them to the facts that they apply to. [BFE080] - Write assertion used on comparable dimensions and link them to the facts that they apply to.
Alternative Flow of Events:		[AFE010] - User has the option to re-run comparison to include companies that are not fully comparable. For example: user want to compare Q004 growth rates for all constituents of an European stock exchange index for the fiscal year 2010. One company changed accounting policies in Q003 but did not provide restated or cumulative Q003 data. Before publishing the result, the user is alerted to this fact and is asked if he wants to include Q004 data for this company based on original disclosed information only. User can select yes or no. If selected as ‘yes; and when result is published, a warning message appears. If selected no, no value is provided and the reason as to why no value is provided is given to the user.
Exceptional Flow of Events:

2.3. 03 Benchmarking Use Case

Figure 1 - 03 Benchmarking diagram

2.3.1. Report XBRL Instance

Use Case Name:	Report XBRL Instance		ID:	1000
Primary Actor:	· Reporting Officer
Goal:	[G010] To report company business information in XBRL format.
Assumption:
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] XBRL taxonomy must exist. [PRE020] Company business information is prepared for reporting.
Post Condition:	[POST010]Existing XBRL Instance document is published.
Scenarios
Basic Flow of Events:		[BFE010] Reporting officer gathers and prepares company’s business information. [BFE025] Reporting officer maps company’s business information to elements (i.e. concepts) in the XBRL taxonomy. [BFE030] Reporting officer generates XBRL Instance document. [BFE040] Company approves the XBRL Instance document for publication. [BFE020] Reporting officer selects XBRL taxonomy to present company’s business information.
Alternative Flow of Events:		[AFE010] Reporting officer concludes that the chosen XBRL taxonomy is insufficient to meet the needs of the company and thus chooses to extend the taxonomy. [AFE020] Reporting officer generates XBRL extensions to the base taxonomy. [AFE040] Company approves the company-specific extensions for publication. [AFE030] Reporting officer defines, documents, and inserts company-specific extensions into the chosen XBRL taxonomy.
Exceptional Flow of Events:		[EFE010]Reporting officer needs to use more than one XBRL taxonomy to report company business information. For example: local (based on local GAAP) and consolidated accounts (based on IFRS) are published into a single in-line XBRL report. Consumer will use the in-line XBRL report rather than pooling the XBRL instance document. .

2.3.2. Pool XBRL

Use Case Name:	Pool XBRL		ID:	2000
Primary Actor:	· · Data Aggregator
Goal:	[G010] To collect together XBRL data from a variety of sources, resulting in a single pool of XBRL data that can be consumed by assertions as part of discrete comparisons which would normally have been performed against just a standalone XBRL instance document.
Assumption:	[A010] The ability to pool XBRL data enables richer ways to analyze and consume XBRL data than is possible with separate standalone XBRL instance data. Pooled XBRL into a data base can provide performance enhancements for software consuming the data and simpler data access.
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE020] XBRL taxonomies exist. [PRE010] XBRL instance data exists.
Post Condition:	[POST010] Pools of XBRL data are available to consumers. [POST020] Pools have appropriate controls and access mechanisms.
Scenarios
Basic Flow of Events:		[BFE010] Data aggregator collects XBRL instance data together. [BFE015] Data aggregator provides an inventory or manifest of the XBRL data that is available. [BFE020] Data aggregator publishes the pool of XBRL data.
Alternative Flow of Events:
Exceptional Flow of Events:

2.3.3. Write Basic Assertion

Use Case Name:	Write Basic Assertion		ID:	3000
Primary Actor:	· Assertion Provider
Goal:	[G010] To provide public Assertions which state comparability between component of XBRL instance documents.
Assumption:	[A010] The Assertion provider is a reputable domain expert whose Assertions will carry authority in the respective domain for which they are providing Assertions.
To Do:
Implementation Issues:
Non Functional Requirements:	[NFR010] The Assertion Provider must be able to state authorship of the Assertion so that Consumers are able to verify the author.
Notes:
Narrative
Pre Condition:	[PRE010] XBRL instance documents are available. [PRE020] XBRL taxonomies are available.
Post Condition:	[POST010] Assertions are created and available to be applied in comparison scenarios.
Scenarios
Basic Flow of Events:		[BFE050] The Assertion Provider releases / publishes the assertions for consumption. [BFE020] The Assertion Provider identifies gaps in comparability which can be closed through the provision of Assertions. [BFE030] The Assertion Provider uses the Comparability Specification to create the Assertions. [BFE040] The Assertion Provider tests the Assertions. [BFE010] The Assertion Provider analyzes the inventory of XBRL Instance documents and taxonomies which are available.
Alternative Flow of Events:
Exceptional Flow of Events:

2.3.4. Compare Against a Pool of XBRL Data

Use Case Name:	Compare Against a Pool of XBRL Data		ID:	4000
Primary Actor:	· Comparison Consumer
Goal:	To perform comparisons of XBRL data against a pool of other similar XBRL data gathered from a collection of XBRL sources
Assumption:	There are cases where it is valuable to compare XBRL instance data against a pool of other similarly reported XBRL instance data.
To Do:
Implementation Issues:
Non Functional Requirements:
Notes:
Narrative
Pre Condition:	[PRE010] XBRL instance documents are available [PRE020] XBRL taxonomies are available [PRE030] Pools of XBRL data are available [PRE040] Assertions are available which can leverage the presence of pools of XBRL data [PRE050] Assertions can define new and additional comparison points which are possible against the pool (e.g. compare against an average, against a standard deviation, against a certain percentile, etc.)
Post Condition:	[POST010] Data consumer has performed comparisons of XBRL data against a pool of XBRL data
Scenarios
Basic Flow of Events:		[BFE010] Data Consumer selects XBRL instance documents over which he would like to perform comparisons. [BFE030] Data Consumer locates assertions that have been provided by Assertion Provider(s) to address those gaps in comparability. [BFE040] Data Consumer applies the assertions to the comparability scenarios that he wishes to fulfill. [BFE020] Data Consumer evaluates the availability of XBRL pools against which he can perform comparisons. [BFE030] Data Consumer selects an XBRL pool against which to compare his instance document. [BFE040] Data Consumer evaluates the availability of assertion sets which can leverage the data in the XBRL pool. [BFE050] Data selects one or more assertion sets which fulfills his comparison needs. [BFE060] Data Consumer performs comparisons between his instance document and the pool of XBRL data.
Alternative Flow of Events:		[AFE010] A pre or post condition of an Assertion fails. [AFE020] The Data Consumer is notified of the failure. [AFE030] The Data Consumer corrects the Assertion, such as choosing another Assertion. [AFE040] The Data Consumer re-runs the Comparison.
Exceptional Flow of Events:

3. Business Requirements

This section defines the requirements of all XBRL Comparability users.

Defining a standard that enables these requirements to be met is a major goal of the phase two Comparability Task Force.

3.1. Approach

The business requirements have been written to these rules:

1. Hierarchical: The requirements are structured into Parent Child relationships

2. Complete: The children of a parent define the parent in fully and completely

3. Orthogonal: Each requirement is standalone – the requirements are as independent, with the least amount of overlap as possible.

4. Acceptance criteria: Each requirement has criteria by which the implementation is measured. The criteria of a parent are a summary of the criteria of the children.

3.2. Requirements versus needs

In the process of writing the Business Requirements the working party found it helpful to make the following distinctions:

· XBRL Comparability requires management of, and integration into, elements that are non XBRL. For example, external data, such as an exchange rate, is required to be integrated into an XBRL Comparability authoring and execution

· This wider scope means the working party identified issues outside the direct scope of the Comparability standard that are still dependencies

· Therefore, the team determined to define

o "Requirements" to mean something to be reflected in the XBRL Comparability standard

o "NEEDS" to mean a dependency of comparability that would not directly be expressed in the XBRL Comparability standard.

3.3. The tickback process

The business requirements are derived from the Use Cases. In order to show completeness and avoid duplication and overlap, the relationship from the Use Case to the Business Requirements is shown directly.

The right hand column of this table is a cross reference to the Use Case, and the element within the Use Case, from where the requirement is derived.

e.g. "01 1000 BFE 010" refers to:

- The 01 Use Case diagram

- The Use Case numbered 1000 within that diagram

- The Basic Flow of Events number 010 within that Use Case

The Children BR are assumed to inherit the BR of their Parents, unless stated otherwise. For example:

The entities / nouns in the UML Class diagram, where used in a business requirement or Use Case, in CAPS [1]. This enables unambiguous cross reference.

3.4. Business requirements

These requirements are broken into four parts:

Defining the Comparison Standard
Manage the "externals" provided by assertions providers
Writing a comparison
Publishing a comparison result
Publishing XBRL instances

Number	Requirement	Source Use Case
1	Define comparison standards	01 2000 BFE030
1.1	Manage Comparability specification.
1.1.1	The Comparability specification must be managed in the same regime as other XBRL Standards
1.1.2	The Comparability specification must be integrated with other external standards. Examples are those standards to do with identification, authentication etc.

Number	Requirement	Source Use Case
2	Define Global Comparability EXTERNALS. EXTERNALS are "remote" functions and must adhere to the same requirements as 2.1.3. OUTSTANDING: Clear definition of EXTERNALS. Is an EXTERNAL the concrete implementation of a ASSERTION?
2.1	Requirement: An Externals author must be able to define a function that any appropriate Comparison Author can use.
2.1.1	An External must be writable for
2.1.1.a	Accessing external facts (such as enterprise identifiers, security identifiers or exchange rates).
2.1.1.b	Mapping between variables (such as exchange rates). Note: these details are specifically for mappings, a simple assertion type.
2.1.1.b.1	Mappings must relate two data points together NOTE: Looking for better name than "data point".
2.1.1.b.2	Mappings must have a single input.
2.1.1.b.3	Mappings must have a single output.
2.1.1.b.4	Mappings preserve type from input to output?
2.1.1.c	Performing a function (such as a mathematical function or a set of functions).
2.1.1.d	Calling a web service.
2.1.1.e	Pools (as well as instances)
2.2	A catalogue of Externals must be published and available to the XBRL community.
2.3	The Externals must be accessed by the community under agreed conditions (covering Intellectual Property, commercial and other criteria).
2.4	Externals must integrate with other standards (such as group http://www.w3.org/RDF/).
2.5	EXTERNALS must be uniquely identifiable by a comparison author, for example by a URI.
2.6	EXTERNALS must be able to draw on other EXTERNALS for input.

Number

Requirement

Source Use Case

Write a Comparison

3.1

Comparisons Inputs

3.1.1

Comparisons must be able to draw on taxonomies for input.

01 2000 PRE 010

3.1.1.1

Concepts

3.1.1.2

Dimensions

3.1.1.A

The same NEEDS exists for Taxonomies as for Instance Documents – see 2.1.2.A, 2.1.2.B, 2.1.2.C etc

3.1.2

Comparisons must be able to draw on XBRL instance documents for input.

01 2000 PRE 020

3.1.2.1

XBRL facts

3.1.2.2

XBRL periods

3.1.2.3

XBRL entity declarations

3.1.2.4

XBRL concept

3.1.2.5

XBRL dimensions and members

3.1.2.6

XBRL unit

3.1.2.A

An Instance document NEEDS to be uniquely identifiable. A comparer (and a Comparison author) must be able to refer to a unique instance document (i.e. it has a unique id) Aside: See the URN standard http://en.wikipedia.org/wiki/Uniform_Resource_Name for an existing standard.

3.1.2.B

Instance document NEEDS be gettable.

A comparer must be able to retrieve an instance document (ie. it has a URL)

See URL standard http://en.wikipedia.org/wiki/Uniform_Resource_Locator

The document must be accessible by typing the URL into a browser.

IMPLEMENTATION THOUGHT: a candidate technology would be hashed blog objects like git uses?

3.1.2.C

Instance documents NEED be verifiable (Document must be provably valid and unchanged from publication).

For example, Instance documents NEED to be published with a checksum.

Example approach is Md5 http://en.wikipedia.org/wiki/Md5sum

3.1.2.D

Instance documents must be authenticable – the consumer should be able to prove that the document is from the author claimed.

The authenticating protocol NEEDS to be open - the end user should be able to chose from a number of the authentication options like http://en.wikipedia.org/wiki/OpenID or VeriSign or other vendors.

3.1.2.E

Instance documents NEEDS be findable / searchable

An instance consumer / comparer NEEDS be able to find instance documents by search criteria (e.g. "I want all instances of the

a) xyz taxonomy

b) issued by firms in the abc industry

c) who are headquarted in def"

d) in this specified time period,

e) suing this financial statement type (annual or interim),

f) and I want the statement update type of …(original, restated, reclassified, pro-forma)."

3.1.2.F

There NEEDS to be a standard language which an end user can use to define a search - see http://en.wikipedia.org/wiki/SPARQL for an example.

3.1.2.G

External suppliers NEED be able to "add value" by codifying / annotating instance documents with meta data (so end users can do the searches, even if the XBRL instance document author did not provide that info). One standard for this is http://en.wikipedia.org/wiki/Resource_Description_Framework#Resource_identification.

3.1.3

Comparisons must be able to draw on functions for input.

3.1.3.1

Functions must be defined in terms of a signature, which consists of input parameters and a result type. E.g. A "Round" function might have a signature of a real number and the number of positions to round. The returned type might be an integer.

3.1.3.2

Functions must be able to handle exceptions.

3.1.4

Comparisons must be able to draw on services for input.

3.1.6

Comparisons must be able to draw on other comparison results for input.

3.1.7

The author must be able to define 2 sides of the comparison. [OUTSTANDING ISSUE: is there a reason to restrict to 2 sides?]

3.1.7.1

For each side of the comparison the author must be able to define the where XBRL compared must be "sourced" (bad name).

3.1.7.1.A

XBRL instance document

3.1.7.1.B

XBRL pooled data

3.1.7.1.C

Other data

3.1.7.1.Ci

Web services

3.1.7.1.Cii

Static data

EXAMPLES
Name	View
Local drive	C:\.
Web address	http:www.mysite.com/xbrl/
Database	Data Source=username/password@myserver/myservice:dedicated/instancename;

3.1.7.2

For each side of the comparison the author must be able to identify the DOCUMENTS [bad name?] within the SOURCE.

3.1.7.2.a

An individual instance document.

3.1.7.2.b

A set of instance document by a set of criteria, which may be meta data.

EXAMPLES
Name
Individual instance file	RIM_2011.xbrl
Individual by unique identifier	Examples of unique identifiers include - Hash keys (a unique key derived from the content http://en.wikipedia.org/wiki/SHA-1) -
Selected pool	All instances where the company is headquartered in Japan and Industry is Mobile Phones

3.1.7.3

For each side of the comparison the author must be able to identify the target within TARGETS the DOCUMENTS.

3.1.7.3.1

The TARGETS may be:

3.1.7.3.1.i

FACTS within an instance document.

3.1.7.3.1.ii

The result of a "function" (e.g. SUM).

3.1.7.3.1.iii

The result of service call such as an exchange rate conversion.

3.1.7.3.1.iv

Data point from a pool (the result of an assertion).

EXAMPLES
Name
Single data point	Annual profit
Derived	Average of "Annual profit"
Service call	Annual profit, converted to USD using Reuters exchange rates as at 2010-01-01

3.2

Comparisons RESULT

For examples of what RESULTS look like see the section 4.1 Introduction.

3.2.1

Comparisons must generate a COMPARISON RESULT.

3.2.1.1

A RESULT must be a side by side comparison.

3.2.1.2

The columns and the left hand and right hand side must be of the same form.

3.2.1.3

The columns must reflect the dimensions and criteria used in the authoring of the comparison.

1) There must be a extra column [or more?] to allow feedback to the end user Examples include:

a. feedback from web services

i. Messages, such as definitions, from Assertion providers

ii. Warnings

iii. Errors / failures

b. Pre-condition failures

c. Post condition failures

3.2.1.

There must be a rows must represent the selected left and right hand side.

3.2.1.1

There is a row for each unique member of the DIMENTIONs of the TARGET elements.

3.2.1.2

If there is a match on one side but not on the other then the empty side should show null e.g. you ask to compare the revenues by region of 2 companies – if one operates in a region that the others does not the region should still be listed.

3.2.2

Comparisons must be publishable, so consumers can find and access them.

01 2000 BFE050

3.2.2.1

The approach to publishing results should be the same as for publishing instance docs and taxonomies.

Example: In this example the user asks to compare

1. One and only one instance document on each side

2. For Nokia on the LHS

3. For RIM on the RHS

4. For the year 2011 –include rows even if the data is not there ([NOT] covered?)

5. TARGETED figure of profit (without currency conversion). It is a pre-condition that in both taxonomies the profit figures are listed by product.

6. By the product dimension –include rows even if the data is not there ([NOT] covered?)

7. Using the "Original" reported values

RESULT:

Notes:

1. They selected target instances using the firm names of Nokia and RIM – so the name is shown. This could be shown once rather than repeated on each row.

2. The year is shown as it is a selection criteria. In this case both documents have 2011 year. If there was no data for that year then the columns would be empty. (however, see the note below about the pre and post condition checks). If year was not a selection criteria then it would not be shown. In the case where there is data for more than one year then the amounts would be summed. If profit is defined, say, by month, then it would be summed to the year figure.

3. If, within either taxonomy, the profit figure is broken down by, say, region and product then this request for profit by product alone implies the summing of profit across region.

4. The products "Phones", "Pads" and "Services" are listed and matched on both sides. In this case the profit for the "Minutes" product is in the instance document for RIM but not for Nokia.

5. The profit data point is not specified with a currency conversion, so the result is in the reported currency.

6. Any messages are also allowed for on each side. In this case the Minutes profit is annotated with "estimated". This message might come, for example, from the service provider who is augmenting an original XBRL instance document.

7. If more than one instance document existed for either company in 2011 then the single instance document pre-condition would fail and the result would be a pre-condition exception. [Comment: You would have assertions which would handle this. For example: company produces and 10K and 10KA. The assertion could be then unless specified differently, the 10K A is used. You would also have assertions to handle year end changes and annualize data where appropriate.]

8. If one or both sides did not have matching data (even if there was an instance document) then the post condition of one and only one instance document would fail and the result would be post–condition exception.

Number	Requirement	Source Use Case
3	Perform a comparison
	The user must be able to perform a comparison where an XBRL instance document exists on at least one side of the comparison.
3.1	Specify Explicit comparison inputs
3.1.1	Resolve differences in currency
	The user must be able to resolve differences which are introduced due to numeric figures being given in different currency.
3.1.2	Resolve differences in dates (periods and instances)
	The user must be able to resolve differences which are introduced due to dates being reported which are not identical, but which are close enough for comparison purposes. For example, there should be a way to assert that a date which is within a "15-day" overlap period is close enough for comparison purposes.
3.1.3	Resolve differences in entity declarations /securities etc,,
	The user must be able to resolve differences which are introduced due to entity declarations (pointing at the same entity) being of different format.
3.1.4	Define a way to declare pre-conditions
	Pre-conditions are assumptions that must be met in order for an assertion to execute. For example, an assertion which states that 1.5USD = 1EUR might have a pre-condition that the accompanying date must be "August 2011".
3.1.5	Define a way to declare post-conditions
	Post-conditions are assumptions that must be met in order for an assertion's output to be valid.
3.1.6	Resolve differences in XBRL Concept (taxonomy element) declarations
	The user must be able to resolve differences which are introduced due to reporting elements which are fundamentally the same concept but which use different names because they come from different namespaces/taxonomies.
3.1.7	The user must be able to select COVERED and UNCOVERED. To do: Correct words needed here about COVERED and UNCOVERED, to match with their use in other parts of standard.
3.2	Run a comparison
3.2.1	Inputs
3.2.1.1	Must be able to select a comparison to perform.	10 3000 PRE030
3.2.1.2	Must be able to select both sides of a comparison.	10 3000 PRE010 10 3000 BFE010
3.2.1.3	Must be able to over-ride default setting for a comparison. See ASPECT POINT CUTS and ASPECTS in the domain model.	10 3000 BFE030
3.2.1.4	Must be able to specify pre-conditions.
3.2.2	Execute a comparison	10 3000 BFE040
	Acceptance criteria: A comparison can only execute with mandatory inputs present.
	Acceptance criteria: There is a log or proof of execution.
	Acceptance criteria: All errors are trapped, where they exist, being reported back to the user, with trace information that enables a user to identify the root cause/s.
3.3	Publish a comparison result	01 1000 POST010
3.3.1	Must be able to uniquely identify a COMPARISON RESULT.
3.3.2	From the result you must know what the result is for.
3.3.2.1	Left and right hand sides
	This implies that anything underneath EXTERNALS must have a way to also identify themselves.
3.3.2.2	The comparison
3.3.2.2.1	Syntactic definition of explicit inputs entered into comparison.
3.3.2.2.2	Syntactic definition of implicit results returned.
3.3.2.2.3	Semantic definition of all results in comparison included in the assertion set.
3.3.2.3	The overrides used
3.3.2.4	Timestamp
3.3.2.5	The environment. This might end up being optional due to privacy concerns.
3.3.2.6	The user. This might end up being optional due to privacy concerns.
3.3.3	Readable : there must be a known "standard" by which potential reads can read the result – it is in XML, it is to a particular XSD, it is in xHTML / CSV

Number	Requirement	Source Use Case
4	Prove a comparison result
4.1	A comparison must be expressed in a formal way, un-ambiguous way.
4.2	There must be a set of expected results by the author of a comparison.
4.3	There must be a "reference implementation" of a comparison.

Number	Requirement	Source Use Case
5	Publish XBRL instances
5.2	XBRL data must be able to be made available for consumption by others – to "Publish"
5.1	Owners must be able to assert intellectual property rights	Use Case Pool XBRL [POST020] Pools have appropriate controls and access mechanisms.

4. Appendix: Abstract domain model [2]

This section describes the domain in terms of the classes, their attributes and their relationships.

4.1. Comparability domain model

Figure 1. Comparability domain model

Advice

Aspect Specification

Attributes

Name	Type	Multiplicity	Description
AspectSpecificationID

Assertion

Assertions can come in sets as it relates to concepts, units, periods and entities.

Attributes

Name	Type	Multiplicity	Description
	Equater
	Equater
	Comparability Specification
	Generate Investment Comparison
assertionName

Comparability Specification

Attributes

Name	Type	Multiplicity	Description
unnamed1

Comparison

Attributes

Name	Type	Multiplicity	Description
	Assertion
	ComparisonResult
comparisonFunction
comparisonResult
Equater2Result
Equator1Result

ComparisonResult

Attributes

Name	Type	Multiplicity	Description
	Comparison
Timestamp	date		Date and time that a comparison was preformed.

Equater

Attributes

Name	Type	Multiplicity	Description
	Assertion
	Assertion
	Comparability Specification

Equater
node

Attributes

Name	Type	Multiplicity	Description
	Equater
	Equater node
	Equater node
	Function
	Services
	Instance
	Mapping

ExternalComparisonResult

Externals Specification

Function

Functions modify instance document facts during comparison based on a defined parameters specified in external assertions.

If a currency exchange rate is 1.4 EURO to USD a function could perform a 1.4 multiplication to all USD facts in the comparison and return External Comparison Results in EURO equivalents. Alternatively the function could perform and 1.4 division to EURO facts in a comparison returning an External Comparison Result in USD equivalents.

Attributes

Name	Type	Multiplicity	Description
	Equater node

Instance

Attributes

Name	Type	Multiplicity	Description
	Equater node

Mapping

Attributes

Name	Type	Multiplicity	Description
	Equater node

pointCut

Services

Attributes

Name	Type	Multiplicity	Description
	Equater node

XBRL Taxonomy

This class represents an XBRL Taxonomy as defined by the Abstract Model Task Force.

Attributes

Name	Type	Multiplicity	Description
	Equater node

4.2. Investing Comparison Result

Figure 2. Investing Comparison Result

Assertion US GAAP EPS to IFRS EPS

IFRS EPS

US GAAP EPS

5. Appendix: Contributing work

The following work was part of the preparation of the file product. It is included to provide context and motivations for the final versions above.

5.1. Comparing companies Use Case

The most common scenario is to compare several companies data by industry.

This is a screen shot for a simple analytical tool SSE provided to investors.

CSRC and the Exchanges are now considering to open international board to introduce Foreign Companies to be listed in China.
The immediate question would be how to disclosure, in what form and by what standard.
The next question would be how to compare them to local companies, and if they make disclosure by local requirements, how to compare them with their other disclosure documents in their own country by their own standard if there are any.
Another common scenario is to compare this year's data with historical data.
From 2006 to 2007, China experienced a major accounting policy change. We develop new taxonomy for new accounting policy but left behind bunch of instance documents in old taxonomy. While doing historical data comparison, problem rises, which I think versioning method won't be enough to solve this problem.
The three base method used in CSRC's annual research of the Market is aggregate, average, then compare.
To set a bench mark for the Market is very important to us. We wish to identify whether the concept can be aggregated, averaged, or compared. I wish this solution would not be limited to comparison only.
Probably out of scope:
The sectors by industry may be different country by country, would there be a mapping method for this?

5.2. Structural implications use case

This use case explores the implications of Comparability for the how organisations use XBRL.

XBRL Scenario

Mary is a controller for an investment bank. She works in global risk management, having responsibilities to ensure that, within the EMEA region, no desk is taking too much risk.

She is particularly interested at the moment in the UK desk and the French desk. In meetings they are saying very different things, but she is seeing very similar trading patterns. If so, that would mean the bank is taking bigger risks than management are lead to believe.

As Is situation

To investigate, Mary wants to look at the trading profile of each desk. She has the GL accounts from both, but needs to drill down into the detail.

She is also going to need some kind of helicopter view, slice and dice capabilities, as well as ability to contrast the treatment of a French company with that of a comparable British company.

As Is situation on the UK desk

Firstly, she rings David, from the UK desk. "Can I have the details you are using to track and research your UK stocks?" she asks.

David panics – not only is he nervous when talking to the risk guys, he does not want to expose such information.

"Of course, you can have our spreadsheets" he says, hoping to sound cheerful.

As Is situation on the French desk

Next she rings Nicolas, from the French desk. "Can I have the details you are using to track and research your French stocks?" she asks.

Nicolas panics – not only is he nervous when talking to the risk guys, he does not want to expose such information, and he doesn't like the English.

"Of course, you can have our spreadsheets" he says, hoping to sound cheerful.

The Spreadsheet Versions

Once she has both sets of spread sheets there was an immediate problem. There were hundreds of spread sheets, each of a different format, in 2 languages and 2 currencies.

When she rang David to ask what one figure actually meant he replied "that spread sheet was written by a chap who left 9 months ago. What I guess he must mean is ….."

Mary had to take a different tack.

XBRL versions

In discussing with her friend Raymond, he said "why don't you get them to submit in XBRL? All the reports from each country will be in the same taxonomy. You will only need to solve the comparability problem."

It took 6 months but finally Mary got the reports in XBRL. The UK reports were in the "UK GAAP" taxonomy. French reports were in an in-house taxonomy "Fr Sarkozy".

What Mary wants:

Mary now saw the wisdom of Raymonds words, when he said "the comparability problem wont be easy to solve".

Mary went to see John, someone she trusted from the IT department (the only person she trusted in the IT department).

"Why do you want to compare these? In real detail." was his first question.

Mary asks "why"

Mary had to go back to her desk to think. She saw 2 problems:

A) Politically, she had to show it was possible to compare the results of the 2 teams

B) How to produce an actual set of comparisons

i) A French company, its financials and the French teams recommendation

ii) A British company, where the financials where different to the French and the British teams recommendation

Mary knew that both teams would have there own approaches to B), that she could manage at the detailed level. But nothing would work if she could not get agreement to A)

5.3. Comparability language

This section describes how an end use might express their comparability requirements. This section is not intended to express a standard, but work through the issues on how an end user might want to express a comparison and see the result.

Worked examples

5.1. Feedback from review of version 0.4

NAME	FEEDBACK
BPB meeting 2012-04-03	Suggested including a statement about the relationship with other standards elements – e.g. Formula

[1] As At version 1.0 this has yet to be implemented fully.

[2] As at version 0.4 this section is under review by the modeling SME.

Name	Location
[1] XBRL Strategic plan
[2] XBRL Comparability brief
[3] XBRL Standards	http://www.xbrl.org/SpecRecommendations/
[4] XBRL Conformance Suites	http://www.xbrl.org/SpecRecommendations/
[5] XBRL Comparability Taskforce Sharepoint site	http://sharepoint.xbrl.org/INT-COMP/default.aspx
[6] MagicDraw Comparability model
[7] This document	http://sharepoint.xbrl.org/INT-COMP/Files/XBRL_comparability_taskforce_report_phase_1.docx
[8] XBRL Comparability White Paper (intro for XBRL Product Managers)	http://sharepoint.xbrl.org/INT-COMP/Files/XBRL%20Comparibility%20whitepaper%20-%202012-01-31.docx

1. Introduction

1.1. Purpose

1.2. Scope

1.3. Overview

1.4. Outstanding issues:

1.5. Stakeholder map

2. Use Cases

2.1. 01 Basic Comparison Use Case

2.1.1. Report XBRL Instance

2.1.2. Write Basic Assertion

2.1.3. Compare Basic XBRL Instances

2.2. 02 Investing Use Case

2.2.1. Report XBRL Instance

2.2.2. Pool XBRL

2.2.3. Write Basic Assertion

2.2.4. Assert Comparable Reporting Periods

2.2.5. Asserts Comparable Entities

2.2.6. Asserts Comparable Sets of Units

2.2.7. Asserts Comparable Concepts

2.2.8. Asserts Comparable Dimensions

2.2.9. Generate Investment Comparison

2.2.10. Write Comparison

2.2.11. Run Comparison

2.2.12. Publish result

2.3. 03 Benchmarking Use Case

2.3.1. Report XBRL Instance

2.3.2. Pool XBRL

2.3.3. Write Basic Assertion

2.3.4. Compare Against a Pool of XBRL Data

3. Business Requirements

3.1. Approach

3.2. Requirements versus needs

3.3. The tickback process

3.4. Business requirements

4. Appendix: Abstract domain model[2]

4.1. Comparability domain model

Attributes

Attributes

Attributes

Attributes

Attributes

Attributes

Attributes

Attributes

Attributes

Attributes

Attributes

Attributes

4.2. Investing Comparison Result

5. Appendix: Contributing work

5.1. Comparing companies Use Case

5.2. Structural implications use case

5.3. Comparability language

Worked examples

5.1. Feedback from review of version 0.4

4. Appendix: Abstract domain model [2]