Table of Contents

1 Introduction

Data collectors often require reports to include certain mandatory facts. The presence of these facts in the report is validated by the collector. Data collectors need to effectively communicate details of the mandatory facts to preparers and software developers. This document recommends several different approaches for specifying mandatory facts for an XBRL report and is targeted towards data collectors.

XBRL reporting programmes generally include additional validation rules other than mandatory facts, such as checking that an appropriate currency has been used for monetary facts or checking that numeric values pass appropriate calculation checks. The scope of this document is limited to the communication of mandatory facts, though it is recommended that a consistent approach be taken for communicating other validation rules as well.

2 What do we mean by mandatory facts?

Mandatory facts in an XBRL report, at the simplest level, correspond to required fields in a web form. Mandatory facts, if not reported, will cause the filing to be automatically rejected. An XBRL financial statement will typically require facts such as ‘Period of Reporting’, ‘Entity Identification’, ‘Revenue’, and ‘Assets’ to be reported. Note that disclosure requirements are generally much more than the list of mandatory facts, as disclosures are qualified by conditions such as the occurrence of an event or a transaction. For example, the following extract from ‘Related party transactions disclosures [IAS 24.18-19]’ states that disclosures are required if there have been related party transactions:

"If there have been transactions between related parties, disclose the nature of the related party relationship as well as information about the transactions and outstanding balances necessary for an understanding of the potential effect of the relationship on the financial statements."

When specifying mandatory facts in an XBRL report, it is important to identify exactly what is required. Facts are primarily identified by a concept, but it is also necessary to specify other dimensions, such as the period, entity and units with which the fact must be reported. It should also be made clear how many times mandatory facts must be reported. For example, some facts will need to be reported once for the report, whereas others may need to be reported once for each reporting period in which data is provided.

3 Why should mandatory facts be communicated?

Data collectors generally implement rules in the data collection platform to automatically reject filings that do not have the required facts. In addition to implementation of mandatory fact rules, it is important that the requirements are communicated to preparers and software vendors. This ensures that:

• Preparers are made aware of mandatory facts and ensure that they are present when creating their reports.
• Documentation of mandatory facts is needed to allow developers to create helpful UIs to prevent errors at input, rather than relying on the validation of XBRL reports and potentially complex error messages.
• Documentation also helps software developers to enable automated testing to ensure that mandatory fact rules are implemented correctly in software applications.

4 Possible communication and implementation approaches

This section discusses possible approaches for specifying mandatory facts for an XBRL report. One or multiple of the approaches discussed here can be used as summarised in the recommendation section.

4.1 Publish as a table

In this approach, the mandatory facts are published as a table either in a spreadsheet, or CSV file. Columns of the table represent details about the mandatory fact.

Characteristics and consequences:

• The mandatory facts can be understood by business users, without the need for specialised software.
• If the format of the table is suitably detailed and consistent, software developers can use it directly to implement (and update) mandatory checks in their applications. This is particularly beneficial where the number of required facts is large.
• More complicated rules such as X must be reported if Y greater than zero, may be difficult to represent effectively in a simple tabular structure.
• The table does not provide validation capability; a separate implementation such as XBRL formula rules would be required to validate reports.
• The table is an additional representation of the rules that must be kept in sync with the executable rules implemented in the filing platform. The executable rules and the table of rules should be generated from the same source to avoid the possibility of errors and omissions.

A variation of this approach is publishing the details of mandatory facts in a PDF document or a webpage. Although these formats are widely supported and popular, they make it hard for data to be extracted. It is not recommended to publish the table of mandatory facts as a PDF document or a webpage.

4.2 Provide mandatory fact validation as XBRL Formula Rules

In this approach, validation of mandatory facts is provided in the form of XBRL Formula rules. This means that mandatory fact validation is defined in the taxonomy and can be executed by an XBRL processor.

Characteristics and consequences:

• Conformant XBRL software can automatically validate XBRL Formula rules.
• Being in executable format avoids the possibility of misinterpretation of the rules by preparers and third-party software developers.
• XBRL Formula rules are equipped to address the complex variation of mandatory fact rules such as conditional applicability or multiple dimensions.
• The rules are updated along with the publication of the taxonomy.
• XBRL Formula rules do not provide human-readable documentation of the rules. Users may need XBRL conformant tools in order to review the rules, and the rules may not be readily comprehensible to business users.
  • The use of the "XF" text-based representation of XBRL Formula rules can significantly improve the readability of such rules, although this will depend on the complexity of the rules, and how they are constructed.

4.3 Annotated reporting templates

In this approach, mandatory facts are visually represented by highlighting or annotating a template-based representation of the report. In the taxonomies that use XBRL Reporting Templates (Table Linkbase), this may be a rendered table layout with highlighted mandatory cells.

Characteristics and consequences:

• Easier for business users to understand mandatory facts without knowing the underlying XBRL tags.
• It can effectively communicate mandatory facts that require specific combinations of taxonomy defined dimensions.
• This approach may not allow software developers to easily automate the implementation of mandatory checks in their applications.

4.4 Other Approaches

