Practice Profile: Implementing Business Validation Rules

Abstract

This topic focuses on alternatives available to incorporate business validation rules as part of the XBRL program. This document includes analysis and comparison of the alternatives and guidance for the implementers. This document is not intended to explain the technical implementation of the alternatives.

Need

Enhanced data quality and accuracy is one of the main benefits that has fostered the adoption of XBRL globally. The technical/syntax level standardisation is well taken care of by the suite of XBRL technical specifications. Further, the ability to define business logic at taxonomy level is making XBRL a natural choice for enhancing financial and non-financial data collection and consumption processes as well as digitising documents.

The users of XBRL data often validate and cross-check the information to assess the accuracy and consistency of information, before actually using the data for their intended purposes. Typically the checks include, but are not limited to:

• Whether the data is complete
• Whether numbers are reported with correct signs
• Whether the numbers sum up correctly
• Whether the facts are consistently reported throughout the report
• Whether data for related data points have been reported appropriately

These types of checks are referred to as business validation rules. The checks related to the structure of file and conformance to specifications, are referred to as syntactical rules. Validation rules as a whole consist of both syntactical checks and business validation rules introduced by the implementers of the XBRL reporting system. Implementers here could refer to those who are either setting up a platform to collect XBRL reports or data consumers who are looking to use XBRL reports for analysis and other purposes. Some implementers perform both functions of collecting and analysing data. A regulatory body is a classic example of an implementer who would be collecting the data as well as consuming the data.

Figure 1: Validation

This paper focuses on business validation rules of reported XBRL. and covers the available alternatives, commonly followed approaches, and some notable points when implementing business validation rules. The document is targeted at those needing to include business validation rules as part of an XBRL implementation program.

Using XBRL for Validating the Reported Data

Business validation rules are needed to ensure the quality, accuracy and completeness of information within an XBRL report. Accordingly, there can be numerous checks and queries which can be defined for and around the reported data. While such business validation rules can be defined using proprietary methods by the implementer (e.g., regulator), the advantage of using the XBRL framework (primarily through the taxonomy) is that the business validation rules are -

• Defined in a consistent, transparent manner
• Accessible to all users of the taxonomy (e.g., XBRL document preparers, data users/consumers)
• Ensures data quality right from the creation stage of XBRL report
• Reduces dependency on proprietary software applications

The taxonomy specifies the disclosure requirements for an XBRL report and thus making it the most obvious choice is to define the business validation rules. Also, this helps to make available the business validation rules, to all the users of the taxonomy, including preparers of XBRL documents, analysts, investors, regulators, software vendors and others. However, it is important to note that:

Validation Process

For any validation, the input needed is an XBRL report and this document will refer to the XBRL taxonomy.

Figure 2: Validation Method

The method of processing and displaying the validation result is application specific.

Defining Business Validation Rules

Defining business rules in the taxonomy

The taxonomy reflects the disclosure and the business requirements for the implementation program. Using taxonomy components, it is possible to define different types of business validation rules and at different levels.

Figure 3: Defining Rules

Defining business validation rules at concept level

The basic properties of elements such as data type, period of measurement etc. are defined in the taxonomy. The data in an XBRL report is then validated against these properties, and this facilitates testing the basic validity of individual reported values.

For example, if the taxonomy has a concept defined as “Country of Operations”, it is possible to specify that the value reported against this element can take names of either selected countries or all countries. With these types of rules, it becomes mandatory that the concepts can be reported only with allowed values

Business validation rules defined at the concept level have the useful property that they can be tested independently of other data, allowing the validity of individual values to be tested without assembling a complete XBRL instance document. This allows XBRL creation tools to provide feedback on the validity of individual values directly to the user.

Defining calculation constraints

As the name suggests, business validation rules that specify calculation constraints between the concepts can be built in the taxonomy. These constraints, however, are limited to the basic arithmetic operations of addition and subtraction. There is a weighting factor that needs to be applied that determines whether the values need to be added or subtracted in order to arrive at the total. The sign of weight i.e. plus (+) or minus (-) indicates how the value is to be treated in the calculation. The commonly followed practice is to specify the weights as +1 (when the value is to be added) and -1 (when the value is to be reduced). However, any weights other than +1 or -1 can be used for defining calculation constraints.

Calculation constraints defined in this way will be applied where:

• the total and at least one of the child components value are reported
• the contextual information for all values involved in the calculation, such as period and any dimensional qualification, are the same
• concepts are of numeric nature

With these conditions to be met, there are limited types of calculation rules that can be built. Calculation constraints are generally defined for data which has a linear hierarchy, for example the primary financial statements - Statement of Financial position (or Balance Sheet), and Income statement. Most of the calculations in these statements can be defined in the taxonomy using calculation constraints.

