1 Introduction

The XBRL Formulae specification [FORMULA] defines a syntax that can be used to express the rules for transforming information obtained from XBRL reports and their supporting discoverable taxonomy sets into XBRL facts.

The purpose of this specification is to extend the XBRL Validations specification [VALIDATION] introducing a new kind of assertion that reuses existing formula definitions to produce additional tests on XBRL reports. These tests check the consistency of calculated facts on each evaluation of the formula resources associated and the corresponding facts reported in the instance document.

This way, the same formula resource can be used to produce a new fact or to check the validity of a reported one. For instance, a regulator could use this kind of assertions to test the quality of data received, whereas producers of that information could have used the same formula resources to calculate derived facts consistently with the definition of the regulatory authority.

This kind of assertion facilitates the definition of business rules that perform checks like those set out in Example 1.

Example 1: Consistency assertions

The total amount of incomes reported for a company must be equal to the total amount of incomes result of the addition of the incomes reported by market segment, considering the precision of the fact reported and the precision of the fact calculated.
The difference between net incomes reported and net incomes calculated as the total incomes minus operation expenses, must be less than a 10% of the latter.
The difference between the ending balance reported and the ending balance result of the addition of the flows during the intervening period to the starting balance, must be less than an amount defined by an external parameter.

Many of the syntax constraints imposed by this specification are set out in the normative schema Appendix A. To eliminate the potential for conflicts, this specification only enunciates syntax features that are not expressed in the normative schema.

1.1 Background

This specification is a member of a suite of similar specifications that define specific types of tests that can be applied to the information contained in XBRL reports.

1.2 Relationship to other work

This specification builds on the foundation provided by the XBRL Validation specification [VALIDATION] and the XBRL Formulae specification [FORMULA].

1.3 Language independence

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

1.4 Terminology

This specification is consistent with the definitions of any of the terms defined in specifications that it depends on.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in [IETF RFC 2119].

1.5 Document conventions (non-normative)

Documentation conventions follow those set out in the XBRL Variables Specification [VARIABLES].

1.6 Namespaces and namespace prefixes

Namespace prefixes [XML NAMES] will be used for elements and attributes in the form ns:name where ns is the namespace prefix and name is the local name. Throughout this specification, the mappings from namespace prefixes to actual namespaces is consistent with Table 1.

The prefix column in Table 1 is non normative. The namespace URI column is normative.

Table 1: Namespaces and namespace prefixes

Prefix	Namespace URI
`formula`	`http://xbrl.org/2007/formula`
`validation`	`http://xbrl.org/2007/validation`
`ca`	`http://xbrl.org/2007/assertion/consistency`
`xbrlcae`	`http://xbrl.org/2007/assertion/consistency/error`
`eg`	`http://example.com/`
`fn`	`http://www.w3.org/2006/xpath-functions`
`link`	`http://www.xbrl.org/2003/linkbase`
`xbrli`	`http://www.xbrl.org/2003/instance`
`xfi`	`http://www.xbrl.org/2005/function/instance`
`xbrldi`	`http://xbrl.org/2006/xbrldi`
`xbrldt`	`http://xbrl.org/2005/xbrldt`
`xl`	`http://www.xbrl.org/2003/XLink`
`xlink`	`http://www.w3.org/1999/xlink`
`xs`	`http://www.w3.org/2001/XMLSchema`
`xsi`	`http://www.w3.org/2001/XMLSchema-instance`
`generic`	`http://xbrl.org/2007/generic`
`variable`	`http://xbrl.org/2007/variable`
`iso4217`	`http://www.xbrl.org/2003/iso4217`

1.7 XPath usage

XPath usage is identical to that in the XBRL Variables Specification [VARIABLES].

2 Syntax

This specification only provides a textual declaration of syntax constraints when those constraints are not expressed by the normative schema supplied with this specification.

Explanations of elements and attributes are only supplied when explanations are not already provided in other specifications.

Unless explicitly stated otherwise, a reference to a specific element MUST be read as a reference to that element or to any element in its substitution group .