4.4.1 Defining ‘requires-element’ relationships

The standard ‘requires-element’ relationship (arc role) enforces the presence of a fact for one concept based on the presence of a fact for another concept. This relationship does not support set of facts varying in dimensions. This approach is not recommended as it only caters for a subset of mandatory fact rules, and cannot enforce an absolute requirement for a fact; it can only require a fact based on the presence of another. Due to the limitations of this mechanism, use of ‘requires-element’ is not recommended.

4.5 External rules

Specification of mandatory facts can also be achieved using rules defined outside of the XBRL taxonomy. Implementing external rules for mandatory facts is not recommended as it is disconnected from the taxonomy and requires custom implementation by data collectors and each software application. Read the guidance on implementing business rules in an XBRL programme to learn more.

5 Recommendations for specifying mandatory facts

• Selecting an implementation approach:
  • Always publish mandatory fact rules as XBRL formula rules.
  • Consider publishing as a table to assist software vendors if the mandatory facts can be consistently represented in a format that can be easily extracted to implement the validation checks in the applications.
  • Consider providing annotated reporting templates for representing mandatory facts where mandatory facts vary widely in required taxonomy-defined dimensions, rather than being a simple list of concepts.
• While publishing mandatory facts in a table consider including the following details:
  • Rule Identification - A unique identification for each rule.
    • This unique identification can be used for cross-referencing rules in XBRL formula and in error reports sent from the collection system.
  • Fact Identification
    • Identify mandatory facts by concept name and required dimensional qualifications.
    • For reporting programmes which use XBRL reporting templates, fact identification can be based on table, row and column coordinates.
  • Period - State the period or periods for which the mandatory facts are required to be reported.
  • Severity - Specify how rule failures will be treated by the reporting platform. For example, a filing system may reject reports that have rule failures with an "error" severity but accept filings if the only rule failures have a "warning" severity.
  • Condition- Some mandatory fact rules are triggered based on the presence or value of a different fact. Specify the details of the precondition that will trigger the mandatory rule.
    • An example of a conditional mandatory rule would be 'Reporting "Audit Observations" is mandatory for Public Companies’. The condition is checked based on the value reported for the concept "Type of Company".
    • Tabular representation of mandatory facts is most effective where the rules are unconditional, or can be classified into a small number of patterns of conditional rules.
  • It may be necessary to segment the mandatory fact rules by taxonomy entry point if reports use different entry points based on their reporting requirements.
  • Generate all representations of mandatory facts from the same source, to avoid inconsistencies and minimise maintenance burden. Collectors should automate taxonomy publication processes in order to ensure that representation of the mandatory facts is in sync with the taxonomy.
  • Where details of mandatory facts are communicated separately, data collectors should make it clear if there are other rules that may cause filings to be rejected.

6 Illustrative Examples

This section provides examples of mandatory fact rules published as a table and their corresponding representation in the XF format.

Please note that the structured tabular representations given in this document are only intended only as examples. They will need to be adapted to meet the specific needs of individual reporting programmes.

6.1 Example 1: Simple mandatory rule

Table 1 shows human-readable documentation of the rule which requires ‘Current Period End Date’ to be reported once. Data collectors will need to document the meaning of notations used in the table. For example, in this case "Report Type" with value "REPORT_ONCE" could mean the mandatory fact is required to be reported once, with a period that corresponds to the reporting period for the report.

XF representation of mandatory rule in Table 1

namespace eg = "http://example.com/taxonomy";
assertion M1 {
    unsatisfied-message (en) "’Current Period End Date’ must be reported";
    unsatisfied-severity ERROR;
    variable $v1 {
        concept-name  eg:CurrentPeriodEndDate;

    };
    evaluation-count {. eq 1};
};

The rule shown above will pass if there is exactly one fact for the "CurrentPeriodEndDate" concept present in the report. For a detailed explanation, refer to the mandatory rule example in XBRL formula rules tutorial.

6.2 Example 2: Conditional mandatory

Table 2 shows tabular documentation for a conditional mandatory rule which requires "Management Commentary" to be reported for listed entities. The "Rule Type" – ‘REPORT_ONCE_CONDITIONAL’ indicates that the mandatory fact is required to be reported once if a specific precondition is met. In this case, the precondition is based on the type of the reporting entity, determined by the value of an "Entity Type" concept.

XF representation of mandatory rule in Table 2

namespace eg = "http://example.com/taxonomy";
assertion M2 {
unsatisfied-message (en) " Report ‘Management Commentary’ as the entity is listed";
unsatisfied-severity WARNING;
variable $MgntCommentary {  
        fallback {()}
       concept-name eg:ManagementCommentaryExplanatory; 
    };
    variable $Status {
       concept-name eg:EntityStatus;
    };
    precondition { $Status eq xs:QName("eg:Listed")};
    test {not(empty($MgntCommentary)};
};

The rule shown above will check whether a fact for the "Management Commentary" concept is present when the value of "Entity Status" is "Listed". For a detailed explanation, refer to the precondition rule example in the XBRL formula rules tutorial.