5.1 Report Variables

Report Variables can be used to automate Report Content.  They can be dragged from the automation panel and dropped anywhere into the main body of the report.

Dragging and dropping a report variable creates a data object on the report (or changes the Data adaptor of existing Data Objects).  Data objects can be XBRL tagged, linked to external data sources, calculated or used in other calculations. (See Data Objects).

Data objects can exist in page headers or footers in addition to cross-references used for automation of their contents (see Cross-referencing) .

A report variable can be dragged from the automation panel and dropped onto the report:  

• If dropped onto an existing data object, its adaptor will change to reference the report variable.
• If dropped onto text in a report, the text will be replaced by a data object referencing the report variable.

Standard Report Variables

There are many standard report variables based on the current document properties that can be used to automate elements in the report ranging from report and entity names and IDs, default currencies and scaling, period end dates etc. 

The advantage to using these standard report variables is that they will sync with the current document's properties. i.e. if you change the reporting entities name - or the report's start and end dates, all data objects assigned to this report variable will automatically update.

Custom Report Variables

In addition to the standard report variable, custom report variables can be created. These custom report variables are very useful to:

• automate report content that needs to be consistent. For example, a custom report variable can be created for the report's approval date, and this custom report variable can be used to update the date of signing of the Strategic Report, the Directors' Report, and the approval date of the balance sheet. Updating the value of the custom report variable will update all data objects using the updated custom report variable; and
• drive suppression rules. Suppression rules can created based on the value of a custom report variable. For example, a custom variable of type "list" can be created for the type of the subsidiary. The list could have items "LLP" or "PLC". Suppression rules can be created based on the value of this custom report variable and used to suppress the Directors' Report or the Members' Report as appropriate.

Creating a Report Variable

To create a report variable, activate the Custom Variable panel and click Add:

Name: Type the name of the custom variable. It must be unique.

Type: Select the type of Report Variable. The following types are available:

1. Text. Can contain any text
2. List. The custom variable's value can only be one of the pre-defined list items.
3. Date. The custom variable can only be a valid date.
4. Number. The custom variable can contain only a valid number.
5. Yes/No. The custom value can be either true or false based on a checkbox.

Please note that custom variables of type "Yes/No" can be used directly to suppress content without having to first create a suppression rule. Since suppression rules return either a True or a False, suppression rules and custom variables of type Yes/No can be attached to segment, table rows and columns.

Items: (Only visible if custom variable is of type "List". You can enter all acceptable values delimited with a semi-colon.

Value: The value of the Report Variable. This could be a text box, combobox, checkbox or calendar control depending on the type of custom variable.

Editing the Value of a Custom Variable

The value of a custom variable can be edited by clicking on the Edit button:

Once the value is edited, the report will be updated with the variable's new value.

XBRL Tagging of Custom Variables

Allowing Custom Variables to be tagged provides a much simpler alternative to creating hidden segments with mandatory tags (included in hidden sections of iXBRL documents upon export) — streamlining the process of applying mandatory tags that either don’t appear directly in the report or are not in a format supported by the tag.

Examples include:

• cipc-ca:NameOfDesignatedPersonResponsibleForCompliance

  This person may not be explicitly listed in the report.

• cipc-ca:BusinessAddressCountry

  This field expects a three-letter ISO country code, but the report may only show the full country name.

Custom variables can be tagged with a single XBRL tag, along with any applicable non-default secondary tags, using a straightforward drag-and-drop process.

The desired primary XBRL tag can be dragged from the Primary Tags panel and dropped onto the target custom variable. This method mirrors how tags are applied within the Enhanced Auto-tag Table. If any non-default secondary tags are selected at the time of tagging, they will be automatically applied to the variable alongside the primary tag.

A non-default secondary tag, once appropriately ticked in the Secondary Tags panel, can be dragged from the Secondary Tags panel and dropped onto the target tagged custom variable.

Ensure that the checkbox next to the desired secondary tag is ticked before dragging it, as only selected tags can be applied this way.

Hidden XBRL Tag Attributes

For number-type custom report variables tagged with numeric XBRL tags, both Unit and Scale values must be defined. These are defaulted automatically, using the same logic as when tagging items on the face of the report. However, users are able to edit these values by clicking the Edit button.

Automatically created custom variables

When creating a new report by importing an existing document, the application auto-generates a number of custom report variables with default values for mandatory tags in FRC , South African CIPC, Irish Revenue FRC Taxonomy.

If the selected taxonomy is FRC, Step 4 – Defaults of the New Document Wizard will display a group box titled Hidden Mandatory Tags, containing:

• Entity Trading Status
• Accounts Status
• Accounts Type

Selecting an appropriate option in this step will automatically create XBRL-tagged custom variables with those secondary tags applied as shown below:

This approach will ensure that mandatory tags—not visible in the report—are set accurately at the document creation stage, reducing post-creation edits and improving compliance.