Login

This Practice Profile document explains the features available in the Assertion Severity Specification for categorizing validations build through XBRL Formulas. This document is not intended to explain technical implementations of Assertion Severity Specification. The features explained here are based on Assertion Severity1.0, Recommendation 19 April 2016.

Target audience

It is primarily targeted towards audience seeking a basic understanding of the technical specification.

This document is a review draft. Circulation is restricted to members of XBRL International. Readers are invited to submit comments to the Implementation Guidance Task Force.

Editors

  • Revathy Ramanan
  • Paul Warren

Contributors

  • Carol Baskey
  • Shilpa Dhobale
  • Kathryn Dobinson
  • Pierre Hamon
  • Ian Hicks

This practice profile discusses Why Assertion Severity is required, What features it offers, How it’s beneficial and Where to look for more information.

WHY (it’s needed)

The quality of a reporting is assessed by validation rules. Usually not all validation rules imply erroneous reporting. Some rules are to be strictly complied with while others may be built to flag exceptional scenarios which may or not be issues in reporting. The Assertion Severity specification allows taxonomy authors to achieve this categorisation of validations built using XBRL Formula rules.

WHAT (it offers)

The specification allows classification of validation rules into three severity categories: ERROR, WARNING and OK as described in Figure 1.

Figure 1: Category of Validation Rule

“ERROR” category of validation rule obligates full compliance for all filings. If this validation rule fails then it will result in the report being rejected . Example of such validation rules can be Asset should be equal to Total Equity and Liabilities. Another example of such “ERROR” rule could be Number of Accounts" must be greater than equal to zero.

“WARNING” category of validation rule are cautionary in nature or do not apply to all filers. This rule gives flexibility in terms of compliance required. If this validation rule fails then the report will not necessarily be rejected and just cautions for a possible inaccuracy. Example of such rule can be Balance - beginning of Year as compared to Balance - End of Year excess the threshold of ± 20%. Another example could be value reported for ‘Revenue’ is negative (as usually expected to be a positive value).

Finally, the specification provides an “OK” category, which is intended to convey a result that is purely informational and is not indicative of any issue, or potential issue, with the report. Use of this severity level is discouraged in public taxonomies, as inclusion of such results is likely to cause confusion for users.

HOW (it benefits)

  • On the event of the validation rule failure, the categorisation will help preparer /reviewer of XBRL reports to assess the severity of non-compliance with the rule. This assessment will guide them to take next actions with regards to validation rule failure.

  • Submission success rates will increase, benefitting both preparer and receiver of reports. For the preparer, it will mean reports are not rejected for trivial reasons.

  • The severity categorisation being available within the taxonomy can be processed by XBRL compliant applications and users can be accordingly guided. In absence of such categorisation within the taxonomy, reference to a proprietary external list would be required which will be implementation specific customization.

WHERE (it’s applied)

Taxonomies that have implemented Assertion Severity specification are

  • IFRS Formula Linkbase 2016
  • EIOPA Solvency II Taxonomy 2.1.0
  • EBA CRR / CRD IV Taxonomy 2.6

Further Reading

This document was produced by the Implementation Guidance Task Force.

Published on: 2017-11-22.


Was this article helpful?

Related Articles


Newsletter
Newsletter

Would you like
to learn more?

Join our Newsletter mailing list to
stay plugged in to the latest
information about XBRL around the world.

By clicking submit you agree to the XBRL International privacy policy which can be found at xbrl.org/privacy