XBRL Instance Validation Requirements
Recommendation dated 2009-06-22
Copyright © 2006-9, XBRL International Inc., All Rights Reserved
This version:
	Validation-REQ-REC-2009-06-22.rtf
is normative. Any other formats and versions are non-normative.
Editors
Victor Morilla	victor.morilla@bde.es	Banco de España	
Geoff Shuetrim	geoff@galexy.net	Galexy	
Abstract
This requirements document remains unchanged from that published with the the first set of candidate recommendation specifications for XBRL validation against business rules.  This document sets down the requirements that are guiding the XBRL instance validation and supporting specifications.
Status
Circulation of this Candidate Recommendation is unrestricted.  Recipients of this draft are invited to submit comments to the editors, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Table of Contents
1Overview	3
2Introduction	3
3.1.1An instance contains exactly one fact with a specified set of aspects	4
3.1.2An instance contains at least one fact with a specified set of aspects	4
3.1.3An instance contains no fact with a specified set of aspects	4
3.1.4An instance contains at least one of a specified set of facts	4
3.1.5An instance contains at least one of a specified set of facts	4
3.1.6An instance contains a footnote for a given fact	5
3.2.1An instance contains a set of facts that are consistent with each other according to a deterministic formulaic relationship	6
3.2.2An instance contains a set of facts that are consistent with each other according to a non deterministic formulaic relationship	6
3.3.1An instance contains a fact with a value that is within a given range	7
3.3.2An instance contains a fact with a value that is within a variable range	7
4Requirements	9
A.References (non-normative)	11
B.Intellectual Property Status (non-normative)	11
C.Acknowledgements (non-normative)	11
D.Approval process (non-normative)	11
E.Document history (non-normative)	11

Formatting
The following highlighting is used for non-normative examples in this document:
	
Non-normative editorial comments to be removed from final recommendations are denoted as follows:
GCS: This highlighting indicates editorial comments about the current draft, prefixed by the editor’s initials.
Italics are used for rhetorical emphasis only and do not convey any special normative meaning.
1	
Overview
An important feature of XBRL is its ability to declare not only business concepts definitions, but rules to constrain the set of expected values of facts reported according to those business concepts. For instance:
•	Summation-item arcs define how some concepts can be calculated as the aggregation of other ones.
•	Requires-element arcs test for the presence of a concept if other concept is reported in an instance document.
•	XML Schema typing allows constraints on the range of valid values of individual concepts.
•	XBRL Dimensions specify how to limit the set of allowed dimension values of primary items reported.
Given these kind of rules, consumers of XBRL instance documents can use the result of the validation performed by a XBRL processor, for instance, to assess the validity of the information managed. This facility has been widely adopted to improve the quality of data in regulatory and other reporting environments.
As XBRL is being adopted more broadly, there is a growing demand for standardised definitions of more complex validation rules. This document describes an extensive set of use cases relating to XBRL instance validation.  These use cases underpin a list of XBRL instance validation requirements.
2	
Introduction
This introduction establishes terminology that serves throughout the remainder of the document.
Validation of an XBRL instance involves testing that instance against a set of assertions.  Formulae can be interpreted as assertions.  However, assertions can take forms that may not be best expressed as formulae.  An XBRL instance can contain zero or more data sets for which a given assertion can be tested. When tested, an assertion always returns either true or false.
Validation of an XBRL instance involves choosing an assertion set, optionally passing a set of parameters  and testing the assertions in that set against the XBRL instance.  An XBRL instance is valid, according to an assertion set and a set of parameters, if and only if all required assertions in that assertion set are found to be true for all sets of data in the instance against which they can be tested.
3	
Example assertions
3.1	Existence assertions
Existence assertions are used to test for the existence or absence of data in XBRL instances.