Defining Business Validation Rules using XBRL Dimensions

Data that is to be reported in XBRL could be multi-dimensional in nature, thus requiring more than just a primary concept and standard contextual information (such as period) to correctly model it. This can be addressed using XBRL Dimensions, which can define the allowed dimensional combinations for a fact. For any given data set, if relevant, the process of identifying and classifying the data into line items and dimensions is required for developing taxonomy. XBRL dimensions usually come into picture when the data sets are complex and could have many aspects or many criteria can be applied to slice and dice the data.

Using XBRL Dimensions, it is possible to create sub-sets or groups of information having similar characteristics. This is particularly important when a general way of classification is adopted, however, there could be exceptions to certain combinations of characteristics (e.g., a situation in which the combination of the line item and the characteristic identified may not be valid).

For example, the table below is a hypothetical extract of information to be disclosed for goods sold by a company. The example considers goods are sold in wholesale from the manufacturing division or sold through retail locations. Thus, for sales made through the manufacturing division, there would be no transportation cost involved, while for retail sales there would be no discounts for bulk orders.

Figure 4: Sample Disclosure

If this table is modelled using XBRL Dimensions, then rules to ensure that only valid combinations can be reported can be handled to a large extent by selecting the alternatives offered by XBRL Dimensions.

Defining rules using XBRL Formula

XBRL Formula has been designed to allow validation rules to be captured within an XBRL taxonomy. It can be used to model any kind of mathematical, logical and user defined formulae and these formulae can cover data sets which are modelled using XBRL Dimensions. It should be noted that XBRL Formula is a generic language for writing the business validation rules and hence can be used to define any type of business validation rules, including the categories mentioned in the above sections.

XBRL Formula allows the creation of rules involving multiple facts, which may be of similar or are completely different in terms of type, period or dimensions.. Business rules which require certain conditions to be fulfilled or need to be checked within acceptable tolerance margin can also be defined using XBRL Formula. Additionally, there is provision to define parameters and perform validations using the input provided for the parameter.

Defining messages for validation result and classification of the severity level of rules (i.e., whether error or warning) are some additional features which can be implemented using XBRL Formula.

The following table summarises some common categories of business validation rules implemented through XBRL Formula:

Comparative analysis: Defining Business Validation rules in taxonomy

The following table summarises the alternatives and mechanisms provided by the taxonomy components for defining business validation rules:

Using some of the common categories of business validation rules, a comparative summary is presented below:

Defining business rules outside the taxonomy

All the business validation rules discussed so far were mainly around the data that gets reported in an XBRL report. There could be business validation rules that may require the reported data to be compared to some already available data existing in databases or some other format or with historic filings. Additionally, there could be some business validation rules for ensuring consistency and standardisation of reporting the data in the XBRL report submitted previously or XBRL reports of other entities. Such rules are either built as specific or custom rules for the filing platform or communicated through filing manuals or guidelines. The filing rules and guidelines typically consist of the practices to be followed while creating XBRL reports and could include the file naming style, usage of period, entity, currency etc.

While it is observed that such business validation rules are mostly handled outside the taxonomy, it can be technically implemented using XBRL Formula through use of custom functions.

Deciding the Implementation Strategy

There are numerous choices and methods available for building business validation rules in the taxonomy that would eventually be used by the XBRL filing program. Here are some key points to consider when implementing business validation rules:

Making the choice between Taxonomy and outside Taxonomy alternatives

The taxonomy specifies the disclosure requirements for an XBRL report and thus, making it the most obvious choice to define the business validation rules. Also, this helps to make the business validation rules available to all users of the taxonomy, including preparers of XBRL documents, analysts, investors, regulators, software vendors and others. However, it is important to note that:

• Checks that require comparing data submitted in XBRL documents to external sources are difficult to define in the taxonomy without defining custom components. For example, an XBRL report may include a registration number of the filing entity. This information could already be present in some database of the regulator. There could be a business validation rule that says the content included in XBRL report should match the data present in the database.

  Defining such business validation rules in the taxonomy requires custom functions to be included in the taxonomy. Further, this approach may be more time and resource intensive if the XBRL data sets are large. Hence such business validation rules are usually outside the scope of the taxonomy.

• Business validation rules that are included in the taxonomy are driven by the implementers of XBRL Program. Other stakeholders can create an additional layer of business validation rules using the taxonomy. This would result in extension taxonomy.

  For example, the taxonomy defined by the implementer may include a business validation rule to check if name of reporting entity, total assets, total liabilities and net profit is mandatorily reported in the XBRL report. The data consumer may want to have certain more fields to be checked for mandatory reporting like revenue, finance cost, cash balance etc. In this case, the data consumer can define these additional business validation rules as an extension to the base taxonomy.