2.1 Consistency assertions

A consistency assertion is a statement of expectations in relation to the consistency of facts in an XBRL instance with the values that can be derived for those from the same XBRL instance by processing formulae [FORMULA].

A consistency assertion is expressed by the <ca:consistency-assertion> element in the normative schema supplied with this specification.

A consistency assertion derived fact is any of the facts that can be produced from the evaluation of any of the formula in the consistency assertion formulae given a target instance document.

Which derived facts can be used to produce the evaluation of a consistency assertion can be controlled by the @strict boolean attribute at the assertion resource:

If the @strict attribute equals false, then only those derived facts that have corresponding facts in the target instance document MAY produce an evaluation of the assertion. Thus, the assertion will not produce an evaluation for those facts that can be derived from assertion formulae but are not present in the target instance.
If the @strict attribute equals true, then any derived fact MAY produce an evaluation of the assertion. Thus, the assertion will be evaluated for those facts that can be derived from formulae but are not present in the target instance.

Example 2: @strict attribute usage

`@strict` attribute	Facts in target instance	Assertion formula	Evaluated / not evaluated
`false`	a, b, c	a = b * c	Evaluated
`true`	a, b, c	a = b * c	Evaluated
`false`	b, c	a = b * c	NOT Evaluated
`true`	b, c	a = b * c	Evaluated (and not satisfied)

The acceptance radius of a consistency assertion is a number that represents the maximum difference between the numerical value of two facts for them to be considered consistent (see Section 4).

The acceptance radius can be defined in two different ways:

By an absolute, value result of the evaluation of the XPath expression at the @absoluteAcceptanceRadius attribute in the consistency assertion resource.
By a ratio, result of the evaluation of the XPath expression at the @proportionalAcceptanceRadius attribute in the consistency assertion resource.

If the former is defined, the acceptance radius is the result of the evaluation of the XPath expression at the @absoluteAcceptanceRadius attribute.

If the latter is defined, the acceptance radius is the result of the evaluation of the following XPath expression:

. * ( #proportionalAcceptanceRadius )

where #proportionalAcceptanceRadius is the XPath expression at the @absoluteAcceptanceRadius attribute.

The context for these two XPath expression MUST:

Have as context item and atomic value equal to numeric value of the derived fact.
In-scope variables MUST include assertion parameters

[Error: Error code xbrlcae:acceptanceRadiusConflict MUST be thrown if a consistency assertion sets a value for both the @absoluteAcceptanceRadius and @proportionalAcceptanceRadius attributes. ]

Example 3: Acceptance radius

Attribute / value	Derived fact value	Acceptance radius
No attribute defined	Any	Not defined
`@absoluteAcceptanceRadius` = `100`	Any	Not defined
`@absoluteAcceptanceRadius` = `$margin`	Any	Value of the parameter `margin`
`@proportionalAcceptanceRadius` = `0.5`	`500`	`250`
`@proportionalAcceptanceRadius` = `0.5`, `@absoluteAcceptanceRadius` = `500`	Any	Error: acceptance radius definition conflict

3 Fact consistency assertions relationships

3.1 Consistency-assertion-formula relationships

A consistency assertion MUST be associated with at least one formula through consistency-assertion-formula relationships:

A consistency-assertion-formula relationship is a relationship between a consistency-assertion and a formula expressed by an XLink arc.

To declare a consistency-assertion-formula relationship an XLink arc MUST:

have an arcrole value equal to http://xbrl.org/arcrole/2007/consistency-assertion-formula
have a consistency-assertion at the starting resource of the arc
have a formula at the ending resource of the arc

The arcrole value, http://xbrl.org/arcrole/2007/consistency-assertion-formula, is declared in the normative schema for consistency assertions.

Consistency-assertion-formula relationships MUST be expressed by generic arcs as indicated by the restrictions imposed by the arcrole declaration in the normative schema. Violations of this requirement will be detected by validation against the XBRL Specification [XBRL 2.1].

[Error: Error code xbrlcae:missingFormulae MUST be thrown if the consistency assertion has no consistency-assertion-formula relationships defined. ]

The set of formulae related to a consistency assertion by consistency-assertion-formula relationships are known as the consistency-assertion formulae.

A consistency assertion checks the consistency of reported facts with the facts produced by each one of the formulae determined by assertion-formula relationships, processed in an individual way. Thus, the tests implied by one consistency assertion associated with two formulae (f1 and f2), are equivalent to the tests implied by two consistency assertion, one associated to formula f1 and the other one associated to formula f2.

3.2 Consistency assertions variable-set relationships

A consistency assertion MAY be associated with parameters by consistency assertion variable-set relationships. A consistency assertion MUST NOT be associated with fact variables or general variables.

A consistency assertion variable-set relationship is a relationship between a consistency-assertion and a parameter expressed by an XLink arc.

To declare a variable-set relationship for a consitency assertion, an XLink arc MUST:

have an arcrole value equal to http://xbrl.org/arcrole/2007/variable-set
have a consistency-assertion at the starting resource of the arc
have a parameter at the ending resource of the arc

The arcrole value, http://xbrl.org/arcrole/2007/variable-set, is declared in the normative schema for XBRL Variables [VARIABLES].

[Error: Error code xbrlcae:factVariablesNotAllowed MUST be thrown if there is an arc with arcrole value equal to http://xbrl.org/arcrole/2007/variable-set, a consistency assertion at the starting resource of the arc, and a fact variable at the ending resource of the arc ]

[Error: Error code xbrlcae:generalVariablesNotAllowed MUST be thrown if there is an arc with arcrole value equal to http://xbrl.org/arcrole/2007/variable-set, a consistency assertion at the starting resource of the arc, and a general variable at the ending resource of the arc ]

A consistency assertion parameter is any of the parameters associated to a consistency assertion by variable-set relationships.

4 Test implied by fact consistency assertions

A fact consistency assertion is satisfied for an evaluation of one of its associated formulae if the value of the fact produced is consistent with the values of all its corresponding facts in the input instance document. Thus, the data set of a consistency assertion is made up of a derived fact plus the corresponding facts in the input instance. The following special cases must be taken into account:

If there are no corresponding facts for a derived fact and the @strict attribute of the assertion is set to false, then the assertion is not evaluated for that derived fact.
If the derived fact has a nil value, the assertion is satisfied if either there are corresponding facts with nil value or there are no corresponding facts and the @strict attribute is set to true. The assertion is not satisfied if there are corresponding facts with values other than nil
If there are no corresponding facts for a produced fact with a value different than nil and the @strict attribute of the assertion is set to true, then the assertion is not satisfied.

Example 4: Nil value combinations

`@strict` attribute	Derived fact value	Corresponding facts	Assertion evaluation
`false`	Any	Don't exist	Not evaluated
`false`	Nil	Nil	Satisfied
`false`	Nil	Not nil	Not satisfied
`false`	Not nil	Nil	Not satisfied
`true`	Nil	Don't exist or nil	Satisfied
`true`	Nil	Not nil	Satisfied
`true`	Not nil	Don't exist or nil	Not satisfied

The corresponding facts in an instance document to a produced fact, are those facts that verify the match filters inferred for the aspects defined by the chosen aspect model. These match filters use the produced fact as matched fact.

The aspect model is determined by the @aspectModel attribute at the formula resource that produces the derived fact.

This specification defines the set of inferred match filters for the two different aspect models specified by the XBRL Variables specification [VARIABLES] according to the following tables:

Table 2: Aspects and match filters defined for non-dimensional aspect model

Aspect	Match filter
the concept aspect	the concept matching filter
the location aspect	the location matching filter
the entity-identifier aspect	the entity-identifier matching filter
the period aspect	the period matching filter
the complete segment aspect	the complete segment matching filter
the complete scenario aspect	the complete scenario matching filter
the unit aspect	the unit matching filter

Table 3: Aspects and match filters for dimensional aspect model

Aspect	Match filter
the concept aspect	the concept matching filter
the location aspect	the location matching filter
the entity-identifier aspect	the entity-identifier matching filter
the period aspect	the period matching filter
a segment dimension aspect for each segment dimension	the segment dimension matching filter for the segment dimension
the non-XDT segment aspect	the non-XDT segment matching filter
a scenario dimension aspect for each scenario dimension	the scenario dimension matching filter for the scenario dimension
the non-XDT scenario aspect	the non-XDT scenario matching filter
the unit aspect	the unit matching filter

A produced fact and one of its corresponding facts have consistent values if they verify one of the following conditions:

If the type of the compared facts is not numeric, its content MUST be s-equal2.
If the type of the compared facts is numeric and the acceptance radius is not defined, its numeric values MUST be equal according to the definition of v-equal in the XBRL 2.1 specification [XBRL 2.1]. Note that a derived fact and its corresponding facts MAY be not c-equal depending on the set of match filters [MATCH FILTERS] inferred.
If the type of the compared facts is numeric and the acceptance radius is defined, its numeric values MUST verify the following XPath expression:
fn:abs(#producedFact - #correspondingFact) le fn:abs(#acceptance)
where #producedFact is the numerical value of the produced fact, #correspondingFact is the numerical value of the corresponding fact and #acceptance is the value of the acceptance radius.

Example 5: Consistent values

Derived fact		Corresponding fact		Acceptance radius	Assertion evaluation
Inferred precision	Value	Inferred precision	Value	Acceptance radius	Assertion evaluation
-	`foo`	-	`foo`	Any	Satisfied
-	`foo`	-	`bar`	Any	Not satisfied
`INF`	`315.5`	`INF`	`315.5`	Not defined	Satisfied
`INF`	`315.5`	`INF`	`315.50001`	Not defined	Not satisfied
`0`	`315.5`	`INF`	`1000000`	Not defined	Satisfied
`2`	`10`	`2`	`10.4`	Not defined	Satisfied
`2`	`10`	`3`	`10.4`	Not defined	Satisfied
`2`	`10`	`3`	`10.5`	Not defined	Not satisfied
Any	`10.0000001`	Any	`10.0000001`	`0`	Satisfied
Any	`10`	Any	`10.0000001`	`0`	Not satisfied
Any	`25`	Any	`30`	`5`	Satisfied
Any	`25`	Any	`30.000001`	`5`	Not satisfied

5 The processing model for consistency assertions

Consistency assertions MAY produce one evaluation for each derived fact by any of its formulae, taking into account the constrains entailed by the @strict attribute.

The prerequisites for the evaluation of this kind of assertions are the evaluation of the acceptance radius, should any of the attributes @absoluteAcceptanceRadius or @proportionalAcceptanceRadius be defined, the production of a fact according to any of its formulae and the selection of the corresponding facts in the target instance (that MUST exist if the @strict attribute equals false). Once these prerequisites are verified, a consistency assertion evaluation entails the testing of the consistency of the derived fact and its corresponding ones (if any), according to the rules defined in the Section 4.

Appendix A Normative schema

The following is the XML schema provided as part of this specification. This is normative. Non-normative versions (which should be identical to these except for appropriate comments indicating their non-normative status) are also provided as separate files for convenience of users of the specification.

NOTE: (non-normative) Following the schema maintenance policy of XBRL International, it is the intent (but is not guaranteed) that the location of non-normative versions of these schemas on the web will be as follows:

While any schema is the most current RECOMMENDED version and until it is superseded by any additional errata corrections a non-normative version will reside on the web in the directory http://www.xbrl.org/2007/ - during the drafting process for this specification this directory should contain a copy of the most recent published version of the schema at http://www.xbrl.org/2007/consistency-assertion.xsd.
A non-normative version of each schema as corrected by any update to the RECOMMENDATION will be archived in perpetuity on the web in a directory that will contain a unique identification indicating the date of the update.

<link:definition>

assertion based on formula

</link:definition>

<link:usedOn>

generic:arc

</link:usedOn>

</link:arcroleType>

</appinfo>

</annotation>

</extension>

</complexContent>

</complexType>

</element>

</schema>

Appendix B 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)
FORMULA: XBRL International Inc.. "XBRL Formulae 1.0, Public Working Draft"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See formula-PWD-2007-12-31.html)
GENERIC LINKS: XBRL International Inc.. "XBRL Generic Links 1.0 (Public Working Draft)"
Mark Goodhand, Ignacio Hernández-Ros, and Geoff Shuetrim.
(See http://www.xbrl.org/Specification/XGL-PWD-2007-04-24.rtf)
IETF RFC 2119: IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.
(See http://www.ietf.org/rfc/rfc2119.txt)
MATCH FILTERS: XBRL International Inc.. "XBRL Match Filters 1.0, Public Working Draft"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See matchFilters-PWD-2007-12-31.html)
VALIDATION: XBRL International Inc.. "XBRL Validations 1.0, Public Working Draft"
Victor Morilla, and Geoff Shuetrim.
(See validation-PWD-2007-12-31.html)
VARIABLES: XBRL International Inc.. "XBRL Variables 1.0, Public Working Draft"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See variables-PWD-2007-12-31.html)
XBRL 2.1: XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1"
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-2006-12-18.htm)
XLINK: W3C (World Wide Web Consortium). "XML Linking Language (XLink) Version 1.0"
Steve DeRose, Eve Maler, and David Orchard.
(See http://www.w3.org/TR/xlink/)
XML NAMES: W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Second Edition)"
Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin.
(See http://www.w3.org/TR/REC-xml-names/)
XML SCHEMA STRUCTURES: W3C (World Wide Web Consortium). "XML Schema Part 1: Structures Second Edition"
Henry S. Thompson, David Beech, Murray Maloney, and Noah Mendelsohn.
(See http://www.w3.org/TR/xmlschema-1/)
XPATH 2.0: W3C (World Wide Web Consortium). "XML Path Language (XPath) 2.0"
Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon.
(See http://www.w3.org/TR/xpath20/)

Appendix C 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 D Acknowledgements (non-normative)

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

Appendix E Document history (non-normative)

Date	Author	Details
30 June 2007	Geoff Shuetrim	Initial draft created.
22 July 2007	Geoff Shuetrim	Converted to XML format.
15 October 2007	Geoff Shuetrim	Adapted to XBRLspec syntax.
25 November 2007	Victor Morilla	Split from validation report specification Adapted and included variable, group filter and precondition augmentation
26 November 2007	Geoff Shuetrim	Modified the definition of a consistency assertion. Changed the consistency-assertion element name to camel case to conform with the naming convention used by other XBRL specifications. Eliminated the default value for the strict attribute on consistency assertions to conform to the broader approach of always being explicit at the syntax level.
03 December 2007	Victor Morilla	Simplified and adapted to new variables specification Included an acceptance radius as suggest by G.S Included possibility of parameters to determine the acceptance radius as suggest by H.F
04 December 2007	Victor Morilla	Moved assertion-formula relationship to this specification as suggested by G.S Removed obsolete comments
06 December 2007	Victor Morilla	Included examples Removed obsolete comments Description of `@strict` rewritten References to the definition of the assertion data set
09 December 2007	Victor Morilla	consistency-assertion-formula relationships now used on generic:arc `@aspectModel` attribute obtained from formulae producing fact instead of the assertion resource
10 December 2007	Victor Morilla	Adapted to be in the SG for assertions (not in the SG for variables). General variables associated with assertions removed
16 December 2007	Victor Morilla	Changed namespace of consistency assertions from http://xbrl.org/2007/consistency-assertion to http://xbrl.org/2007/assertion/consistency

Appendix F 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 Formula Working Group up to and including 31 December 2007 . 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.

Added comments and feedback on various aspects of defining what constitutes confirmation of the assertion.

No errata have been incorporated into this document.

Consistency Assertions 1.0

Public Working Draft 31 December 2007

Status

Abstract

Table of Contents

Appendices

Tables

Examples

Definitions

Error codes