3.1.1	An instance contains exactly one fact with a specified set of aspects
In some cases, it can be useful to test the for the presence of one and only one fact with a specific set of aspects. These aspects can refer to any field in the context of that fact (period, scenario, entity, user dimensions, ...), to its unit or to any other attribute (precision, decimals, containing tuple structure, ...).  Note also that the set of aspects need not be exhaustive.
e.g.: total assets measured in USD as at December 31, 2006, for ACME Inc.
e.g.: total assets with an entity, period and scenario and units as specified by parameters provided at validation time.
e.g.: total assets measured in any units as at December 31, 2006, for ACME Inc.
e.g.: total assets measured in USD as at December 31, 2006, for ACME Inc., with a precision of at least 1.
e.g.: total assets measured in USD as at December 31, 2006, for ACME Inc., that is accurate to at least -3 decimal places.
3.1.2	An instance contains at least one fact with a specified set of aspects
This is a similar case to the previous one, but more than one occurrence of the required fact is allowed.
e.g.: total assets measured in any units as at a date after December 31, 2004, for ACME Inc.
e.g.: director name as a child of an executive remuneration tuple for the year ending December 31, 2006, for ACME Inc.
e.g.: a total remuneration item contained in a director's remuneration tuple (note the exclusion of the date and reporting entity from the specified set of aspects).
3.1.3	An instance contains no fact with a specified set of aspects
In other cases, it is useful to test for the absence of some facts in an instance document.
e.g.: share of profit from equity-accounted associates should not be reported for ACME Inc. (as it is an individual company).
e.g.: total assets in any units for a date prior to January 1, 2006 for ACME Inc.
3.1.4	An instance contains at least one of a specified set of facts
At times it can be useful to test an assertion that at least one of a specified set of facts is contained by an XBRL instance.
e.g.: An instance contains a bank capital adequacy ratio measured under an advanced IRB approach or under a standardised approach for December 31, 2008 for ACME Inc.
3.1.5	An instance contains at least one of a specified set of facts
At times it can be useful to test an assertion that exactly one of a specified set of facts is contained by an XBRL instance.
e.g.: An instance contains a bank capital adequacy ratio measured under a standardised approach, an IRB approach, or an advanced IRB approach (but not both) for December 31, 2008 for ACME Inc.
e.g.: Current address or date of death can be reported, but not both.
3.1.6	An instance contains a footnote for a given fact
Sometimes, checking for the presence of a fact is not enough, and qualitative information can be required in the form of a footnote. Although the end consumers of the content of these footnotes are human beings rather than software, some basic testing can be useful, for instance, to assure that the footnote is not empty.
e.g.: Bank capital adequacy ratio for December 31, 2008 has a footnote for December 31, 2008 for ACME Inc.
e.g.: Total Incomes have a footnote whose content is not empty.
3.2	
Internal consistency assertions
Internal consistency assertions involve specifying a formulaic relationship that must be found to hold for the data in an XBRL instance.
3.2.1	An instance contains a set of facts that are consistent with each other according to a deterministic formulaic relationship
Some formulaic relationships specify how a fact (or a set of facts) can be calculated given a set of input facts. This kind of relationship can be used to test for the consistency of computed facts compared to reported facts. The word “consistency” is used herein to remark that the equality of two facts can only be asserted when its precision is infinite. A reported fact is said to be consistent according to a formula if the interval of the computed fact has a non empty intersection with the interval of the reported value (see calculation involving decimals and precision on XBRL 5.2.5).  For some assertions, in the event that a consistency checking formula cannot be evaluated because the instance does not contain the necessary data, then the assertion must be deemed to be not testable for the instance being tested.  Users can choose how they wish to handle situations where some of the assertions are not testable for an XBRL instance.
The calculated fact and the reported fact need to have the same context and unit to confirm consistency.
e.g.: Risk weighted exposure amount can be calculated as the total exposure amount multiplied by a factor of 0.8. Both amounts in an instance document must be consistent according to this relationship and taking into account its reported precision.
e.g.: Total income of a company can be calculated as the aggregation of its income by product (where product is represented as a dimension). Reported values must be consistent with this relation.
The precision of computed and reported facts determines a tolerance level for this kind of assertion. However, in some cases, a user defined tolerance level can be very helpful:
e.g.: total assets, current assets and non-current assets are all reported in USD for December 31, 2008 for ACME Inc, and the value of total assets is equal to the value of current and non-current assets, within a tolerance level specified as part of the assertion.
e.g.: total assets, current assets and non-current assets are all reported in USD for September 31, 2008 and for December 31, 2008 for ACME Inc, and the value of total assets is equal to the value of current and non-current assets for both periods, again within a tolerance level specified as part of the assertion (as either an absolute value or as a percentage).
e.g.: If total assets, current assets and non-current assets are reported, then their values must be consistent with the formula stating that the value of total assets is the sum of the values for current and non-current assets.
e.g.: The reported annual growth in market capitalisation, matches the market capitalisation reported as at the beginning of the period and the end of the period for which the growth rate was reported.
3.2.2	An instance contains a set of facts that are consistent with each other according to a non deterministic formulaic relationship
Some formulaic relationships specify how the set of possible values for a concept is constrained, but not determined, by the value assigned to other related concepts.
e.g: Total incomes of a group of companies must be less than or equal to the summation of the individual incomes for each company.
e.g: Total funds for solvency of a bank must be greater than its capital requirements.
3.3	Value range assertions
Value range assertions involve specifying an acceptable range of values for a fact.  The range can be degenerate, in which case the assertion is that a fact has a specific value.  Ranges can be specified in terms of combinations of less than, greater than, less than or equal, greater than or equal, equality, and inequality relations.
Although XML Schema types provides a powerful means of constraining the set of possible values for a fact, it has some important limitations:
●	XML Schema types constrain just the lexical value of a fact. Precision and decimals attributes are ignored.
●	A value range assertion can be a part of a more complex assertion. For instance: if A>0 then predicate1 else predicate2.
●	The schema type of a concept cannot be modified by an extending taxonomy.
●	The restrictions on the valid range may only be relevant in some reporting contexts.
Where these limitations on XML Schema types are relevant, assertions about allowable values for certain types of facts can be useful.
3.3.1	An instance contains a fact with a value that is within a given range
e.g.: The interest cover ratio reported in an instance for the year ending December 31, 2008 for ACME Inc. is above 2.
e.g.: The interest cover ratio computed from EBIT and interest paid as reported in an instance for the year ending December 31, 2008 for ACME Inc is above 2.
e.g.: The name of the entity as reported in an instance for the year ending December 31, 2008 for the entity with identifier “ACME” is ACME Inc.
e.g.: The country code fact in an address tuple is “NL” for the Netherlands.
e.g.: The interest cover ratio reported in an instance for the year ending December 31, 2008 for ACME Inc. is above 2 but below 5.
3.3.2	An instance contains a fact with a value that is within a variable range
The variable range is generally a function of other data from the XBRL instance.
e.g.: The tier 1 capital ratio must be more than 50% of the tier 2 capital ratio in for December 31, 2003 for ACME Inc.
e.g.: total costs is greater than to personnel costs.
e.g.: initial cost of purchase for an asset is greater than or equal to the depreciated value of the same asset.
3.4	Assertion preconditions
Some assertions only need to hold for the data sets in an XBRL instance that satisfy a set of preconditions. Note that preconditions can be satisfied for some data sets but not for others.
e.g.: For the year ended December 31, 2008, an instance contains an interest cover ratio over 3 if the industry code indicates that ACME is in the agriculture industry as indicated by the industry code fact.
e.g.: Tier 1 capital represents at least 80% of total capital if the financial institution is classified as a regional bank.
3.5	Alternative assertions
Some assertions are such that one or the other assertion must hold but both do not need to.
e.g.: Depreciation is calculated in one of two different ways, both of which are acceptable. The assertion is that reported depreciation is consistent with one or the other of the depreciation methods, and the data in the instance is sufficient to check the value of depreciation using one or the other method.  This is trying to motivate the notion that an assertion can be driven by more than one formula – in this case, there would be two formulae (one for each depreciation method) that are leveraged by the assertion.
e.g.: Depreciation is calculated one way prior to a particular change in accounting standards and in another way following the change in accounting standards.  The assertion is that depreciation is calculated in a manner that is consistent with accounting policies so the formula to test reported depreciation against has to depend on the period associated with reported depreciation values.
3.6	Multiple assertion tests for a single instance
Users need to be able to identify that a particular assertion is tested the right number of times against an XBRL instance.  In the event that an XBRL instance in that class does not contain enough datasets to support the required number of tests of the assertion, the XBRL instance is invalid.
e.g.: The assertion is that the remuneration is reported for a director.  Director remuneration is reported in tuples.  An instance contains a fact describing the number of directors in the company.  The assertion needs to be shown to hold for a number of datasets in the XBRL instance that is equal to the number of directors in the company.
e.g.: The assertion is that assets = current assets + non current assets.  Valid instances are required to contain two occurrences of assets, current assets and non current assets, one for this year and one for the previous year.  The assertion needs to be tested twice for the instance to be deemed valid.
Note that these use cases could be covered by creating an assertion set that included a range of fact existence tests along with the test of aggregation consistency.  Perhaps being able to specify an exact number of times for an assertion to be tested is unnecessary.
3.7	Assertion composition
Assertions can need to be grouped so that validation engines can identify the sets of assertions to test.  Sets of assertions can need to be defined in terms of individual assertions that are included or other sub-sets of assertions that are included.  Sets of assertions can also need to be specified such that one or the other subset of the complete set of assertions needs to be satisfied.
e.g.: Bank capital adequacy ratio for December 31, 2008 has a footnote if its value is below 8% for December 31, 2008 for ACME Inc.
e.g.: The initials of a person are to be reported in the instance and the last name of the person is to be reported in the instance.  This is two fact existence assertions that need to be tested together.
e.g.: Two kinds of forms can be submitted to a regulator.  The set of assertions to be applied depends on the form that is submitted.  An author of validation rules needs to specify that either one of two sets of assertions needs to be satisfied, but not both.
4	
Requirements
4.1	Assertions
Users MUST be able to declare assertions.
Users MUST be able to group assertions into assertion sets.
Users MUST be able to include a given assertion in more than one set.
Users MUST be able to associate preconditions with an assertion.
Preconditions MUST be able to be associated with an assertion as used in an assertion set rather than just for the assertion itself (this is useful if the precondition is only relevant for the assertion in a particular validation context).
Users MUST be able to identify alternative assertions, only one of has to be satisfied, in an assertion set.
Users MUST be able to identify the treatment of the assertion (whether it is deemed to have failed or not, or to be indeterminate) if the instance does not contain sufficient data to test the assertion).
4.2	Validation results
Validation results for a given XBRL instance MUST include:
●	A Boolean value for each assertion test against the XBRL instance where true indicates that the assertion was confirmed by the test
●	Identification of the instance data drawn upon in the assertion test that generated the Boolean result
●	Identification of the assertion tested to generate the Boolean result
Should validation results for a given XBRL instance also include:
●	Identification of the parameters used to initialise each assertion test; or
●	Identification of any required assertion tests that could not be performed because the data in the XBRL instance was insufficient?
4.3	Assertion parametrisation
Users MUST be able to parametrise assertions at testing time, setting values in ways that constrain the aspects over which the assertion is expected to be tested for a given instance.
Users MUST be able to parametrise preconditions.

