Formula assertions can have only one of two outcomes: true or false. From the business perspective there is however the need to place a nuance on the outcome. The result of an assertion can be either 'as expected', 'in error' or 'a warning'. This requirement describes the required nuance.
The XBRL Assertion Severity 1.0 specification provides a static mechanism for this, but does not provide a means for dynamic specification of severity.
This document restates the requirements including an addition to the Assertion Severity specification that addresses dynmaic specification of severity.
All formula assertions specifications value-assertions, existence-assertions and consistency-assertions define a standard XML-based syntax for validations on XBRL business reports.
The technical nature of an assertion is that the result is either true or false. These specifications have deliberately not prescribed whether true or false is a situation that should be recognized as an error.
From a business perspective more results from an assertion can be expected. Besides the result being 'OK' or 'error', the severity of the 'error' situation needs to be expressed.
The requirement for placing this severity indicator does NOT prescribe the reason or the number of nuances that can be placed on the 'erroneous' situation, all that is required is that a nuance can be made.
A complementary requirement to the severity placed on the outcome of the assertions is that each severity can be equipped with an appropriate message text. These messages are similar to the existing messages specification and can use aspects of the assertion in their content.
No requirement is made on the consequences of the severity reported. It is left to the software or user evaluating the results if any sorting or filtering is in order.
It IS required however, that the severity is part of the reported message to prevent assertion creators to structure the message content with a structural severity level aspect.
Tax filings have a level of rules that prevents users to file their report. This has legal consequences since not filing in time causes fines and other problems for the reporter. In general errors of this nature tend to be syntax oriented or completeness oriented. For other rules the severity is less. Filing is allowed but tax internal reviewing is needed to assess if the situation is in error or still a possibility.
These rules include rounding problems, incorrect summations or situations that on first glance contradict. These situations should not prohibit the user from filing, but it would be better if these situations are detected and brought to the attention of the reporter in a way that is best described as 'are you sure you want to file this situation?'.
The Dutch central bank (DNB) is using the European Banking Authority (EBA) taxonomy to collect reports from commercial banks. EBA has defined approximately 1800 business rules as assertions. The results of these assertions is always an 'error' that primes the supervisor to inspect the filing. DNB is however planning on creating complementary assertions on this taxonomy. These complementary rules MUST NOT prevent the reporter to file with DNB since the instance can be 'EBA legitimate'. Applying a result that places a 'warning' on the outcome of the DNB specific assertions allows both reporter and DNB to take appropriate action without disturbing the filing process to EBA.
Having the ability to set the severity level dynamically would avoid coding the same check twice just to have a different treatment in different situations.
A regulator could treat failing an assertion differently depending on the type of data requested. For example, failing a consistency check for a scheduled report would be treated as an error and the regulator would reject the file. In the case of a filing in response to an ad-hoc data request from a regulator, the same consistency check would be treated as a warning and the regulator would accept the file as the intent is to collect the data and study it.
A regulator could choose to treat reports differently based on the magnitude of any discrepency found when validating rules. For example, small differences in between calculated and reported values may result in the report being accepted with warnings, but any large differences would be treated as errors and cause the report to be rejected.
The following requirements were considered, but deemed to be out of scope.
| Date | Author | Details |
|---|---|---|
| 20 February 2014 | Roland Hommes | First draft created |
| 23 September 2015 | Paul Warren | Updated to reflect agreed reduction in scope. |
| 27 August 2020 | Herm Fischer | Added dynamic severity (and reformatted from s4s to md) |
| 07 July 2021 | Paul Hulst | Clarification of dynamic severity use cases |