Selecting amongst the alternatives

Within the XBRL framework, there are a number of options from which to choose for defining the business validation rules. While defining the business validation rules, any, some or all of the options can be used. All the options can co-exist in the taxonomy and hence while developing the taxonomy, any one or all techniques can be used to fulfil the business requirements. Each of the options has their own pros and cons. Some methods may be very easy to define and implement, however they may not handle all the desired business validation rules, while other options may take higher processing time as compared to others etcFor example, the concept level validations are relatively easier to define and to test a single fact individually for validity as compared to defining the same constraint using XBRL Formula. Likewise, calculation rules (when implemented as calculation constraints) are easier to analyse and visualise (as it is represented in a hierarchical manner) as compared to XBRL Formula.

Further, some of the alternatively are tightly coupled with taxonomy design and hence any amendments to business validation rules defined using those approaches, will necessitate a migration to new taxonomy version. The business validation rules defined at concept level is one such example. While amendments to business validation rules defined using calculation constraints, XBRL Dimension and XBRL Formula can be handled as extension layer, which can co-exist with previous taxonomy versions.

A careful evaluation of every alternative needs to be done to determine how and where the rules will be defined.

Impact on taxonomy versions

Defining business validation rules as part of the taxonomy can have an impact on taxonomy maintenance, as every change in a business validation rule will require a change in the taxonomy. The changes in business validation rules could be due to reasons such as revision in business logic, inclusion of new rules, deleting existing rules or fixing issues within existing rules. Hence, if business validation rules are defined as part of a taxonomy, then a change in the taxonomy would be warranted. This fact could influence the decision of identifying which business validation rules should be built as part of the taxonomy and which should be implemented using other mechanisms.

Support

In addition to the usual implementation support that is provided when setting up an XBRL filing program, specific support with respect to business validation rules should be provided to XBRL document preparers and data users/consumers. Some of the support items to be considered are:

• Documentation of business validation rules in business or non-technical language
• Testing all the reporting scenarios
• Providing test cases and expected results
• Providing descriptive error messages
• Creation and use of a validation tool suite

The extent of support needed will depend on the maturity and readiness of the market. When the business validation rules are part of taxonomy, the XBRL document preparers need to have access to XBRL-enabled software applications that can read and process the validation rules on the reported data

Market readiness

XBRL has widespread global adoption. However, the implementation and roll out strategy varies from country to country and regulator to regulator when considering the market readiness and maturity of the impacted stakeholders. With validation rules being part of the taxonomy, the first responsibility is on the preparers of XBRL documents to ensure complete and accurate data is submitted (as per the business validation rules). The users/consumers of XBRL reports may also have some additional rules to check post submission. Other users of XBRL data may want to define their own validation rules. This warrants the need for availability of software tools and skill sets that can facilitate the whole process, including defining business validation rules, helping to prepare data as per rules and finally validating the data.

Track for new developments

Considering the global implementation experience and feedback from the broader XBRL community, new XBRL technical specifications and guidance materials are being released for assisting the stakeholders involved in implementation of XBRL based solutions. Some of the recently released specifications like “Assertion Severity for XBRL Formulas” and “Extensible Enumerations” further offer flexibility and provision to define more business validation rules or related information at taxonomy level, which was previously handled through custom solutions. When choosing an approach for implementing validation rules, the latest available XBRL technical specifications should be considered.

Reference Implementations

Business validation rules are an integral part of all XBRL implementations. While it can be said as a best practice to define most of the business validation rules in the taxonomy, there could be some rules that are built as customisations to applications or the filing platform.

Some implementations and taxonomies that have adopted different methods of defining business validation rules are listed in the table below:

It should be noted that the need to satisfy the business validation rules and the extent of conformance are often specified at the XBRL Program level. This discretion is usually observed in case business validation rules defined using Calculation constraints, XBRL Formula and defined outside taxonomy.

Some XBRL programs necessitate that the XBRL report should conform to the business validation rules defined using Calculation constraints (examples include MCA India, ACRA Singapore, DBD Thailand), while some XBRL programs consider non-conforming to Calculation constraints as acceptable (examples include SEC, US)

Similarly, the business validation rules defined using XBRL Formula or outside taxonomy, are commonly classified as errors and warnings. Thereby suggesting which business rules have to be necessarily complied with.

Further Reading

• US SEC findings on data quality
• Formula overview
• US FDIC - Implementing formulas