A.	
References (non-normative)
[RFC2119]	Scott Bradner
Key words for use in RFCs to Indicate Requirement Levels, March 1997
http://www.ietf.org/rfc/rfc2119.txt
	
[XBRL]	Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis.
Extensible Business Reporting Language (XBRL) 2.1 Recommendation with corrected errata to 2006-12-18.
http://www.xbrl.org/SpecRecommendations/	
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).
C.	Acknowledgements (non-normative)
This document is a result of careful consideration by the participants of the XBRL International Formula Working Group.  The XBRL International Formula Working Group is chaired by Geoff Shuetrim (Galexy) and vice chaired by Herman Fischer (UBMatrix).
D.	Document history (non-normative)
Date	Editor	Remarks	
2007-12-31	Geoff Shuetrim	First PWD version created from the requirements documentation agreed by the FWG.	
2008-03-12	Geoff Shuetrim	Updated to CR status.	
2008-11-03	Geoff Shuetrim	Updated for second CR.	
2009-04-10	Herm Fischer	Updated for PR.	
2009-06-22	Herm Fischer	Updated for REC.	

E.	Approval process (non-normative)
These requirements have been developed following the XBRL Technical Working Group Processes: http://www.xbrl.org/XSB/XBRL_Technical_Working_Group_Processes-Approved-2007-04-17.htm